Many reverse engineers always try to break the cryptographic protocols/applications using reverse engineering process as their primary key. The process itself is known as "Cryptanalysis". It is hard, time consuming and resource mean. A common way to break the commercial crypto system is to reverse the code and find the implementation errors. I will take two such commercial examples below:
– MXI Stealth
– EISST E-capsule PrivateSafe
- FIPS 142-3 level 2 certified USB Key
- AES on-chip encryption
- Authentication through password (windows application) or fingerprint (OS independent)
- Upon connection a first removable drive with a locked contents appears.
- Upon successful authentication a second drive appears.
Problem with Technology
Passwords are injected upon creation from external USB interface. A random salt is also added as a plain text through USB and stored in the EEPROM. Combined password with salt is then hashed using SHA-256 bit algorithm and stored again in EEPROM with associated user. Now upon failed password attempt there is a delay of 500ms. However, this delay also applies when a password verfication operation is done. This gap allows a maximum of 120 tries/minute. It gives an attacker enough time to break into.
- There is a library to exchange encrypted messages with the key.
– Apparently the password is encrypted and sent to the key.
– After some messages are exchanged the protected disk is activated.
- A logging function is implemented. It does not write log messages into a log file but they can be seen in the memory.
– A simple patch of the code can reactivate the log file.
- The 60 byte string are three SHA1 hashes. The current password and the previous 2 passwords.
- The "enterprise" version of the software needs this info to make sure the user does not reuse
the current and last "n" passwords.
- This information is received by the software even before the user has authenticated.
EISST E-capsule PrivateSafe
PrivateSafe is a software that creates encrypted containers.
There are 4 passwords:
1. The admin password allows managing the container.
2. The public password reveals one part of the content.
3. The private passwod gives access to the rest of the content.
4. The panic password deletes all files and gives access to an empty container.
There are 2 files:
1. The encrypted file system.
2. A control file.
Through reverse engineering we found that:
- Each block of the control file is encrypted with AES 256 CTS mode.
– The key is the SHA256 hash of the corresponding password.
– The IV is the ripemd160 hash of the password.
– The clear text of blocks 1,2 and 3 are the same. Block 0 corresponds to the admin key.
- Exchanging two blocks in the control file inverts the role of their keys. E.g, private <-> public
- Worse. E.g, Shred <-> private
- Actually, exchanging just the single ascii character that identify the blocks is enough.