DEV Community: Luka Bubalo

Printer steganography or "Is your printer spying on you"

Luka Bubalo — Mon, 07 Dec 2020 09:03:02 +0000

Lately, I’ve been solving information security challenges on RootMe and I came across an interesting steganography challenge that has surprised me. Just a small digression for those who are not familiar with RootMe which is a platform where you can find a lot of interesting security challenges from different topics like cryptanalysis, steganography, servers security, programming, etc. If you are interested in security, RootMe is the place where you can learn a lot of stuff and have fun at the same time.

The challenge

So the problem goes like this, you are given a scan of a printed document and your goal is to find the date of printing as well as the serial number of the printer. At first, I didn’t know what to do and I was trying to find clues in the text and the file itself. Of course, there was nothing within the text nor the file that I could use to solve this problem so I decided to read the reference that was given. The reference text described how some printers are using hidden digital watermarks called yellow dots or MIC (Machine Identification Code) allowing the printer to mark the identification of the device with which a document was printed and the date of printing. At first, I thought someone has a really good imagination and this challenge is completely fancied, but after some google searches I have found that this is real.

Why?

Many printers use this type of watermarking and according to Wikipedia it was developed by Canon and Xerox in the mid-1980s but it was kept secret until 2004. According to Xerox, the main motivation behind this watermarking technique was to assure that their printers won’t be used to counterfeit money. In 2004 Dutch authorities were using this to track down the counterfeiters who had used Canon printers and this hidden property became public. Also, there are rumors that all major manufacturers of color laser printers entered a secret agreement with governments to ensure that the output of those printers is forensically traceable.

Here, you can see how MIC looks on the paper. Every row has a certain number value, and every column has its data purpose in this yellow dots matrix.

If you find this interesting, try to solve the challenge. Good luck and have fun!

How to share a secret?

Luka Bubalo — Mon, 21 Sep 2020 08:43:20 +0000

Imagine, you are in the room with a group of total strangers and you are able to share secret information out loud with the one person of your choice, while everyone else is listening. Sounds a bit impossible at first thought, right? How could you say something out loud so that only one person will be able to understand what you are saying? Ok, you might start talking in Dumi language in hope that only that person understands it. But what if that person doesn’t understand Dumi or, the worst case, someone else does and your secret suddenly becomes compromised? What if you could publicly create a shared language only that person and you will understand? This is where the Diffie-Hellman key exchange method comes into play.

Diffie-Hellman key exchange

“The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher.” - Wikipedia

Now when we are done with the formal definition, let’s see what this really means.

Let’s say that our well-known security friends Alice and Bob want to perform a Diffie-Hellman key exchange. In the first step, they agree on publicly known information, let’s call it a common key, which will later be used to create a shared secret - key that will be used to encrypt all the communication between them. After they agree on the common key, both of them create a secret key that they keep for themselves. In the third step, both Alice and Bob combine the common key with their secret key and exchange that combination publicly. The most important presumption here is that it is nearly impossible to disassemble that combined key into initial parts - common key and secret key. Otherwise, this method wouldn’t make sense. Now you might be asking yourself how is this possible, but we will tackle this later on.
After the exchange of the combinations (Alice gets the combination of Bob’s private key and common key and vice versa), they again, each on their side, combine the private key with the combination they got from the other party. After this process is done, they will end up with the same key, the one that only Alice and Bob know and which is then used to encrypt the communication between them.

Photo by Wikipedia

Mathematics behind the Diffie-Hellman

In the first part of this post, we talked about how Diffie-Hellman works in a more abstract way. In this part, you will dive deeper and see how Diffie-Hellman works in terms of mathematics and how it is even possible to perform such a method.

Before we start, I hope you are all familiar with the modulo arithmetic, but let’s have a quick look.

a mod b (a modulo b) is a remainder of dividing a with b.
E.g. 11 mod 3 = 2, because 11/3 is 3 with the remainder 2.

You can imagine modulo arithmetic as circling around a clock which has numbers from 0 to (b - 1). According to the above example, the clock would have numbers 0, 1, 2 and you will make 3 circles around the clock ending up at number 2.

Now we are ready to see what happens under the hood while performing Diffie-Hellman.

