Points: 223

Tags: crypto timing cache aes aes-ecb aeskey timing-attack side 

Poll rating:

My crypto algorithm runs in constant time, so I'm safe from sidechannel leaks, right?

Note: To clarify, the sample data is plaintext inputs, NOT ciphertext

A text file:

Hello, fellow space enthusiasts!

I have been tracking a specific satellite and managed to intercept an interesting piece of data. Unfortunately, the data is encrypted using an AES-128 key with ECB-Mode.

Encrypted Data: 8bffc933b930b6d8067056eec711ab82c1b45ff4dff4360a014febf5e98073dc7e65d53dbdad4656034282020990088870f96a754c5c0c6e48e8ad0500d1135c9059251efc898ee57fb5d20475e0aea1c3e2ce37c4087b1083d22a6350bd146f92685ce072fc8a34be3e1d23c98cdd46

Using proprietary documentation, I have learned that the process of generating the AES key always produces the same first 6 bytes, while the remaining bytes are random:

Key Bytes 0..5: bed370513985

The communication protocol hashes every message into a 128bit digest, which is encrypted with the satellite key, and sent back as an authenticated ACK. This process fortunately happens BEFORE the satellite attempts to decrypt and process my message, which it will immediately drop my message as I cannot encrypt it properly without the key.

I have read about "side channel attacks" on crypto but don't really understand them, so I'm reaching out to you for help. I know timing data could be important so I've already used this vulnerability to collect a large data set of encryption times for various hash values. Please take a look!

And then a text file with many lines of the form

49fd411ea44d35f07adc1dbd79f38ab4,10704 19f6a95f9c5703c4d8fc0f0bb1b11f7a,10680 aad94711aa37274c9ba91ab01de1c7e3,10752 bafc1e9d71d5581195385d7d4a26bfac,10704 fe2e2515e83ba7d48fd43eb984ca615b,10728 13ebe9dda084b5c7da268f4e643d1bb9,10704

Writeups

ActionRatingAuthor team
Read writeup
not rated
PFS
Read writeup
not rated
1064CBread
You need to authenticate and join a team to post writeups