End-to-end encryption with BEAM and Elixir

Transcript

1. of messages-in-transit Security
2. Mrinal Wadhwa CTO, Ockam mrinal github.com/ockam-network/ockam
3. Actor Model The
4. Start A C B Transition 1 Transition 2 Transition 3 Sense Act Infer
5. Edge Inference Start A C B Transition 1 Transition 2 Transition 3 Cloud Inference
6. Device Edge Cloud
7. of messages-in-transit Security
8. Messages, within modern applications, rarely flows over a single, direct, point-to-point transport connection. Client Server TCP
9. Client Server TCP
10. Client Load Balancer HTTP over TCP Server Server Server HTTP over TCP
11. Client API Gateway Microservice Microservice Microservice Microservice
12. Client Ingress Gateway Microservice Microservice Microservice Microservice Load Balancer
13. Client Microservice Microservice Microservice Microservice Message Broker
14. Client Microservice Microservice Microservice Microservice Externa l Message Broke r as a service
15. Client Microservice Externa l Message Broke r as a service External Service Microservice Microservice Microservice
16. Client Microservice Microservice Microservice Microservice Message Broker LPWAN Gateway Radio Protocol
17. Client Microservice Microservice Microservice Microservice Message Broker Edge Message Broker Microservice Microservice Microservice Microservice Data Center
18. of messages-in-transit Security
19. Messages, within modern applications, rarely flows over a single, direct, point-to-point transport connection.
20. THREAT DESIRED PROPERTY S Spoo fi ng identity Identi fi cation, Authentication T Tampering with data Integrity R Repudiation Non-repudiability (some applications desire the opposite) I Information disclosure Con fi dentiality D Denial of service Availability E Elevation of privilege Authorization Note that this model is very high level, there is massive amounts of nuance in dealing with each of the rows. The STRIDE threat model can help us evaluate every message.
21. Trust in Network Boundaries
22. Client Load Balancer HTTP over TCP Server Server Server HTTP over TCP
23. Client Microservice Microservice Microservice Microservice Message Broker
25. • The network is always assumed to be hostile. • External and internal threats exist on the network at all times. • Network locality is not sufficient for deciding trust in a network. • Every device, user, and network flow is authenticated and authorized. • Policies must be dynamic & calculated from as many sources of data as possible. Zero Trust in network perimeters. A zero trust network is built upon five fundamental assertions:
27. Transport Layer Security
28. Messages, within modern applications, rarely flows over a single, direct, point-to-point transport connection.
29. TLS is tightly coupled with the length and duration of the underlying TCP connection.
30. Data integrity and confidentiality guarantees are lost at every transport connection hop.
31. Principle of Least Privilege Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.” — Jerome Saltzer, Communications of the ACM, 1974 “
32. Trust is an application layer concern.
33. Secure Channels
34. Initiator Responder Shared Secret Shared Secret M1 M2 M3 The shared secret is then used as a key in Symmetric Key Cryptography to maintain con fi dentiality and integrity of application data. Application Data - Authenticated Encryption The entities involved use Public Key Cryptography to authenticate each other and agree on a shared secret. Authenticated Key Exchange D Secure Channel
36. TLS IP TCP Application
37. TLS TCP Application TCP Application Ockam Routing Ockam Secure Channels IP IP
38. TCP Application Ockam Routing Ockam Secure Channels IP
39. TCP Application Ockam Routing Ockam Secure Channels IP UDP WebSocket HTTP
40. TCP Application Ockam Routing Ockam Secure Channels IP UDP WebSocket HTTP Bluetooth LPWAN
41. Create a Worker
42. Create a Worker
43. Create a routable message.
44. Route the message.
45. Create a TCP transport listener
46. Create a TCP transport connection
47. Create a routable message.
48. Route the message.
53. End-to-end Encryption
54. THREAT DESIRED PROPERTY S Spoo fi ng identity Identi fi cation, Authentication T Tampering with data Integrity R Repudiation Non-repudiability (some applications desire the opposite) I Information disclosure Con fi dentiality D Denial of service Availability E Elevation of privilege Authorization Note that this model is very high level, there is massive amounts of nuance in dealing with each of the rows. The STRIDE threat model can help us evaluate every message.
55. Heart Rate Monitor Heart Rate Application
56. Heart Rate Monitor Heart Rate Application
57. Heart Rate Monitor Heart Rate Service Heart Rate Application
58. Heart Rate Monitor Heart Rate Service 80 bpm Heart Rate Application
59. Heart Rate Monitor Heart Rate Service 80 bpm Heart Rate Application
60. The phone may not be online all the time so the service also caches this data to deliver it later … Heart Rate Monitor Heart Rate Service 80 bpm Heart Rate Application
61. Heart Rate Monitor Heart Rate Service Transport Layer Security Transport Layer Security Since these devices have direct access to the internet, with TLS … Heart Rate Application
62. Heart Rate Monitor Heart Rate Service 80 bpm Transport Layer Security Transport Layer Security Heart Rate Application
63. Heart Rate Monitor Heart Rate Service 80 bpm 0x217c5111… Transport Layer Security Transport Layer Security Heart Rate Application
64. Heart Rate Monitor Heart Rate Service 80 bpm 0x217c5111… 80 bpm Transport Layer Security Transport Layer Security Heart Rate Application
65. Heart Rate Monitor Heart Rate Service 80 bpm 0x217c5111… 80 bpm 0x8621f842… Transport Layer Security Transport Layer Security Heart Rate Application
66. Heart Rate Monitor Heart Rate Service 80 bpm 0x217c5111… 80 bpm 0x8621f842… 80 bpm This type of setup is industry best practice. Transport Layer Security Transport Layer Security Heart Rate Application
67. Heart Rate Monitor Heart Rate Service 80 bpm 0x217c5111… 80 bpm 0x8621f842… 80 bpm But even when we manage to setup the channels correctly the data is still exposed to the service. 
 The service doesn’t need to know the contents of the message to route and cache messages (its primary job). Transport Layer Security Transport Layer Security Heart Rate Application
