Every secure file is encrypted and signed, sector by sector, using dedicated keys derived by the two mSE master keys.
The Secure File System allows standard applications to access standard file systems through an HW cryptographic layer which performs data encryption, signature and name remapping.
You just need your mSE and the right login password to access your files!
Coded File Name = SHA256(File Name | EncDBKey | SigDBKey)
Two header fields (Random Number and Unique ID) are not encrypted, but only signed.
- RND = Random Number generated by the mSE physical RNG (clear)
- MAGIC = Secure File System magic number
- VER = Secure File version UID = File Unique ID (clear)
- UID_CNT = Unique ID Counter (clear)
- FNAME_LEN = File Name length
- FNAME = File Name
- Each Secure File is cached in Crypto Pages (~8KB per page),
- Each Crypto Page is made up of 8 sectors (506B per sector).
To Encrypt/Decrypt and Sign/Verify, two crypto streams (EncGrub, SigGrub) are generated by the mSE for each Crypto Page.
- Secure File UID (unique per Secure File)
- Secure File RND (unique per Secure File)
- Secure File CodedName (unique per Secure File)
- Secure File Sector index (unique per Secure File)
- mSE EncDBKey, SigDBKey (unique per mSE)
EncGrub Generation(SigGrub generation starts from SigDBKey)
The versioning feature allows developers to freeze the current Secure File version and invalidate all the previous ones.
- Before t3 all the Secure File copies can be accessed through the Secure File System APIs, if the right mSE is plugged in the device
- After t3, the copies taken at t0, t1, t2 cannot be accessed as they are invalidated by the SetVersion API
- At time t6 only the copy taken at t5, t6 can be managed, all the others are invalidated.
The SendTo function prepares a Secure File which can be received only by one or more declared mSE cards. It starts from a regular Secure File and creates a transient Secure File, which can be sent to other mSE cards.
- If the SecureFile header is corrupted you cannot operate on the Secure File.
- If the ReadFile function detects a corrupted sector it does not return data (it is supposed to retrieve garbage).
- If the WriteFile function detects a corrupted sector, it can still write data using the forceWrite flag. In this case the corrupted sector is supposed to be full of garbage but you can overwrite it. If you overwrite all the garbage, you purify the sector, otherwise the final sector is a mix of garbage and right data.
- The OpenFile function just checks the header and the last sector. If the last sector is corrupted, it can open the file using the forceOpen flag. In this case the last sector is supposed to be full of garbage.