High Assurance Secure Software Development on the Server Side

Charles Hubain (LINE Plus / Security R&D Team / Senior Security Engineer)
Jonas Lejeune (LINE / Security R&D Team / Senior Security Engineer)

https://tech-verse.me/ja/sessions/70
https://tech-verse.me/en/sessions/70
https://tech-verse.me/ko/sessions/70

Transcript

2. Agenda 1. Background 2. Security Architecture 3. Hardware Security Module 4. Intel® Software Guard Extensions 5. Practical Considerations
3. Background
4. 1. Backing up Letter Sealing keys 2. Maintain End-to-End Encryption guarantees 3. Resist external and internal threats Background More details available in the "Easier and Safer LINE Account Transfer” session
5. Threat Model - Direct access to code, file and databases - Man-in-the-middle - Code backdoor - External threats - Attack through public APIs - Internal threats
6. Backup of Letter Sealing keys ✳ LINE Developer Day 2019: Seamless device migration using LINE secure backups LINE Client
7. Backup of Letter Sealing keys ✳ LINE Developer Day 2019: Seamless device migration using LINE secure backups LINE Client Backup Data
8. Backup of Letter Sealing keys ✳ LINE Developer Day 2019: Seamless device migration using LINE secure backups LINE Client User PIN Backup Data
9. Backup of Letter Sealing keys ✳ LINE Developer Day 2019: Seamless device migration using LINE secure backups LINE Client User PIN Public Key Backup Data
10. Backup of Letter Sealing keys ✳ LINE Developer Day 2019: Seamless device migration using LINE secure backups LINE Client LINE Server Backup server Encrypted Backup Internet User PIN Public Key Backup Data
11. Backup of Letter Sealing keys ✳ LINE Developer Day 2019: Seamless device migration using LINE secure backups LINE Client LINE Server Backup server Encrypted Backup Internet User PIN Public Key Private Key Backup Data
12. Backup of Letter Sealing keys ✳ LINE Developer Day 2019: Seamless device migration using LINE secure backups LINE Client LINE Server Backup server Encrypted Backup Internet User PIN Public Key Private Key Attempt counters Backup Data
13. External Threats Backup of Letter Sealing keys ✳ LINE Developer Day 2019: Seamless device migration using LINE secure backups LINE Client LINE Server Backup server Encrypted Backup Internet User PIN Public Key Private Key Attempt counters Backup Data
14. Internal Threats External Threats Backup of Letter Sealing keys ✳ LINE Developer Day 2019: Seamless device migration using LINE secure backups LINE Client LINE Server Backup server Encrypted Backup Internet User PIN Public Key Private Key Attempt counters Backup Data
15. Trusted Execution Environment Internal Threats External Threats Backup of Letter Sealing keys ✳ LINE Developer Day 2019: Seamless device migration using LINE secure backups LINE Client LINE Server Backup server Encrypted Backup Internet User PIN Public Key Private Key Attempt counters Backup Data
16. Security Architecture
17. Security Architecture
18. Security Architecture Mobile Device
19. Security Architecture Mobile Device Secure Service
20. Security Architecture Mobile Device Secure Service Service Private Key
21. Security Architecture Mobile Device Service Certificate (statically provisioned) Secure Service Service Private Key
22. Security Architecture Mobile Device Service Certificate (statically provisioned) Secure Service Service Private Key LINE Server Authenticated Secure Channel
23. Security Architecture Mobile Device Service Certificate (statically provisioned) Trusted Execution Environment Secure Service Service Private Key LINE Server Authenticated Secure Channel
24. Security Architecture Mobile Device Service Certificate (statically provisioned) Trusted Execution Environment Secure Service TEE Protected File Service Private Key LINE Server Authenticated Secure Channel
25. Security Architecture Mobile Device Service Certificate (statically provisioned) Trusted Execution Environment Secure Service TEE Protected File Service Private Key Code Signing Key LINE Server Authenticated Secure Channel
26. Security Architecture Mobile Device Service Certificate (statically provisioned) Trusted Execution Environment Secure Service TEE Protected File Service Private Key Code Signing Key Code Signature LINE Server Authenticated Secure Channel
27. Security Architecture Mobile Device Service Certificate (statically provisioned) Trusted Execution Environment Secure Service TEE Protected File Service Private Key Code Signing Key Code Signature ACL LINE Server Authenticated Secure Channel
28. Chain of Trust
29. Chain of Trust Service Certificate
30. Chain of Trust Service Certificate Service Private Key Authenticate with Client
31. Chain of Trust Service Certificate Code Signature Allow to Access Service Private Key Authenticate with Client
32. Chain of Trust Service Certificate Code Signing Key Sign Code Signature Allow to Access Service Private Key Authenticate with Client
33. Trusted Execution Environment Chain of Trust Service Certificate Code Signing Key Sign Code Signature Allow to Access Service Private Key Authenticate with Client
34. Root of Trust
35. Root of Trust - Code signing key becomes the root of trust
36. Root of Trust - Code signing key becomes the root of trust - Only the code signing key has to be protected
37. Root of Trust - Code signing key becomes the root of trust - Only the code signing key has to be protected - Can be protected offline with a high level of physical security
38. Root of Trust - Code signing key becomes the root of trust - Only the code signing key has to be protected - Can be protected offline with a high level of physical security - Can also be destroyed
39. Root of Trust - Code signing key becomes the root of trust - Only the code signing key has to be protected - Can be protected offline with a high level of physical security - Can also be destroyed ➡ Security by immutability
40. Trusted Execution Environment
41. Trusted Execution Environment - Hardware support for cryptographic features
42. Trusted Execution Environment - Hardware support for cryptographic features - Loading and executing signed code
43. Trusted Execution Environment - Hardware support for cryptographic features - Loading and executing signed code - Guarantee integrity and confidentiality
44. Trusted Execution Environment - Hardware support for cryptographic features - Loading and executing signed code - Guarantee integrity and confidentiality - Many implementations:
45. Trusted Execution Environment - Hardware support for cryptographic features - Loading and executing signed code - Guarantee integrity and confidentiality - Many implementations: - CPU feature: ARM® TrustZone®, Intel® SGX, …
46. Trusted Execution Environment - Hardware support for cryptographic features - Loading and executing signed code - Guarantee integrity and confidentiality - Many implementations: - CPU feature: ARM® TrustZone®, Intel® SGX, … - Dedicated chips: Apple® Secure Enclave, Google® Titan
47. Trusted Execution Environment - Hardware support for cryptographic features - Loading and executing signed code - Guarantee integrity and confidentiality - Many implementations: - CPU feature: ARM® TrustZone®, Intel® SGX, … - Dedicated chips: Apple® Secure Enclave, Google® Titan - Dedicated devices: Hardware Security Module
48. Hardware Security Module
49. Hardware Security Module
50. Hardware Security Module HSM are dedicated hardware performing cryptographic operations - Designed to manage and protect cryptographic keys - Usually certified to comply with security standards (FIPS 140, CC, …)
51. Hardware Security Module HSM are dedicated hardware performing cryptographic operations - Designed to manage and protect cryptographic keys - Usually certified to comply with security standards (FIPS 140, CC, …) High focus on the security of the device - Secure software implementations of cryptographic code - Resistance to side channel attacks (timing, power analysis, …) - Physical security is taken into account too - Sealed case, sensors to avoid probing, self-erasure feature, …
52. Hardware Security Module HSM are dedicated hardware performing cryptographic operations - Designed to manage and protect cryptographic keys - Usually certified to comply with security standards (FIPS 140, CC, …) High focus on the security of the device - Secure software implementations of cryptographic code - Resistance to side channel attacks (timing, power analysis, …) - Physical security is taken into account too - Sealed case, sensors to avoid probing, self-erasure feature, … Might provide a Trusted Execution Environment (TEE)
53. Main principles Main principles of an HSM - Keys are manipulated only within the HSM - Operations are done by requests to the HSM - Key usage restrictions with ACL - Trusted code is executed inside the HSM’s CPU HSM OS Crypto processor Application Key Key ID
54. Main principles Main principles of an HSM - Keys are manipulated only within the HSM - Operations are done by requests to the HSM - Key usage restrictions with ACL - Trusted code is executed inside the HSM’s CPU HSM OS Crypto processor Application Key Key ID Key ID Plain text
55. Main principles Main principles of an HSM - Keys are manipulated only within the HSM - Operations are done by requests to the HSM - Key usage restrictions with ACL - Trusted code is executed inside the HSM’s CPU HSM OS Crypto processor Application Key Key ID Key ID Plain text Key ID
56. Main principles Main principles of an HSM - Keys are manipulated only within the HSM - Operations are done by requests to the HSM - Key usage restrictions with ACL - Trusted code is executed inside the HSM’s CPU HSM OS Crypto processor Application Key Key ID Key ID Plain text Key ID Key
57. Main principles Main principles of an HSM - Keys are manipulated only within the HSM - Operations are done by requests to the HSM - Key usage restrictions with ACL - Trusted code is executed inside the HSM’s CPU HSM OS Crypto processor Application Key Key ID Key ID Plain text Key ID Plain text Key
58. Main principles Main principles of an HSM - Keys are manipulated only within the HSM - Operations are done by requests to the HSM - Key usage restrictions with ACL - Trusted code is executed inside the HSM’s CPU HSM OS Crypto processor Application Key Key ID Key ID Plain text Key ID Plain text Cipher text Key
59. Main principles Main principles of an HSM - Keys are manipulated only within the HSM - Operations are done by requests to the HSM - Key usage restrictions with ACL - Trusted code is executed inside the HSM’s CPU HSM OS Crypto processor Application Key Key ID Cipher text Key ID Plain text Key ID Plain text Cipher text Key
60. Operational Costs of HSM
61. Operational Costs of HSM Development complexity - Unusual development environment (CPU architecture, OS, …) - Suboptimal performances for general purpose computing
62. Operational Costs of HSM Development complexity - Unusual development environment (CPU architecture, OS, …) - Suboptimal performances for general purpose computing High availability and high performance required - Unit price of an HSM is high - Spare units needed quickly in case of hardware failures
63. Operational Costs of HSM Development complexity - Unusual development environment (CPU architecture, OS, …) - Suboptimal performances for general purpose computing High availability and high performance required - Unit price of an HSM is high - Spare units needed quickly in case of hardware failures Maintenance operations require physical presence - Might require several operators at the same time - Specific knowledge is required
64. Intel® Software Guard Extensions
65. Intel® Software Guard Extensions What is Intel® SGX - Intel® proposal for Trusted Computing directly in the CPU - Implemented as 18 new assembly instructions - Security critical code is signed and isolated in an enclave - Enclaves are totally isolated from other processes
66. Main principles Process SGX Enclave CPU
67. Main principles Process SGX Enclave CPU
68. Main principles Process SGX Enclave CPU
69. RAM Main principles Process SGX Enclave CPU
70. RAM Main principles Process SGX Enclave CPU
71. RAM Main principles Process SGX Enclave CPU
72. RAM Main principles Process SGX Enclave CPU
73. RAM Main principles Process SGX Enclave CPU I / O
74. Main principles Intel® SGX Developer Guide defines 3 objectives to have trusted computing: - Measurement: instantiation of the code in a trusted environment - Sealing: safe export of secret from the trusted environment - Attestation: provability that the code is running in a trusted environment
75. Measurement of code Instantiation of the code in a trusted environment - Enclaves are signed at compilation time - Signature is verified when the enclave is loaded by the CPU - Enclave code can only be accessed at well-defined entry points
76. Data Sealing Safe export of secrets from the trusted environment - SGX only guarantees the authenticity of the code, not its confidentiality - Enclave’s memory encryption is done with a random temporary key Impossible to provision or export secrets with these properties only.
77. Data Sealing SGX provides a way to safely export data: - CPUs are provisioned with a Root Sealing Key (RSK), fused in the silicon - The RSK cannot be accessed directly, even by enclaves - Enclaves can request a derivation of the RSK to get their sealing key
78. Sealing principles Trusted Environment Enclave
79. Sealing principles Trusted Environment Enclave Enclave Signer Attributes
80. Sealing principles Trusted Environment Enclave SGX password RSK Enclave Signer Attributes
81. Sealing principles Trusted Environment Enclave Sealing Key SGX password RSK Enclave Signer Attributes
82. Sealing principles Trusted Environment Enclave Sealing Key Data SGX password RSK Enclave Signer Attributes
83. Sealing principles Trusted Environment Enclave Sealing Key Sealed Data Data SGX password RSK Enclave Signer Attributes
84. Sealing principles Trusted Environment Enclave Sealing Key Sealed Data Data SGX password RSK Untrusted Environment Application External Storage Enclave Signer Attributes
85. Code Attestation Provability that the code is running in a trusted environment - Local attestation: attestation between 2 enclaves on the same machine - Remote attestation: attestation between an enclave and a remote 3rd party
86. Local attestation Local attestation Enclave A Enclave B 1 2 3 Machine with SGX - Performed between two enclaves running locally on the same machine - Takes advantage that the two enclaves share the same RSK - A secure channel can be established during the attestation process
87. Remote attestation Remote attestation - Performed between an enclave and a remote 3rd party - Requires a Quoting Enclave and an external Attestation Service to verify enclave’s report - A secure channel can be established during the attestation process Enclave Machine with SGX 3rd Party Client
88. Remote attestation Remote attestation - Performed between an enclave and a remote 3rd party - Requires a Quoting Enclave and an external Attestation Service to verify enclave’s report - A secure channel can be established during the attestation process Enclave Machine with SGX 3rd Party Client Quoting Enclave 1 2 3 4 5 Attestation Service
89. Practical Considerations
90. SGX Security Architecture Mobile Device SGX Enclave Secure Service SGX Sealed Data Service Private Key Mobile Client
91. SGX Security Architecture Mobile Device SGX Enclave Secure Service SGX Sealed Data Service Private Key Code Signing Key Mobile Client
92. SGX Security Architecture Mobile Device SGX Enclave Secure Service SGX Sealed Data Service Private Key Code Signing Key Code Signature Mobile Client
93. SGX Security Architecture Mobile Device SGX Enclave Secure Service SGX Sealed Data Service Private Key Code Signing Key Code Signature Sealing Key Derivation Mobile Client
94. SGX Security Architecture Mobile Device Attestation PKI SGX Enclave Secure Service SGX Sealed Data Service Private Key Code Signing Key Code Signature Sealing Key Derivation Mobile Client
95. SGX Security Architecture Mobile Device Attestation PKI SGX Enclave Secure Service SGX Sealed Data Service Private Key Code Signing Key Code Signature Enclave Attestation Sealing Key Derivation Mobile Client
96. SGX Security Architecture Mobile Device Attestation PKI SGX Enclave Secure Service SGX Sealed Data Service Private Key Code Signing Key Code Signature Enclave Attestation Sealing Key Derivation Authenticated Secure Channel Mobile Client
97. Are We More Secure?
98. Are We More Secure? - Reduce the attack surface
99. Are We More Secure? - Reduce the attack surface - Trusted Computing Base:
100. Are We More Secure? - Reduce the attack surface - Trusted Computing Base: Sum of components critical to security
101. Are We More Secure? - Reduce the attack surface - Trusted Computing Base: Sum of components critical to security - No need to trust the OS / user applications
102. Are We More Secure? - Reduce the attack surface - Trusted Computing Base: Sum of components critical to security - No need to trust the OS / user applications - Move security functions into hardware
103. Are We More Secure? - Reduce the attack surface - Trusted Computing Base: Sum of components critical to security - No need to trust the OS / user applications - Move security functions into hardware - Hardware attack cost is much higher
104. TCB Threats
105. TCB Threats - Hardware vulnerabilities
106. TCB Threats - Hardware vulnerabilities - Recent examples: ÆPIC leak, SEPROM bug, …
107. TCB Threats - Hardware vulnerabilities - Recent examples: ÆPIC leak, SEPROM bug, … - Cryptographic vulnerabilities
108. TCB Threats - Hardware vulnerabilities - Recent examples: ÆPIC leak, SEPROM bug, … - Cryptographic vulnerabilities - Side channel attacks
109. TCB Threats - Hardware vulnerabilities - Recent examples: ÆPIC leak, SEPROM bug, … - Cryptographic vulnerabilities - Side channel attacks - Insecure protocol design
110. TCB Threats - Hardware vulnerabilities - Recent examples: ÆPIC leak, SEPROM bug, … - Cryptographic vulnerabilities - Side channel attacks - Insecure protocol design - Memory vulnerabilities
111. TCB Threats - Hardware vulnerabilities - Recent examples: ÆPIC leak, SEPROM bug, … - Cryptographic vulnerabilities - Side channel attacks - Insecure protocol design - Memory vulnerabilities - Memory leaks
112. TCB Threats - Hardware vulnerabilities - Recent examples: ÆPIC leak, SEPROM bug, … - Cryptographic vulnerabilities - Side channel attacks - Insecure protocol design - Memory vulnerabilities - Memory leaks - Arbitrary code execution
113. TCB Threats - Hardware vulnerabilities - Recent examples: ÆPIC leak, SEPROM bug, … - Cryptographic vulnerabilities - Side channel attacks - Insecure protocol design - Memory vulnerabilities - Memory leaks - Arbitrary code execution Affect all TEEs, Can only mitigate
114. Back To Secure Development
115. Back To Secure Development - Cryptographic protocol design flaws
116. Back To Secure Development - Cryptographic protocol design flaws - Formal verification can help: proverif
117. Back To Secure Development - Cryptographic protocol design flaws - Formal verification can help: proverif - Memory vulnerabilities
118. Back To Secure Development - Cryptographic protocol design flaws - Formal verification can help: proverif - Memory vulnerabilities - Testing and Fuzzing helps
119. Back To Secure Development - Cryptographic protocol design flaws - Formal verification can help: proverif - Memory vulnerabilities - Testing and Fuzzing helps - Safer languages are better: Rust
120. Rust
121. Rust - Higher level abstraction than C
122. Rust - Higher level abstraction than C - Rich type system
123. Rust - Higher level abstraction than C - Rich type system - Advanced generic programming
124. Rust - Higher level abstraction than C - Rich type system - Advanced generic programming - Crates: module based dependency management
125. Rust - Higher level abstraction than C - Rich type system - Advanced generic programming - Crates: module based dependency management - Designed with security in mind
126. Rust - Higher level abstraction than C - Rich type system - Advanced generic programming - Crates: module based dependency management - Designed with security in mind - Compiler enforce memory safety, thread safety
127. Rust - Higher level abstraction than C - Rich type system - Advanced generic programming - Crates: module based dependency management - Designed with security in mind - Compiler enforce memory safety, thread safety - Native with bare metal support
128. Rust - Higher level abstraction than C - Rich type system - Advanced generic programming - Crates: module based dependency management - Designed with security in mind - Compiler enforce memory safety, thread safety - Native with bare metal support - Can be as fast as C
129. Rust - Higher level abstraction than C - Rich type system - Advanced generic programming - Crates: module based dependency management - Designed with security in mind - Compiler enforce memory safety, thread safety - Native with bare metal support - Can be as fast as C - Can be used to write firmware, drivers, SGX enclave, …
130. Rust at LINE
131. Rust at LINE - Currently only using it on the server application side
132. Rust at LINE - Currently only using it on the server application side - Excellent ecosystem for service development
133. Rust at LINE - Currently only using it on the server application side - Excellent ecosystem for service development - Started using it for SGX enclave
134. Rust at LINE - Currently only using it on the server application side - Excellent ecosystem for service development - Started using it for SGX enclave - Toolchains already exists: Apache Teaclave, Fortanix® EDP
135. Rust at LINE - Currently only using it on the server application side - Excellent ecosystem for service development - Started using it for SGX enclave - Toolchains already exists: Apache Teaclave, Fortanix® EDP - Easy to make your own
136. Rust at LINE - Currently only using it on the server application side - Excellent ecosystem for service development - Started using it for SGX enclave - Toolchains already exists: Apache Teaclave, Fortanix® EDP - Easy to make your own - Rust can output C compatible (FFI) object files
137. Rust at LINE - Currently only using it on the server application side - Excellent ecosystem for service development - Started using it for SGX enclave - Toolchains already exists: Apache Teaclave, Fortanix® EDP - Easy to make your own - Rust can output C compatible (FFI) object files - Rust nostd code can be linked with Intel SDK
138. Conclusions
139. Conclusions - Higher security assurance can be achieved on the server side
140. Conclusions - Higher security assurance can be achieved on the server side - TEE can help prevent insider threats
141. Conclusions - Higher security assurance can be achieved on the server side - TEE can help prevent insider threats - TEE can protect both data and code
142. Conclusions - Higher security assurance can be achieved on the server side - TEE can help prevent insider threats - TEE can protect both data and code - Multiple TEE implementation available
143. Conclusions - Higher security assurance can be achieved on the server side - TEE can help prevent insider threats - TEE can protect both data and code - Multiple TEE implementation available - Similar security architecture can be achieved
144. Conclusions - Higher security assurance can be achieved on the server side - TEE can help prevent insider threats - TEE can protect both data and code - Multiple TEE implementation available - Similar security architecture can be achieved - Choice will depend on cost, performance, regulations, …
145. Conclusions - Higher security assurance can be achieved on the server side - TEE can help prevent insider threats - TEE can protect both data and code - Multiple TEE implementation available - Similar security architecture can be achieved - Choice will depend on cost, performance, regulations, … - TEE TCB is still a target
146. Conclusions - Higher security assurance can be achieved on the server side - TEE can help prevent insider threats - TEE can protect both data and code - Multiple TEE implementation available - Similar security architecture can be achieved - Choice will depend on cost, performance, regulations, … - TEE TCB is still a target - Safer programming languages are required