- The document discusses cryptographic storage for smartphone data, specifically the aescrypt format and software which allows encrypted storage of secret files on phones and across backups.
- Aescrypt uses a randomly generated initialization vector and password hashes to encrypt the bulk of files with AES-256, and includes metadata and integrity checks without revealing secret information.
- The key derived from hashing the password is used to encrypt an actual encryption key, to provide an additional layer of protection in case the derived key is compromised.
10. Nut[the problem]shell
• Want to store data
• But it must be secret
• if the phone is stolen
• if the iTunes backup is stolen
11. Nut[the problem]shell
• Want to store data
• But it must be secret
• if the phone is stolen
• if the iTunes backup is stolen
• It must be tamper-proof
12. Nut[the problem]shell
• Want to store data
• But it must be secret
• if the phone is stolen
• if the iTunes backup is stolen
• It must be tamper-proof
• …to some extent
15. Solution: aescrypt
• Unencumbered (public domain) format and
freeware implementation at http://
aescrypt.org
• Not just you using it
16. Solution: aescrypt
• Unencumbered (public domain) format and
freeware implementation at http://
aescrypt.org
• Not just you using it
• Mac, iOS, more
17. Solution: aescrypt
• Unencumbered (public domain) format and
freeware implementation at http://
aescrypt.org
• Not just you using it
• Mac, iOS, more
• Let’s start at byte 0 :-)
26. What’s our vector,
Victor?
// We will use an initialization vector comprised of the
current time
// process ID, and random data, all hashed together
with SHA-256.
source: wikipedia
27. You can’t come in here unless
you say “Swordfish”
// Hash the IV and password 8192 times
memset(digest, 0, 32);
memcpy(digest, IV, 16);
for(i=0; i<8192; i++)
{
sha256_starts( &sha_ctx);
sha256_update( &sha_ctx, digest, 32);
sha256_update( &sha_ctx,
(unsigned char*)passwd,
(unsigned long)passlen);
sha256_finish( &sha_ctx,
digest);
}
29. Cutty say 'e can't HANG!
• The key we just derived is not used to
encrypt the plaintext file
• Instead, it’s used to encrypt a key, which is
itself used to encrypt the file.
• …why?
30. Irony: Eminem tribute act
singing “the real slim shady”
…
16 Octets - Initialization Vector (IV) used for encrypting the
IV and symmetric key that is actually used to encrypt
the bulk of the plaintext file.
48 Octets - Encrypted IV and 256-bit AES key used to encrypt the
bulk of the file
16 octets - initialization vector
32 octets - encryption key
32 Octets - HMAC
nn Octets - Encrypted message (2^64 octets max)
1 Octet - File size modulo 16 in least significant bit positions
32 Octets - HMAC
…
31. Filler material
…
16 Octets - Initialization Vector (IV) used for encrypting the
IV and symmetric key that is actually used to encrypt
the bulk of the plaintext file.
48 Octets - Encrypted IV and 256-bit AES key used to encrypt the
bulk of the file
16 octets - initialization vector
32 octets - encryption key
32 Octets - HMAC
nn Octets - Encrypted message (2^64 octets max)
1 Octet - File size modulo 16 in least significant bit positions
32 Octets - HMAC
…
Yes, so there is the NSFileProtection encryption. However, the ability to use that to actually protect data depends on the user having a passcode lock enabled, and you can&#x2019;t test for that in your app. If you can&#x2019;t enforce that all of your users comply with a particular passcode policy, you must implement your own protection mechanism.\n
Yes, so there is the NSFileProtection encryption. However, the ability to use that to actually protect data depends on the user having a passcode lock enabled, and you can&#x2019;t test for that in your app. If you can&#x2019;t enforce that all of your users comply with a particular passcode policy, you must implement your own protection mechanism.\n
Yes, so there is the NSFileProtection encryption. However, the ability to use that to actually protect data depends on the user having a passcode lock enabled, and you can&#x2019;t test for that in your app. If you can&#x2019;t enforce that all of your users comply with a particular passcode policy, you must implement your own protection mechanism.\n
Yes, so there is the NSFileProtection encryption. However, the ability to use that to actually protect data depends on the user having a passcode lock enabled, and you can&#x2019;t test for that in your app. If you can&#x2019;t enforce that all of your users comply with a particular passcode policy, you must implement your own protection mechanism.\n
Yes, so there is the NSFileProtection encryption. However, the ability to use that to actually protect data depends on the user having a passcode lock enabled, and you can&#x2019;t test for that in your app. If you can&#x2019;t enforce that all of your users comply with a particular passcode policy, you must implement your own protection mechanism.\n
Yes, so there is the NSFileProtection encryption. However, the ability to use that to actually protect data depends on the user having a passcode lock enabled, and you can&#x2019;t test for that in your app. If you can&#x2019;t enforce that all of your users comply with a particular passcode policy, you must implement your own protection mechanism.\n
The main problem with creating any new crypto format is the chance that you&#x2019;ll introduce new vulnerabilities by misusing the crypto primitives, even if those primitives themselves are bug-free. Sidestep that risk and reduce development time by choosing an existing solution: but notice that solutions like GPG and OpenPGP have licensing restrictions that are incompatible with the app stores.\n
The main problem with creating any new crypto format is the chance that you&#x2019;ll introduce new vulnerabilities by misusing the crypto primitives, even if those primitives themselves are bug-free. Sidestep that risk and reduce development time by choosing an existing solution: but notice that solutions like GPG and OpenPGP have licensing restrictions that are incompatible with the app stores.\n
The main problem with creating any new crypto format is the chance that you&#x2019;ll introduce new vulnerabilities by misusing the crypto primitives, even if those primitives themselves are bug-free. Sidestep that risk and reduce development time by choosing an existing solution: but notice that solutions like GPG and OpenPGP have licensing restrictions that are incompatible with the app stores.\n
The main problem with creating any new crypto format is the chance that you&#x2019;ll introduce new vulnerabilities by misusing the crypto primitives, even if those primitives themselves are bug-free. Sidestep that risk and reduce development time by choosing an existing solution: but notice that solutions like GPG and OpenPGP have licensing restrictions that are incompatible with the app stores.\n
This basically just exists to let you know you&#x2019;re looking at the correct kind of file.\n
Don&#x2019;t spend too much time on this slide, you cretin :-P\n
Don&#x2019;t spend too much time on this slide, you cretin :-P\n
Don&#x2019;t spend too much time on this slide, you cretin :-P\n
Remember not to leak any information in the metadata that should be a secret. For example: keeping photographs of a protest confidential may not be enough for a user if the photo timestamp and geolocation make their attendance public.\n
Remember not to leak any information in the metadata that should be a secret. For example: keeping photographs of a protest confidential may not be enough for a user if the photo timestamp and geolocation make their attendance public.\n
Remember not to leak any information in the metadata that should be a secret. For example: keeping photographs of a protest confidential may not be enough for a user if the photo timestamp and geolocation make their attendance public.\n
Remember not to leak any information in the metadata that should be a secret. For example: keeping photographs of a protest confidential may not be enough for a user if the photo timestamp and geolocation make their attendance public.\n
\n
\n
\n
The point of the HMAC is to provide integrity checking. There&#x2019;s no real attack against AES in the case of tampered ciphertext - you can replace real data with garbage, but you can&#x2019;t replace real data with other real data. The point of this HMAC is that it&#x2019;s the quickest way to verify that the key was recovered correctly.\n
Notice that this is one of two choices: PKCS#7 padding is the other option.\n