Upgrade to Pro — share decks privately, control downloads, hide ads and more …

10 lines of encryption, 1500 lines of key management

10 lines of encryption, 1500 lines of key management

Talk by Anastasiia Vixentael.

Этот доклад о security design & security architecture. Речь пойдет о реальном iOS/macOS приложении, в котором пользователи запросили end-to-end шифрование своих заметок, и о том, как Настя это реализовала.
Слушатели узнают, как сложно строить безопасную систему, которая не разрушает пользовательский UX. Ключевые слова: модель данных, модель угроз, разница между “data locking” и “data encryption”, разница между паролем и ключем шифрования, выбор криптобиблиотеки, недоверие к iOS Keychain, многоуровневые кэши, подготовка к инциденту, monotonic timer, defense in depth

This talk was made for CocoaHeads Kyiv #15 which took place Jul 28, 2019. (https://cocoaheads.org.ua/cocoaheadskyiv/15)

Video: https://youtu.be/CliAlRUqx14

CocoaHeads Ukraine

July 28, 2019
Tweet

More Decks by CocoaHeads Ukraine

Other Decks in Programming

Transcript

  1. @vixentael product engineer in security and cryptography OSS maintainer: Themis,

    Acra cryptographic tools, security engineering, datasec training
  2. @vixentael zero knowledge searchable encryption cossacklabs.com/acra/ e2ee data collaboration cossacklabs.com/hermes/

    zero knowledge authentication github.com/cossacklabs/themis/wiki/Secure-Comparator-cryptosystem cossacklabs.com/whitepapers/
  3. 1. Encryption: from GDPR to DoD @vixentael 2. Building security:

    decision making in security, boring crypto, defense in depth 3. E2EE note sharing 4. Cat
  4. GDPR @vixentael Article 32/35: responsibly store and process data according

    to risks
 
 Article 33/34: detecting data leakage and alert users & controller https://gdpr-info.eu/
  5. @vixentael Decision making in security 101 1. “just because we

    can” 3. understanding risks & threats 2. every app should have security features
  6. @vixentael Decision making in security 101 1. “just because we

    can” 3. understanding risks & threats 2. every app should have security features ✅
  7. risk & threat model security methods security controls libraries/ code

    app flow app features code user problem @vixentael
  8. @vixentael Data & risks PII User data Service data likes,

    preferences purchase history logs keys, accesses, API tokens backups configurations locations
  9. @vixentael Data & risks compliance risks legal risks reputational risks

    continuity risks User data Service data reputational risks medium.com/@cossacklabs/trick-or-threat-security-losses-for- business-f5b44243d89c
  10. — crypto that simply works, solidly resists attacks, never needs

    any upgrades https://cr.yp.to/talks/2015.10.05/slides-djb-20151005-a4.pdf Daniel J. Bernstein Boring crypto @vixentael
  11. @vixentael should be random should use KDF(key) uses AES CBC,

    not AES GCM padding? salt? @vixentael easy to make mistakes
  12. @vixentael hides cryptographic details: salt, IV, KDF, padding built-in KDF,

    safe to use passphrase uses AES-256-GCM @vixentael github.com/cossacklabs/themis Themis: hard to make mistakes
  13. Defense in depth – independent, yet interconnected, set of security

    controls aimed at mitigating multiple risks during the whole application flow @vixentael
  14. @vixentael 1. Encryption to protect data globally 
 (during the

    whole data flow / app lifecycle). 2. Whatever is the attack vector, there is a defense layer. 3. For most popular attack vectors, we want as many independent defenses as possible. Overlapped security controls
  15. @vixentael • smooth UX • not finance/banking app • syncing

    between all user’s devices • privacy • incident response • next versions: Web/Electron Bear e2ee for notes
  16. @vixentael 1. user notes encrypted using unique keys (per app

    per user) 2. user password is never stored in plaintext 3. data in Keychain encrypted 4. notes & passwords are synced between devices Results
  17. @vixentael UX is important, so we made the security scheme

    more complex from an engineering perspective, but less stressful for users
  18. @vixentael Access Disclosure Modification Access denial note text Moderate Critical

    Critical High user passphrase Moderate Critical Critical Critical note encryption key Moderate Low Low Moderate threats
  19. @vixentael Device filesystem Device process memory Device keychain & secure

    enclave Transport, iCloud database iCloud Keychain Medium High High Medium Medium trust model
  20. @vixentael We have more trust towards the data stored on

    the device than the data stored in a cloud
  21. @vixentael from user mind or password mngr cached for some

    time calculated before usage Keychain, Secure Enclave key model
  22. @vixentael multiple caches to minimize user distractions user Keychain SecureEnclave

    iCloudKeychain in memory cache temp var password manager
  23. @vixentael App encryption key Key stretching: PBKDF2, deterministic long_data =

    user_passphrase + generated_passphrase_password + generated_app_context app_encryption_key = SecureCellContextImprint(data: long_data, context: generated_app_context, key: user_passphrase)
  24. @vixentael long_data = user_passphrase + generated_passphrase_password + generated_app_context app_encryption_key =

    SecureCellContextImprint(data: long_data, context: generated_app_context, key: user_passphrase) long_data = app_encryption_key + generated_passphrase_password + generated_app_context note_encryption_key = SecureCellContextImprint(data: long_data, context: note_encryption_id, key: app_encryption_key) App encryption key, note encryption key Key stretching: PBKDF2, deterministic
  25. @vixentael data encryption encrypted_note = SecureCellSeal(data: note_text, context: note_encryption_id, key:

    note_encryption_key) decrypted_note = SecureCellSeal(data: encrypted_note, context: note_encryption_id, key: note_encryption_key) AES-256-GCM, random IV/nonce, non-deterministic
  26. @vixentael 1. Encryption to protect data globally 
 (during the

    whole data flow / app lifecycle). 2. Whatever is the attack vector, there is a defense layer. 3. For most popular attack vectors, we want as many independent defenses as possible. Overlapped security controls ✅
  27. @vixentael encrypted_passphrase = SecureCellSeal(data: user_passphrase, context: nil, key: generated_passphrase_key) decrypted_passphrase

    = SecureCellSeal(data: user_passphrase, context: nil, key: generated_passphrase_key) passphrase encryption https://www.youtube.com/watch?v=EUGDa0Z71uk https://www.youtube.com/watch?v=sR6KeCaCRMA https://github.com/LinusHenze/Keysteal remember about breaking keychain AES-256-GCM, random IV/nonce, non-deterministic https://thetapedrive.com/face-id-fail-ios-13
  28. @vixentael hint encryption encrypted_hint = SecureCellSeal(data: hint, context: nil, key:

    generated_hint_key) decrypted_hint = SecureCellSeal(data: encrypted_hint, context: nil, key: generated_hint_key) AES-256-GCM, random IV/nonce, non-deterministic
  29. @vixentael Auto-locking timer clean up caches and decrypted data after

    T seconds let unlockDate = Date() ... let unlockedInterval = unlockDate.timeIntervalSinceNow();
  30. @vixentael Auto-locking timer clean up caches and decrypted data after

    T seconds let unlockDate = Date() ... let unlockedInterval = unlockDate.timeIntervalSinceNow(); timezones
  31. 1. Encryption to protect data globally 
 (during the whole

    data flow / app lifecycle). 2. Whatever is the attack vector, there is a defense layer. 3. For most popular attack vectors, we want as many independent defenses as possible. Overlapped security controls ✅ ✅ ✅ @vixentael
  32. 1. Encryption: from GDPR to DoD @vixentael 2. Building security:

    decision making in security, boring crypto, defense in depth 3. E2EE note sharing 4. Cat
  33. @vixentael crypto gets harder if you need usability 1. E2EE

    for notes, synced between devices – Bear 2. Searchable encryption – Acra 3. E2EE for data collaboration – Hermes
  34. failure of single security control is a question of time

    failure of security system is a question of design