68. Heart Rate Monitor Heart Rate Application Heart Rate
69. Route on/off instructions. Connected Outlet Connected Outlet Application Connected Outlet Service
70. Route open/close instructions. Connected Lock Connected Lock Application Connected Lock Service
71. Route/Cache sensor data, alerts and videos. Camera Door Bell Camera Door Bell Application Camera Door Bell Service
72. Gateway Flood Warning Sensor Multiple transport protocols in the path of one message. TCP TCP Flood Monitoring System Sensors Vendor’s Service LPWAN
73. Gateway Flood Warning Sensor Flood Monitoring System Sensors Vendor’s Service Various protocols have various different secure channel designs. TLS TLS LPWAN
74. Gateway Flood Warning Sensor A secure channel that is decoupled from the transport layer connections. 
 The gateway and sensor vendor shouldn’t be exposed to application data. Flood Monitoring System Sensors Vendor’s Service
75. D D D … Devices … … Gateways … Lighting HVAC Water Monitoring Elevators Access Control Fire Safety Waste Parking … Vendor IoT Backends … System Integrator 1 Building Management System … SI IoT Backends … System Integrator 2 G G D D D D D D D D D D D D D D D D D D D D D G G G G G G G G G G G G G G Complexity & attack surfaces grow to be unmanageable. Proprietary data is leaked. Security becomes untenable.
76. D D D … Devices … … Gateways … Lighting HVAC Water Monitoring Elevators Access
78. Provable Change Events
79. Privacy contexts & Identity Profiles
80. Selective Disclosure
81. Anonymous Credentials
82. Trust Policies
83. Fleet Enrollment
84. Mrinal Wadhwa CTO, Ockam mrinal github.com/ockam-network/ockam