EDITORIAL | February 13, 2020

Do You Blindly Trust LoRaWAN Networks for IoT?

By Cesar Cerrudo

Do you blindly trust that your IoT devices are being secured by the encryption methods employed by LoRaWAN? If so, you’re not alone. Long Range Wide Area Networking (LoRaWAN) is a protocol designed to allow low-power devices to communicate with Internet-connected applications over long-range wireless connections. It’s being adopted by major organizations across the world because of its promising capabilities. For example, a single gateway (antenna) can cover an entire city, hundreds of square miles.

With more than 100 million LoRaWAN-connected devices in use across the globe, many cellular carriers are racing to join in by offering LoRa nationwide coverage as a service for a low price: on average, a tenth of LTE-based services. However, neither equipment vendors nor service providers nor the end users who are implementing the technology are paying attention to security pitfalls, and are instead spreading a false sense of security.

Our New Research

In exploring the LoRaWAN protocol, we found major cyber security problems in the adoption of this technology. LoRaWAN is advertised as having “built-in encryption,” which may lead users to believe it is secure by default. When talking about the networks that are used across the globe to transmit data to and from IoT devices in smart cities, industrial settings, smart homes, smart utilities, vehicles, and healthcare, we can’t afford to blindly trust LoRaWAN and ignore cyber security. Last week, IOActive presented these LoRaWAN cyber security problems at The Things Conference in Amsterdam, and it grabbed the attention and interest of conference attendees.

The Root of the Risk

The root of the risk lies in the keys used for encrypting communications between devices, gateways, and network servers, which are often poorly protected and easily obtainable. Basically the keys are everywhere, making encryption almost useless. This leaves networks vulnerable to malicious hackers who could compromise the confidentiality and integrity of the data flowing to and from connected devices.

For example, if malicious hackers want to launch a Denial of Service attack, once they have the encryption keys, they can access the network and disrupt communications between connected devices and the network server, meaning companies can’t receive any data.

Alternatively, attackers could intercept communications and replace real sensor or meter readings with false data. Hackers could exploit this to damage industrial equipment, potentially halting operations and putting company infrastructure at risk.

These are just two examples of how attackers can leverage LoRaWAN to execute malicious attacks, but the list goes on. From preventing utility firms from taking smart meter readings, to stopping logistics companies from tracking vehicles, to blocking industrial control processes from receiving sensor readings, if we unwittingly trust flawed technology, we will pay the price.

What Now?

Currently there isn’t a way for an organization to know if a LoRaWAN implementation is or has been hacked or if an encryption key has been compromised. Furthermore, there are no tools to audit/penetration test/hack LoRaWAN implementations. Standing in the gap, IOActive has released a set of useful tools, the LoRaWAN Auditing Framework, which allows organizations to audit and penetration test their infrastructure, detect possible attacks, and eliminate or reduce the impact of an attack. Our goal is to ensure LoRaWAN is deployed securely.

Resources

IOActive LoRaWAN Networks Susceptible to Hacking: Common Cyber Security Problems, How to Detect and Prevent Them (whitepaper)
IOActive LoRaWAN Auditing Framework tools

RESEARCH | November 19, 2015

Breaking into and Reverse Engineering iOS Photo Vaults

By Michael Allen

Every so often we hear stories of people losing their mobile phones, often with sensitive photos on them. Additionally, people may lend their phones to friends only to have those friends start going through their photos. For whatever reason, a lot of people store risqué pictures on their devices. Why they feel the need to do that is left for another discussion. This behavior has fueled a desire to protect photos on mobile devices.

One popular option are photo vault applications. These applications claim to protect your photos, videos, etc. In general, they create albums within their application containers and limit access with a passcode, pattern, or, in the case of newer devices, TouchID.

I decided to take a look at some options for the iOS platform. I did a quick Google search for “best photo vaults iOS” and got the following results:

Figure 1: Search results for best iOS photo vaults

I downloaded the free applications, as this is what most typical users would do. This blog post discusses my findings.

Lab Setup

Jailbroken iPhone 4S (7.1.2)
BurpSuite Pro
Hex editor of choice
Cycript

Applications Reviewed

Private Photo Vault
Photo+Video Vault Keep Safe(My Media)
KeepSafe

I will cover the common techniques I used during each iOS application assessment. Additionally, I will take a deeper look at the Private Photo Vault application and get into some actual reverse engineering. The techniques discussed in the reverse engineering section can be applied to the other applications (left as an exercise for the reader).