Remember that assumption about how it is nearly impossible to disassemble the combination of private and common keys? Let’s have a look at the fourth step where all the “magic” happens.
Imagine you are an attacker who wants to break the encryption. All you have to do is to find out what is the number A or B (Alice’s or Bob’s secrets) from (P^A mod N) or (P^B mod N). Because, if you find out, for example, A, then you can easily calculate (P^B)^A mod N to get the shared secret and break the encryption.

It may sound easy at first, but it is a difficult problem, even for supercomputers. The problem is called the Discrete logarithm problem and it is not feasible in polynomial time. You can think of a solution for this problem as a brute-force algorithm, which iterates through all numbers between [1, N] and finds the numbers that satisfy the formula (P^A mod N) where only one corresponds to the real A.

When it comes to encrypted communication there is always a challenge to exchange symmetric keys so both parties can encrypt and decrypt the data with only one key, since the asymmetric encryption (one key is used for encryption and the other is used for decryption) is time-costly and unsuitable for fast communication. Diffie-Hellman is one way of tackling this problem. Another way of doing this is to use asymmetric encryption to encrypt and exchange the symmetric key which will then be used to encrypt the communication (encrypt the symmetric key with the public asymmetric key so it can be only decrypted with the private key). For example, this kind of key exchange happens every time you visit some website via HTTPS protocol in the so-called HTTPS handshake.

That’s all folks! Thanks for reading, and if you have any questions, feel free to leave them in the comments section. Cheers! :)

The basics of using the delegation pattern

Luka Bubalo — Mon, 11 May 2020 08:03:30 +0000

Why?

Recently I’ve started with the development of iOS applications and stumbled upon an interesting design pattern called delegation pattern. Abstractly talking, the main idea behind this pattern is to receive and process information in class A when something happens in class B.
In this case, class A is the delegatee/worker, and class B is delegator/master. Specifically, when something happens on screen B, we want screen A to act accordingly. Also, the really good thing about this pattern is that you can have as many workers/delegatees as you want, they just need to implement the protocol.

I will give you an example written in Swift, but this can, of course, be applied in any other programming language which supports the object-oriented paradigm.

How?

Let’s say we have two screens, the first one is a profile screen where all information about the profile is shown like nickname, country, you name it.
The second one is the settings screen where we can change those profile information. What we want to achieve is that when we adjust that information on the settings screen and click the save button, we want that data to be propagated back to our profile screen. So basically, the settings screen is a delegator and the profile screen is a delegatee who will receive the data from its delegator and display it.

Before we start with the code example, let’s see what the flow for implementing delegate pattern looks like:

Define the delegate protocol
Add delegate property in the delegator
Extend the delegatee class so it implements the delegate protocol
Assign the delegatee object as delegate property in the delegator
Call the delegatee from the delegator

Here is the code example:

Note: if you are not familiar with Swift, the protocol is the same as the interface in languages like Java, C#, PHP, etc.

protocol MyProfileSettingsViewControllerDelegate: AnyObject {
    func didChange(profile: Profile)
}

class MyProfileSettingsViewController: UIViewController {

    // ...

    weak var delegate: MyProfileSettingsViewControllerDelegate?

    let saveButton = UIBarButtonItem(title: "Save", style: .plain, target: self, action: #selector(saveButtonTapped))

    func saveButtonTapped() {
        let profile = Profile(...) // populate Profile model with new data
        delegate?.didChange(profile: profile) // pass updated Profile model to delegatee

        // navigate to the profile screen
    }

    // ...
}

class MyProfileViewController: UIViewController {

    // ...

    let settingsButton = UIBarButtonItem(title: "Settings", style: .plain, target: self, action: #selector(settingsButtonTapped))

    func settingsButtonTapped() {
        let controller =  MyProfileSettingsViewController()
        controller.delegate = self // assign this object as delegatee

        // navigate to the profile screen
    }

    func updateInfo(profile: Profile) {
        nicknameLabel.text = profile.nickname
        countryLabel.text = profile.country
        //...
    }

    // ...

}

extension MyProfileViewController: MyProfileSettingsViewControllerDelegate {
    func didChange(profile: Profile) {
        updateInfo(profile: profile) // update your view with new profile data adjusted on the settings screen
    }
}

I hope this was helpful to you. If you have any questions, feel free to leave them in the comments below. :)

Thank you for reading!