Practical bruteforce of AES-1024 military grade encryption:
I recently presented work on the analysis of a file encryption solution that claimed to implement "AES-1024 military grade encryption". Spoiler alert: I did not break AES, and this work does not concern the security of AES. You may find advanced research regarding this topic.
This project started during a forensic analysis. One of my colleagues came with a USB stick containing a vault encrypted with SanDisk Secure Access software. He asked me if it was possible to bruteforce the password of the vault to recover the content. I did not know this software thus, I started to research. It appeared that this solution is distributed by Sandisk by default on any storage device you buy from them.
The solution is convenient, it allows a user to run the binary on the disk and after entering her correct password her vault is unlocked and the files are accessible. Once the software is closed, the files are encrypted back and not accessible anymore. So far nothing uncommon, but one thing drew my attention. In the Options menu, you can choose your "Preferred encryption method".
[...] They claimed to provide "Ultimate encryption using 1024 bit AES keys, Military grade". Thus for all those reasons, I decided to analyze the solution to figure out how it was implemented.
[...] In fact from a general point of view, I was analyzing a password hash function. The function takes as input a user password and hashes it to a key which is later used to encrypt or decrypt data. Usually, the password hash function takes as input a unique and randomly generated salt to avoid precomputed attacks like dictionary or rainbow table attacks. Another common parameter of the hash function is the iterations number which allows to adapt the work factor. The higher the iteration number is the longer it will takes to compute the hash and thus, the harder it will to bruteforce the password for an attacker. Currently the are various recommended algorithms like: PBKDF2, Scrypt or Argon2. Argon2 is the winner of the Password Hashing Competition and is now considered as the state of the art for password hashing.
For this analysis, I only needed to focus on PBKDF2. Its design is simple:
[...] It looks randomly generated but it is definitively not unique since all vaults created with the software would use the same salt for the key derivation. In addition, users using the same password would end up with the same decryption key. Later I discovered that the same salt value is also shared among all the vendors: SanDisk, Sony and Lexar. A less critical problem is that the number of iterations is also fixed and set to 1000. This number of iterations was good when PBKDF2 was designed but nowadays the iteration number has to be higher. For example, OWASP recommends now 310000 iterations when PBKDF2 uses HMAC-SHA-256. Nevertheless, the construction itself of the key derivation function is flawed.
[...] Now that I got the key derivation function, I checked how the password was verified to be correct. In fact, a file name filesystem.dat sored[sic] in the folder C:\Users\user\AppData\Local\ENCSecurityBV\ENCDataVault70\ENCDataVault contains an encrypted magic value. When the decryption of this magic value gives 0xd2c3b4a1 then the password is considered correct. The decryption algorithm used OpenSSL AES encryption. In fact for the AES-128 option, the encryption is simply AES in CTR mode with a 128-bit key generated from the key derivation function described earlier. However for the other modes the construction is more curious.
[...] I got everything I needed to implement a John the ripper plugin that allows everybody to bruteforce AES-1024 military grade encryption! The plugin is now integrated into the main repository and also includes also the bruteforce of the new key derivation function based on HMAC-PBKDF-SHA256.
[...] This analysis shows again that it is difficult to roll a custom cryptographic algorithm and also that the level of security of a solution does not depend on the number of encryptions performed.
(Score: 0) by Anonymous Coward on Saturday May 14 2022, @11:48PM (2 children)
Supersizing AES to 1024 bits makes a significant difference?
(Score: 0, Disagree) by Anonymous Coward on Sunday May 15 2022, @12:36AM
It's like running ROT13 twice.
(Score: 2) by bzipitidoo on Sunday May 15 2022, @04:12PM
Yes, more bits can matter, up to a point. Once there are enough bits to make all conceivable future brute force attacks take millions of years, adding more bits to increase that time to trillions of years is obviously just a waste of effort.
But this vendor didn't really do that. As often is the case with claims of this sort, it's marketing hype. "Military grade", pshaw, right. They just made that part up. Real crypto experts analyzed the vendor's work, and concluded it's actually no more secure than 128 bit AES. This smells like tension between engineers being pressured to deliver, but issuing caveats, and executives feeling they can ignore the concerns to go ahead and sell it by making unsupported and unproven claims that they figure will fly because no one can disprove it either. Then these outside researchers had to get nosy.
(Score: 4, Informative) by Opportunist on Sunday May 15 2022, @12:41AM
AES is secure if, and only if, whoever implements it first of all understood it.
(Score: 1, Funny) by Anonymous Coward on Sunday May 15 2022, @01:28AM
Sandisk sues him under the DMCA.
(Score: 3, Touché) by istartedi on Sunday May 15 2022, @03:30AM
Not a real crypto guy here, but the paragraph that begins "It looks randomly generated" seems like the real problem. It's like that old joke:
#define RANDOM 4 //determined by roll of fair die, and thus random.
Appended to the end of comments you post. Max: 120 chars.
(Score: 0) by Anonymous Coward on Sunday May 15 2022, @04:57PM
also i am no crypto guy, but "hard coded salt"?
also, maybe, crypto would be " easier" if each "password" works but gives gibberish instead of helpfull "sorry, wrong, try again!" :D
(Score: 2) by Mojibake Tengu on Monday May 16 2022, @11:02AM
https://en.wikipedia.org/wiki/NOBUS [wikipedia.org]
Don't blame them corporations, poor SanDisk, Sony, Lexar and Kingston are just obeying behests.
Seriously, still everyone believes a funny dogma 'it is a sin to develop your own encryption'?
Because, that's what I do, for keeping my own data safe from everyone.
And before you freak out, try to think critically for a moment why this dogma was propagated upon common public.
Of course, many of such home-invented encryption schemes will be weak toys or academically flawed.
But the total overall cost of technology and human resources necessary for cracking millions of different ciphers will create unsustainable burden on Services.
And that's a model of asymmetric defense. They can't beat all. The herd will prevail.
The edge of 太玄 cannot be defined, for it is beyond every aspect of design