Note: Unless otherwise stated, all commands are issued from Mac OS after having ssh’d into the jailbroken mobile device.

Private Photo Vault

The first application I looked at was Private Photo Vault. As it turns out, there have been several write-ups about the security, or lack thereof, of this application (see the references section for additional details). Because those write ups were published some time ago, I wanted to see if the developers had corrected the issues. As it turns out, the app was still vulnerable to some of the issues at the time of writing this post.

Bypassing the Lock Screen

When the app launches, the user is presented with the following screen:

Figure 2: Private Photo Vault Lock Screen

Bypassing this lock screen was trivial. The first step is to identify the Photo Vault process and then attach to it with cycript. For those not familiar with cycript, the following is taken from the cycript.org site:

“Cycript allows developers to explore and modify running applications on either iOS or Mac OS X using a hybrid of Objective-C++ and JavaScript syntax through an interactive console that features syntax highlighting and tab completion.”

To identify the Photo Vault process we issue the following commands:

ps –e | grep “Photo”

And then attach to it as shown:

cycript –p PhotoVault

Figure 3: Attaching to PhotoVault process with cycript

We then print the current view hierarchy using recursiveDescription by issuing the following command:

[[UIApp keyWindow] recursiveDescription]

Figure 4: Current View Hierarchy with recursiveDescription

Reviewing the current view hierarchy, we see a number of references to PasswordBox. Let’s see if we can alter what is being displayed. To do that we can issue the following command:

