End-to-end data turnover

Buring zero-knowledge applications. A few words about the history of method, where we derive the inspiration from, a cutting line between fancy theoretical stuff and practically unbroken approaches, and a few words about the zero-knowledge backend encryption and rights management methodology we present.

Transcript

1. Eugene Pilyankevich Chief Technical Officer, Cossack Labs End-to-end data turnover: building zero knowledge applications
2. Sooner or later, everything will be broken (https://medium.com/cryptographic-engineering/everything-will-be-broken-e21f6391aebc)
3. Traditional model: Fort Knox
4. Traditional model: Fort Knox IDS Sensors Echelonized defences . . Well monitored and compartmented infrastructure . Access controls Strong authentication . . . IR teams with snipers and helicopter pads Independent, remote controlled audit logging . VAULT: 22 tons of steel-strong asset at rest protection . Traditional model: Fort Knox
5. Traditional model: Fort Knox • strong perimeter, firewalls • MFA & well-managed PKI • logging, monitoring and intrusion detection • data-in-motion, data-at-rest encrypted • strong ops & IR teams
6. Meanwhile, in reality $ masscan -p27017 0.0.0.0/0 > mongodbs.txt
 $ grep -oP '(?<=Host: )\S*’ > targets.txt $ test_mongo_auth.py < targets.txt 32059 targets without authentication found! Learn more about this peculiar case: https://blog.shodan.io/its-the-data-stupid/
7. What if there were no walls at all?
8. What do we want? 1. Use strongest access control. 2. Minimize trust; control trust. 3. Infinitely small attack surface.
9. Zero-knowledge software Software, which operates with client data without having unencrypted access to it.
10. 1. End-to-end encryption. 2. Granular keys, bound to data owners. 3. Attack surface is client only. Zero-knowledge software
11. Existing ZKS ideas Communication Processing Storage Connect people, servers, processes Control data exposure when processing it Store data securely
12. Some Servers Alice Bob HOSTILE INTERNET Communication
13. Communication E-mail: All client, exchange keys, encrypt & sign. 
 PGP, S/MIME, GnuPG. Messaging: Client crypto, infra matches keys.
 OTR, iMessage, Signal. Voice: Client crypto, socket relaying. ZRTP, Facetime, Signal.
14. Zoom into “Some servers” Listener Temporary storage Session state cache Key directory Outgoing message Incoming message Internal messaging bus Protected infrastructure
15. Realistic version Listener Temporary storage Session state cache Key directory Outgoing message Incoming message Internal messaging bus Key leak MiTM MiTM Session Hijack Message leak Flow change
16. ZKS Communications 1. Many end-to-end designs, it’s natural. 2. Forward secrecy as granular keys. 3. Attack surface is small: only currently decrypted objects.
17. Communication problems Building trust is hard. Communication metadata. Very specific cryptography.
18. Userland memory Kernel memory YOUR (POTENTIALLY COMPROMISED) SERVER Your process memory decryptor.decoded_key_block_buffer [PUBLIC_KEY_LENGTH:] ! ! ! Processes
19. Processes The less you decrypt the less you leak. Operating without decrypting. You don’t always need to use sensitive data.
20. Processes The less you decrypt the less you leak: - granular encryption - new keys per each grain - keys bound to function or user
21. Processes You don’t always have to decrypt data to search it or compare strings. (But it’s a bit risky)
22. Processes You don’t always need to use sensitive data: - indirect references - foresight & planning - conditional secrecy
23. Processes Hardware protection: - Secure enclave, Intel SGX, TrustZone - Run encrypted programs - Verify them, protect memory
24. ZKS Processes 1. Don’t decrypt or no end-to-end. 2. Limit decryption scope manually. 3. Attack surface is unpredictible.
25. Some Servers Alice Bob HOSTILE INTERNET Storage User Storage HOSTILE INTERNET App
26. Storage Encrypt on client, store on server. Problems with manipulating encrypted data. Problems with data exchange.
27. Storage In-browser: Clipperz, Crypton, Sesto, Mylar Storage apps: Tresorit, Sync, SpiderOak Databases: SQLServer, Google, CryptDB
28. Storage lessons Sharing/key discovery via ICE/TGDH. Rights management encrypt ACL (Tresorit DRM). File-based granularity works.
29. Storage problems In-browser crypto is weak. Client-side encryption limits server features. No serious sharing / RM / RPC / requests.
30. ZKS Storage 1. End-to-end encryption works, at cost 
 of easy sharing and management. 2. Key granularity and ownership are OK. 3. Attack surface is client only.
31. So, where we are?
32. Summary (1/2) Most existing ZKS are trying to incrementally improve existing schemes
33. Summary (2/2) Best ZKS schemes are thought from the ground up, only based on experience
34. Our research: Hermes
35. Design goals Enforce security cryptographically Reduce attack surface / breach perimeter Operate in ZKS threat model
36. Crypto framework Secure infrastructure Secure product Hermes Toughbase Your project Crypto & rights Use, manage Benefit
37. Def document DOC [ID, R1, …, Rn]
38. Def document Cust_ID Cust_FullName ActiveCard_1 ActiveCard_2 Email … … … … … ac264602 DWQMqLTcZxv6Tk89o6r4ew== iQynR0/au2L6A6gNhHH+vA== Null sarah.parker@gmail.com 9d8974ba WEes8zIJlJpu+Pw2jimnXQ== hKeWqv0wLzSYpUVs9e+i2w== 2TsNrq7MnomMXs7teIcTIg== mentaloid@aol.com c2548064 C7dmy5j2KwxRNOFHSMo0iw== Ja01Mgzcs5BnrxauCKqgyw== Null voidnull@yahoo.com 6216f8a7 ozII0wUZpU+ez7peNmAA8A== 2lSFu1MMfZHnwC2k1VfsIQ== Null eugene@cossacklabs.com … … … … …
39. Def document Cust_ID Cust_FullName ActiveCard_1 ActiveCard_2 Email … … … … … ac264602 DWQMqLTcZxv6Tk89o6r4ew== iQynR0/au2L6A6gNhHH+vA== Null sarah. 9d8974ba WEes8zIJlJpu+Pw2jimnXQ== hKeWqv0wLzSYpUVs9e+i2w== 2TsNrq7MnomMXs7teIcTIg== mental c2548064 C7dmy5j2KwxRNOFHSMo0iw== Ja01Mgzcs5BnrxauCKqgyw== Null voidnu 6216f8a7 ozII0wUZpU+ez7peNmAA8A== 2lSFu1MMfZHnwC2k1VfsIQ== Null eugene … … … … … R1 ID R2 R3 R4
40. Def document { “cust_id": "ac264602", "cust_full_name": "DWQMqLTcZxv6Tk89o6r4ew==", "cards": ["iQynR0/au2L6A6gNhHH+vA==", "Null"], "email": "sarah.parker@gmail.com" }
41. { “cust_id": "ac264602", "cust_full_name": "DWQMqLTcZxv6Tk89o6r4ew==", "cards": ["iQynR0/au2L6A6gNhHH+vA==", "Null"], "email": "sarah.parker@gmail.com" } Def document R1 ID R2 R3 R4
42. Def encrypted document ENC_DOC [ID, (ER1, K1), (ER2, K2), … (ERn, Kn)] (ERn, Kn): Encrypt Rn with secrey key Kn
43. Key distribution Bind rights to user’s keys.
 Minimize attack surface.
44. CryptoCRUD: Read USER1 grants USER2 read access to Rn: 
 
 PKWRAP(Kn, prU1, pubU2)
45. Crypto CRUD: Write USER1 grants USER2 write access to Rn: 
 
 PKWRAP(UTn, prU1, pubU2)
 
 Update tag: UTn ~ MAC(Rn)
46. Crypto CRUD additional Read/write rights applied to parent node X allows to: - grant CREATE rights underneath it: add ERn with 
 parent node X. - grant DELETE rights underneath it: update target 
 record with null ERn.
47. KeyStore KeyStore is all PKEs for all records within
 document. Not all records are equal.
48. CRUD, old friend CREATE READ UPDATE Add children to parent N DELETE Access to symmetric key Kn Can compute pre-stored MAC Update parent N without X
49. WAT
50. Hermes is a simple encrypted CRUD library, which enforces some ZKS decisions.
51. Roles Storage (recordset) Keystorage (keystore) Credential store (public keys)
52. What did we want? 1. Use unbreakable access control. 2. Minimize and control trust. 3. Infinitely small attack surface.
53. Guarantees (1/2) 1. Each record is protected by unique key. 2. Each record may have own access control policy. 3. Storage never processes data in clear text.
54. Guarantees (2/2) 4. Data access keys are separated from the data. 5. All sensitive information appear in clear text only in 
 user's/application's context. 6. Compromising a single entity from the system creates only very limited damage.
55. 1. End-to-end encryption. 2. Bind keys to data owners. 3. Attack surface is client only. Zero-knowledge software
56. 1. Plaintext only on client. 2. Access via personal key. 3. Attack surface is client only. Zero-knowledge Hermes
57. Important suggestions
58. Give up ownership Ownership leaks data!
 1. Generate Keystore and tags 2. Give your ‘non-owner’ key rights 3. Burn owner key.
59. Non-volatility Cust_ID Cust_FullName ActiveCard_1 ActiveCard_2 Email … … … … … ac264602 DWQMqLTcZxv6Tk89o6r4ew== iQynR0/au2L6A6gNhHH+vA== Null sarah. 9d8974ba WEes8zIJlJpu+Pw2jimnXQ== hKeWqv0wLzSYpUVs9e+i2w== 2TsNrq7MnomMXs7teIcTIg== mental c2548064 C7dmy5j2KwxRNOFHSMo0iw== Ja01Mgzcs5BnrxauCKqgyw== Null voidnu 6216f8a7 ozII0wUZpU+ez7peNmAA8A== 2lSFu1MMfZHnwC2k1VfsIQ== Null eugene … … … … … R1 ID R2 DELETE R4
60. Additional security • Use ZKP + ID indirection to protect
 sensitive IDs between different Hermes DBs • Use Secure Session to protect transport
61. Memory compartmentation HERMES CORE Crypter HSM fork() + OS IPC or encrypted channel if separate Hermes structures PK>SK>Data
62. Specialized records - For search tokenization - For signing - For interactive protocols
63. Using Hermes
64. You said client/server? CLIENT SERVER All crypto Data storage Log Verification
65. “SERVER” “CLIENT” Simple scheme HERMES APP STORAGES
66. APP HERMES CORE HERMES API HERMES STORAGE 
 COMPONENTS STORAGE Crypter KeyStore CredentialStore / PKI RecordStore
67. Client ideas Client != person; client = role.
 
 We have ‘db indexer’ role key, for example.
68. Try it yourself! https://goo.gl/forms/7Qmm3GHLCjlozyzC3
69. Summary
70. Platforms, not single solutions. https://www.scmagazine.com/the-failure-of-the-security-industry/article/536707/
71. No need to talk about algorithms when you have Themis * * www.github.com/cossacklabs/themis
72. Client encryption needs stronger clients.
73. The Internet era of fun and games is over, Bruce Schneier said. Things that look like future have to become your new norm.
74. cossacklabs.com 
 ivychapel.ink Thank you for your time! @9gunpi