[#viewAddress setHidden:YES].

In this case we are testing the first PasswordBox at 0x15f687f0.

Figure 5: Hiding the first password input box

After executing the command we note that the first PasswordBox disappeared:

Figure 6: First password box hidden

Great, we can alter what is being displayed. Having obtained the current view, we now need to determine the controller. This can be accomplished with nextResponder as shown below. See references for details on nextResponder and the whole MVC model.

In a nutshell we keep calling nextResponder on the view until we hit a controller. In our case, we start with [#0x15f687f0 nextResponder] which returns <UIView: 0x15f68790> and then we call nextResponder on that like [#0x15f68790 nextResponder]. Eventually we hit a controller as shown:

Figure 7: Determining the View Controller

The WhiteLockScreenViewController controller seems to be responsible for the view. Earlier I dumped the class information with class-dump-z (not shown here). Examining the class revealed an interesting method called dismissLockScreen. Could it be that easy? As it turned out, it was. Simply calling the method as shown below was enough to bypass the lock screen:

Figure 8: Bypassing the lock screen with dismissLockScreen

Insecure Storage

During the setup I entered a passcode of 1337 to “protect” my photos. The next step, therefore, was to determine how the application was storing this passcode. Browsing the application directory revealed that the passcode was being stored in plaintext in the com.enchantedcloud.photovault.plistfile in /var/mobile/Applications/A025EF5F-ED84-4D82-A23D-BBCFE183F539/Library/Preferences.

As a side note I wonder what would be the effect of changing “Request Pin = 0”? It may be worth investigating further.

Figure 9: Passcode stored in plaintext

Not only is the PIN stored in plaintext, but the user has the option to password protect their albums. This again is stored in plaintext in the Albums.plist plist file.

Figure 10: Album password stored in plaintext

No Encryption

As if this wasn’t bad enough, the stored photos were not encrypted. This has already been pointed out elsewhere. Surprisingly enough, it remains the case as at the time of this writing. The pictures are stored in the /0 directory:

Figure 11: Location of unencrypted photos

Figure 12: Unencrypted view of stored photo

Reverse Engineering Private Photo Vault

Ok, so we have seen how to bypass the lock screen using cycript. However, let’s say that you wanted to go “under the hood “in order to achieve the same goal.

You could achieve this using:

IDA Pro/Hopper
LLDB
Usbmuxd
Debugserver

Environment Setup

Attach the mobile device to your host machine and launch tcprelay (usbmuxd directory) using the following syntax:

tcprelay.py -t <remote-port-to-forward><local-port-to-listen>

Figure 13: Launching tcprelay for debugging via USB

Tcprelay allows us to debug the application over USB as opposed to wifi, which can often be slow.

SSH into the device, start the debugserver, and attach to the PhotoVault process. Issue the following command:

debugserver *:8080 –a “PhoyoVault”

Figure 14: Launching debugserver on the mobile device

Launch lldb from your host machine, and connect to the listening debug server on the mobile device by issuing the following command from within lldb:

process connect connect://localhost:8080

Figure 15: Connecting to debugserver with lldb

Decrypt Binary

Now that the environment is configured, we can start debugging. Decrypt the binary and open it in IDA. I used the following command to decrypt the binary:

DYLD_INSERT_LIBRARIES=dumpdecrypted_armv7.dylib /var/mobile/Applications/A025EF5F-ED84-4D82-A23D-BBCFE183F539/PhotoVault.app/PhotoVault mach -o decryption dumper

Figure 16:Decrypting the PhotoVault binary

At this point I usually check to see if the binary is a FAT binary (i.e. it supports many devices). The command for that is: otool –hV PhotoVault.decrypted

Figure 17: Determining if the binary is a FAT binary

If it is indeed a FAT binary, I strip the architecture for my device. Given I am running an iPhone 4S, I ran the following command:

lipo -thin armv7 -output PhotoVault-v7 PhotoVault.decrypted.

The PhotoVault-v7 binary is what we will analyze in IDA or Hopper (see the reference section for instructions on configuring lldb and debugserver).

Earlier we established that WhiteLockScreenViewController was the controller responsible for the lock screen. This will become important in a bit. If we enter an incorrect password, the application prints “Wrong Passcode – Try Again”. Our first step, therefore, is to find occurrences of this in IDA.

Figure 18: Searching for occurrences of “Wrong Passcode”

We see several occurrences, but any reference to WhiteLockScreenViewController should be of interest to us. Let’s investigate this more. After a brief examination we discover the following:

Figure 19: Examining WhiteLockScreenViewController customKeyboardButtonPressed

At 0013A102, the lockScreen:isPasswordCorrect method is called, and at 0013A114 the return value is checked. At 0013A118 a decision is made on how to proceed. If we entered an incorrect passcode, the application will branch to loc_13A146 and display “Wrong Passcode” as shown in the snippet below.

Figure 20: Wrong Passcode branch we need to avoid

Obviously, we want the application to branch to 0013A11A, because in that branch we see references to a selRef_lockScreen_didEnterCorrectPassword_ method.

Figure 21: Branch we are interested in taking

Let’s set breakpoint at 0013A110, right before the check for the return value is done. Before we can do that, we need to account for ASLR, so we must first determine the ASLR Offset on the device.

Figure 22: Breakpoint will set at 0013A110

To accomplish this we issue the following command from within our lldb session:

image list –o -f

The image is loaded at 0xef000 so the address we need to break on is the 0x000ef000 + 0013A110.

Figure 23: Determining ASLR offset

We set a breakpoint at 0x229110 with the following command: br s -a 0x229110.

From this point breakpoints will be calculated as ASLR Offset + IDA Offset.

Figure 24: Setting the breakpoint

With our breakpoint set, we go back to the device and enter an arbitrary passcode. The breakpoint is hit and we print the value of register r8 with p $r8.

Figure 25: Examining the value in register r8

Given the value of zero, the TST.W R8, #0xFF instructions will see us taking the branch that prints “Wrong Passcode”. We need to change this value so that we take the other branch. To do that we issue the following command: register write r8 1

Figure 26: Updating the r8 register to 1

The command sets the value of register r8 to 1. We are almost there. But before we continue, let’s examine the branch we have taken. In that branch we see a call to lockScreen_didEnterCorrectPassword. So again, we search IDA for that function and the results show it references the PasswordManager class.

Figure 27: Searching IDA for occurences of lockScreen_didEnterCorrectPassword

We next examine that function where we notice several things happening:

Figure 28: Examining lockScreen_didEnterCorrectPassword

In short, in this block the application reads the PIN stored on the device and compares it to the value we entered at 0012D498. Of course this check will fail, because we entered an incorrect PIN. Looking further at this function revealed a call to the familiar dismissLockScreen. Recall this is the function we called in cycript earlier.

Figure 29: Branch with dismissLockScreen

It seems then that we need to take this branch. To do that, we change the value in r0 so that we get our desired result when the TST instruction is called. This ends up tricking the application into thinking we entered the correct PIN. We set a breakpoint at 0012D49C (i.e. the point at which we test for the return value from isEqualToString). Recall we are still in the lockScreen_didEnterCorrectPassword method of the PasswordManager class.

Figure 30: Point at which the PIN is verified

We already know the check will fail, since we entered an incorrect PIN, so we update the value in r0 to 1.

Figure 31: Updating r0 register to 1 to call dismissLockScreen

When we do that and continue execution, the dismissLockScreen method is called and the lock screen disappears, granting us access to the photos. So to recap the first patch allows us to call lockScreen_didEnterCorrectPassword. And then the second patch allows us to call dismissLockScreen, all with an arbitrary pin.

Let’s now look at the other applications.

My Media

Insecure Webserver

This was a very popular application in the app store. However, it suffered from some of the same vulnerabilities highlighted previously. What is interesting about this application is that it starts a web server on port 5555, which essentially allows users to manage their albums.

Figure 32: Web server started on port 5555

Browsing to the address results in the following interface:

Figure 33: My Media Wifi Manager

The first thing I noticed was that there was no authentication. Anybody on the same network could potentially gain access to the user’s albums. Looking a little deeper revealed that the application was vulnerable to common web application vulnerabilities. An example of this is stored cross-site scripting (XSS) in the Album name parameter:

Figure 34: Stored XSS in Album name

Insecure Storage

Again, the photos were not encrypted (verified using the hex editor from earlier). Photos and videos were stored in the following location:

/var/mobile/Applications/61273D04-3925-41EF-BD63-C2B0BC128F70/Library/XFFile/Decoy/1/Picture/Album1

Figure 35: Insecure storage of photos

On the device, this looks like the following:

Figure 36:Albums and photos on device

One of the features of these password-protected photo vaults is the ability to setup decoys. If the user chooses to create a decoy, then when the decoy password is entered it takes them to a “fake” album. I created a decoy in this application and found that the photos were also not encrypted (not that I expected them to be). I created a decoy album and added a photo. The decoy photos were stored in the following location:

/var/mobile/Applications/B73BB177-CEB7-4576-BDFC-2408A0369D42/Library/XFFile/Decoy/2/Picture/Decoy Album

The application stored user credentials in an unencrypted sqlite database. The passcode required to access the application was 1234 and was tied to the administrative account as shown. This was the passcode I chose when I was configuring the application. I also created a decoy user. These credentials were stored plaintext in the users table.

Figure 37: Extracting credentials with sqlite

KeepSafe

Bypassing the Lock Screen

Again bypassing the lock screen was trivial.

Figure 38: KeepSafe LockScreen

The lock screen could be bypassed by calling the showMainStoryboard method from the KeepSafe.AppDelegateclass. Again we attach to the process with cycript and this time we get the instance methods:

Examining the instance methods reveals the following methods:

And calling the showAccountStoryboard or showMainStoryboard methods as shown bypasses the lock screen:

Figure 39: Bypassing the lock screen

The application also allows the user to password protect each album. Each album is synced to the cloud.

Figure 40: KeepSafe cloud storage

I discovered that the password for the albums was returned in plaintext from the server as shown:

Figure 41: Album password return in plaintext from the server

An attacker could therefore not only bypass the lockscreen but he could obtain the passcode for password protected albums as well.

Conclusion

Ok so let’s do a quick recap on what we were able to accomplish. We used:

cycript to bypass the lock screens
sqlite to extract sensitive information from the application databases
plutil to read plist files and access sensitive information
BurpSuite Pro to intercept traffic from the application
IDA Pro to reverse the binary and achieve results similar to cycript

The scary part of this is that, on average, it took less than 30 minutes to gain access to the photos and user credentials for each application. The only exception was the use of IDA, and as we highlighted, we only did that to introduce you to and get you comfortable reading ARM assembly. In other words, it’s possible for an attacker to access your private photos in minutes.

In all cases it was trivial to bypass the lock screen protection. In short I found:

No jailbreak detection routines
Insecure storage of credentials
Photos stored unencrypted
Lock screens are easy to bypass
Common web application vulnerabilities

Let me hasten to say that this research does not speak to ALL photo vault applications. I just grabbed what seemed to be the most popular and had a quick look. That said, I wouldn’t be surprised if others had similar issues, as developers often make incorrect assumptions (believing users will never have access to the file system).

What are some of the risks? First and foremost, if you are running these apps on a jailbroken device, it is trivial to gain access to them. And in the case of My Media, even if you are not on a jailbroken device, anyone could connect to the media server it starts up and access your data.

More importantly though is the fact that your data is not encrypted. A malicious app (some of which have popped up recently) could gain access to your data.

The next time you download one of these apps, keep in mind it may not be doing what you think it is doing. Better yet, don’t store “private” photos on your device in the first place.

References:

RESEARCH | July 24, 2015

Differential Cryptanalysis for Dummies

By Keith Makan

Recently, I ventured into the crazy world of differential cryptanalysis purely to find out what the heck it was all about. In this post, I hope to reassure you that this strange and rather cool technique is not as scary as it seems. Hopefully, you’ll be attacking some ciphers of your own in no time!

A differential cryptanalysis attack is a method of abusing pairs of plaintext and corresponding ciphertext to learn about the secret key that encrypted them, or, more precisely, to reduce the amount of time needed to find the key. It’s what is called a chosen plaintext attack; the attacker has access to plaintext and corresponding ciphertext.

We’re going to attack a simple block cipher I stole using another explanation of the technique (links are available at the bottom of the post). This cipher is meant to exhibit a few rudimentary elements of a Substitution-Permutation Network (SPN) (minus some common elements for simplicity), while highlighting the power of the differential technique. So, let’s get started.

I think a good place to start is to look at the block cipher and check out what makes it tick. Here is a quick schematic of the algorithm:

Where:

C is the cipher-text
K_0, K_1 are the first and second round keys, respectively
P is the plaintext
SBOX is the substitution box.

As you can probably guess from looking at the schematic,: the cipher takes in two 2 sub-keys (K_0,K_1) and a piece of plain-text. It, it then XORs the plain-text with the first key, K_0, then, afterwards pulls the plain-text through a substitution box (SBOX) (we will talk about this little gadget soon). From there, it then takes the output of the SBOX, and XORs it with K_01, and then pulls it through the SBOX again to produce the file piece of final cipher-text. So now that we know how the cipher works, and we can begin formulating our attack.!

To start off with, let’s try writing down this cipher in an algebraic form:

C=SBOX(SBOX(P⨁K_0 )⨁K_1 )

(1)

Great! We can start talking about some of the weird properties of this cipher.

We know that when it comes to the cryptographic security of an encryption function the only thing that should be relied on for Confidentiality is your secret key (these are the words of a great Dutch cryptographer a long time ago [https://en.wikipedia.org/wiki/Auguste_Kerckhoffs]). This means the algorithm, including the workings of the SBOXs, will be known (or rather, in our analysis, we should always assume it will be known) by our attacker. Anything secret in our algorithm cannot be relied on for security. More specifically, any operation that is completely reversible (requiring only knowledge of the ciphertext) is useless!

When it comes to the use of substitution boxes, unless something we don’t know meaningfully obscures the output of the SBOX, using it will not add any security. It will be reduced to a mere reversible “encoding” of its input.

Looking at the algebraic form in (1), we can see the cipher pulls the input through the SBOX again in its last operation before returning it as ciphertext. This operation adds no security at all, especially in the context of a differential attack, because it is trivial to reverse the effect of the last SBOX. To make this clear, imagine knowing the output of the SBOX, but not being capable of knowing the input. Given the context of the last SBOX, this is impossible if you know the ciphertext. We can reduce the encryption function and focus on what actually adds security. The function becomes:

C= SBOX(P⨁K_0 )⨁K_1

(2)

Ironically, the SBOX in this expression (2), is now the only thing that adds security, so it will be the target of our analysis. Consider what would happen if we could know the output of the SBOX, including the plaintext/ciphertext pairs. The entire security of the cipher would fly out the window. After a few XOR operations, we would be able to work out the second key, and by extrapolation, the first key.

But how would we know the SBOX output? Well, what about analyzing the way the SBOX behaves by observing how differences between inputs map to differences in outputs. This insight is at the heart of differential cryptanalysis! Why choose this property? The only thing we have access to is plaintext/ciphertext pairs in a differential cryptanalysis attack (thems the rules), so we need to derive our information from this data. Also, XOR differences have favorable properties under XOR, namely they are unaffected by them. If we look at how the SBOX maps these differences, this is what we get:

∆x	∆y	count	[(x,x^’), (y,y^’)]
15	4	1	[(0, 15), (3, 7)]
15	7	1	[(3, 12), (10, 13)]
15	6	2	[(4, 11), (4, 2)] [(5, 10), (9, 15)]
5	15	1	[(3, 6), (10, 5)]
5	10	2	[(0, 5), (3, 9)] [(1, 4), (14, 4)]
3	15	1	[(1, 2), (14, 1)]
3	12	2	[(5, 6), (9, 5)] [(13, 14), (12, 0)]
3	10	2	[(8, 11), (8, 2)] [(12, 15), (13, 7)]
5	2	1	[(11, 14), (2, 0)]
5	4	1	[(8, 13), (8, 12)]
5	7	1	[(2, 7), (1, 6)]
5	6	1	[(9, 12), (11, 13)]
5	8	1	[(10, 15), (15, 7)]
4	15	1	[(10, 14), (15, 0)]
4	12	1	[(3, 7), (10, 6)]
1	7	1	[(14, 15), (0, 7)]
1	1	1	[(12, 13), (13, 12)]

Where

∆x = x⊕x^’
∆y = y⊕y^’
x^’,x is the input pair to the SBOX
y’,y is the output pair of from the SBOX
And ∆x→ ∆y is a differential characteristic
Count is the number of times the differential characteristic appears

This table is a small sample of the data collected from the SBOX.

This mapping of the XOR difference in the input to the XOR difference in the output is called a differential characteristic. Hence the name, “differential” cryptanalysis.! We can now use this data to steal the secret key.! Given the cipher-text/plain-text pairs, we need to find one encrypted under our target key that satisfies one of the differential characteristics. To find that pair you need to do the following:

Consider a sample differential characteristic a →b (this can be any differential):

Choose (or generate) one plain-text P, and produce another plain-text P^’=P⨁a , where a is an input differential (notice that the XOR difference of P and P’ is a!)
Encrypt the two plain-texts (P,P’) to get (C,C’)
If C⨁C’ = b, then you have a good pair!

If you know that a →b is the differential that suits your text pair, you now know what the potential input/output pairs are for the SBOX, because of thanks to the analysis we did earlier on. ! So now given these pairs, you can try different calculations for the key. You will likely have a couple possible keys, but one of them will definitely be the correct one.

For example, let’s say we have the following setup:

The keys K_0, K_1 : 0,6

(p,p’) :=> (c,c’) : input_diff :=> output_diff : [count, [(sI,sI’),(sO,sO’)]… ]

(3,12) -> (11, 12) : 15 :=> 7 : [1, [[(3, 12), (10, 13)]]]

(5,10) -> (9, 15) : 15 :=> 6 : [2, [[(4, 11), (4, 2)], [(5, 10), (9, 15)]]]

(4,11) -> (4, 2) : 15 :=> 6 : [2, [[(4, 11), (4, 2)], [(5, 10), (9, 15)]]]

(5,10) -> (9, 15) : 15 :=> 6 : [2, [[(4, 11), (4, 2)], [(5, 10), (9, 15)]]]

(3,6) -> (3, 12) : 5 :=> 15 : [1, [[(3, 6), (10, 5)]]]

The script that generated this output is available at the end of the post.

We need to select a plain-text/cipher-text pair and use the information associated to with them the pair to calculate the key. So for example let’s use, using (3,12) => (11,12), we can then calculate the K_0, K_1 in the following way:

Given then that (from the last operation of the cipher):

C=K_1⊕ S_o

We know that (because of how XOR works):

K_1=C⊕ S_o

Although we have a couple of choices for those values, so we need to run through them.

Given that:

K_0,K_1=(11,12)

C=(11,12) this is a tuple because we are using a pair of cipher-texts

P=(3,12)

S_i=(3,12)

S_o=(10,13)

We can then try to calculate the second round key as:

K_1=C[0]⊕ S_o [0]=1 wrong!

K_1=C[0]⊕ S_o [1]=6 right!

(3)

We can also calculate K_0, namely:

K_0=P[1]⊕ S_i [0]= wrong!

K_0=C[0]⊕ S_o [1]= wrong!

K_0=C[0]⊕ S_o [0]=0 right!

(4)

We’ve just derived the two sub keys.! Cryptanalysis successful!

The weird behavior of the SBOX under differential mapping is what makes differential cryptanalysis possible, but it this is not to say that this is the ONLY way to perform differential cryptanalysis. The property we are using here (XOR differences) is merely one application of this concept. You should think about differential cryptanalysis as leveraging any operation in an encryption function that can be used to “explain” differences in input/output pairs. So when you’re done reading about this application, look at some of the other common operations in encryption functions and think about what else, besides SBOXs, can be abused in this way; what other properties of the input/outputs pairs have interesting behaviors under common operations?.

Also, it may be useful to think about how you can extend this application of differential cryptanalysis in order to attack multi-round ciphers (i.e. ciphers that are built using multiple rounds of computation of ciphers like the one we’ve attacked here).