trusted cloud hardware and advanced cryptographic solutions

Demonstration Lecture:Cyber Security (MIT Department)

Trusted cloud hardware and advanced cryptographic solutions

Andrei Costin

16th Nov 2016 Andrei Costin 2

Topic Prerequisites

● Security concepts

● Security-related concepts (e.g., entropy)

● Virtualization and Cloud Computing concepts

● Symmetric-key, Asymmetric-key, PKI cryptographic concepts

● Understanding of cryptographic algorithms (e.g., RSA, ECDSA, ECDH, AES, SHA256, HMAC/SHA256, PRNGs)

● Understanding Transport Layer Security (TLS)

● Cryptographic security standards (e.g., PKCS#11)


Agenda

● Problem Statement and Examples

● Key Terms and Concepts

● Trusted Cloud Hardware

● Advanced Cryptographic Solutions

● Conclusions


Problem Statement

● Requirements

– Security is of paramount importance

– Security almost always involves cryptography


Problem Statement (cont.)

● Problems

– Homemade cryptography is bad



● Problems

– Proper cryptography is nontrivial



● Problems

– Cryptographic keys/operations on end points is risky


Problem Statement (cont.)End Points● Large population of

– Mobile Devices

– Virtual Machines (VM)

– Embedded Devices/Sensors

● Assumed to be untrusted


Problem Statement (cont.)End Points and Risks

● High probability of compromise

● Flaws, vulnerabilities, and malware, at various layers

– Ownership layer

– Hardware layer

– OS layer

– Hypervisor layer

– VM and Application layer● Not the best place to generate keys/secrets

● Not the best place to store keys/secrets


Examples: Mobile Devices: Usage Scenarios and Requirements

● Outgoing email

– Cryptographic signature (sender's authenticity)

● Email signing private keys (e.g., PGP, GPG, S/MIME)


Examples: Mobile Devices: Usage Scenarios and Requirements

● Incoming email

– Decryption for sensitive data

● Email decryption private keys (e.g., PGP, GPG, S/MIME)


Examples: Mobile Devices: Usage Scenarios and Requirements● Create/View protected data

– Online/offline storage

● Symmetric encryption, decryption and signing– Shared symmetric keys

● Asymmetric decryption and signing– Private keys


Examples: Mobile Devices: Compromise Scenarios

● Attacker gets physical access to the mobile device

● Attacker gets backup data/image of the smartphone

● Directed crypto attacks

– Steals keys

– Affects the crypto subsystems● Plain design/implementation vulnerabilities

– In RNG layer

– Other layers


Examples: VMs: Usage Scenarios and Requirements

● HTTPS Server

– Decrypt HTTPS traffic

● HTTPS/SSL/TLS private keys, depending on SSL/TLS cipher-suite


Examples: VMs: Usage Scenarios and Requirements

● Audit logging

– Symmetric encryption and HMAC● Shared symmetric keys

– Asymmetric decryption and signing● Private keys


Examples: VMs: Compromise Scenarios

● Attacker gets to VM using vulnerability or misconfiguration in hypervisor/VM layer

● Attacker copies VM using insecure backup of VM image/snapshot


– Steals data and keys

– Affects the crypto subsystems of the device● Plain design/implementation vulnerabilities

– In hypervisor layer

– In VM layer

– In hardware layer

– E.g., Xen security bug prompts AWS Cloud reboot


Examples: Embedded Devices: Usage Scenarios, Requirements

● Status/sensor information from embedded devices

– Sign with private key

– Encrypt with shared symmetric key


Examples: Embedded Devices: Usage Scenarios, Requirements

● Verification and decryption of software/firmware updates

● Verification and decryption of commands

– Verify with public key

– Decrypt with shared symmetric key


Examples: Embedded Devices: Compromise Scenarios

● Attacker gets physical access to the embedded device

● Attacker gets a software/firmware image for the device


– Steals data and keys

– Affects the crypto subsystems of the device

– Knows weak crypto subsystems of the device

● Plain design/implementation vulnerabilities

More end nodes = More problems + More complexity


Agenda





● Conclusions


Key Terms and Concepts

● Trusted system

– A system whose failure may break a specified security policy

● Trusted Computing (TC)

– Technologies and standards intended to make computers safer, more reliable and less prone to viruses and malware, through hardware enhancements and associated software modifications

– Specified by Trusted Computing Group (TCG)



● Trusted Platform Module (TPM)

– Specialized security chip on an endpoint device/system● Stores RSA keys specific to the endpoint system● vTPM for virtualized environments● Tamper resistant



● Trusted Platform Module (TPM)

– Function● Secure random number generation● Keys storage and derivation● Used by OSes for:

– Data encryption– Secure/authenticated boot and root of trust– Hardware/platform authentication

– Cannot be added later (usually)

– Not scalable: 1 TPM = 1 endpoint device/system



● TCB = Trusted Computing Base: set of all HW/FW/SW components critical to system's security

● TEE = Trusted Execution Environment: secure area (code, data) of the main processor

● TSS = TCG Software Stack: software layer for application developers to use functions provided by a TPM

● TBS = TPM Base Services: software component that allows the Windows operating system and applications to use services provided by the TPM



● Example of how TSS, TBS, TPM and sensitive crypto material (e.g., OpenVPN keys) stack and interact



● Hardware Security Module (HSM)

– Specialized security HW (e.g., plug-in card/dongle, external appliances)

● vHSM for virtualized environments● CloudHSM for cloud setups● Dongle HSM for mobility solutions● Tamper resistant



● Hardware Security Module (HSM)

– Function● Secure random number generation● Securely generates, stores and manages

cryptographic keys and material for strong authentication and encryption

● Performs symmetric and asymmetric crypto-processing

– Can be added later, easy to scale


Trusted Cloud Hardware

● HSM deployed in Clouds

– Secure and Scalable

– Clean APIs

– Validated HSM HW

– Lower cost, easier maintenance



● HSM deployed in Clouds

– Secure and Scalable

– Clean APIs

– Validated HSM HW

– Lower cost, easier maintenance

From: Amazon AWS Documentation



● Cloud HSM roles and responsabilities

From: Amazon AWS Documentation


Agenda





● Conclusions


Advanced Cryptographic Solutions

● Cryptography as a Service (CaaS)

● Computing on Encrypted Data (Searchable Encryption)

● Attestation


CaaS (Cryptography as a Service)

● Cryptographic operations performed by a CaaS provider on behalf of a device-at-risk via web services APIs

● Cryptographic keys are stored within the CaaS provider

– Devices do not possess these keys at any time → much lower benefit for attacker

● Fits well with the Cloud Computing and Virtualization paradigms

● Variants

– Software-only (riskier)

– Hardware-enhanced (safer, higher security, higher costs)


Examples: CaaS

From “Cryptography as a Service” by Peter Robinson, RSAC 2013


CaaS

● Advantages

– Improved security● No important key or data on end points● Important key and data securely stored and

managed by CSP, HSM– Performance

● Offload crypto-processing to dedicated HSM hardware

● Scalable HSM arrays and web API calls in CaaS


CaaS

● Disadvantages

– All end nodes must authenticate to CaaS first

– Requires network connectivity● Certain scenarios do not allow connectivity● DoS on the Trusted Cloud Hardware provider

– More complex of the architecture

– Higher costs and hardware requirements

– Latency and performance penalty/overhead due to web APIs


Computing on Encrypted Data

● A direction in:

– Privacy-Preserving Computation (PPC)

– Multi-Party Computation (MPC)● Searchable Encryption (SE)

– Symmetric Searchable Encryption (SSE)

– Public-key Encryption with Keyword Search (PEKS)

– Private-key Searchable Encryption● Homomorphic Encryption (HE)

● Honey Encryption



● Why?

– Untrusted third-party search modules

– Untrusted remote/cloud storage● Storage outsourcing, mail gateways

– Risk of plain-text data compromise



● Requirements

– Store data externally

– Store data encrypted

– Search data easily● Avoid downloading everything then decrypt● Allow different entities to search data without providing access to

plain-text– Protect

● Retrieved data● Search query● Search query result



● Challenges

– Public key algorithms too slow for large data● Main interest in symmetric searchable encryption

– Classic encryption hides all the information● Server cannot/shouldn't search● Client must search



● Challenges

– Client must search● Client must download entire document/data

collection● Require Secure Indexes (SI) and two-layer searches

performed via trapdoors– A secure index is a data structure that allows a

querier with a ``trapdoor'' for a word x to test in O(1) time only if the index contains x



● Advantages

– Improved privacy

– Improved security● If nodes are compromised, only encrypted data is

leaked, no important keys and materials are leaked, thanks to (Cloud-)HSM



● Disadvantages

– Not standardized yet (NIST, FIPS)

– Searching stored documents linear with size of DB

– Adaptive attackers with search-queries can infer existing and future data


Examples: Computing on Encrypted Data

● Homomorphic Encryption


Examples: Computing on Encrypted Data

● Searchable Strong Encryption

From “Powerful Encryption and Key Management for Cloud Applications and Databases with CipherCloud and Gemalto”


Attestation

● The process of making a claim about properties of a target system by supplying evidence to a verifier system

● Target system's TPM creates a nearly unforgeable hash key summary of the hardware and software configuration

● This allows a third party (Cloud, HSM) to verify that the software has not been changed


Attestation: CaaS and HSM

● Endpoint attestation

– Attest: device hardware, (parts of) software/memory

– Uses device attestation certificates● E.g., TPM AIK = Attestation Identity Key

– CaaS/(Cloud)HSM confirms device manufacturer, model, serial number

– CaaS/(Cloud)HSM confirms device is not tampered with


Examples: Attestation

● Local attestation

From “Txt Introduction by SVG”



● Remote attestation

From “Vpn-info.com. Introduction to Trusted Platform Module.”



● VMs attestation in Cloud (e.g., Intel TXT/SGX)

From: “Intel TXT”



● Device attestation on Internet (e.g., ARM TrustZone)

From: “Samsung Knox ISV SDK”



● Untrusted components attestation (device, VM)

From: “SoftLayer brochure


Agenda





● Conclusions


Conclusions

● Cryptographic keys and operations on end nodes are risky

● Software-only solutions have limitations and vulnerabilities

● Hardware enhancements, such as TPM, HSM, can provide strong guarantees for trusted computing

● HSMs in particular are a scalable way towards trusted cloud hardware


Conclusions

● Trusted cloud hardware is a basic building block towards advanced cryptographic solutions

– CaaS paradigm can assure strong crypto primitives and guarantees even to the most limited end nodes with connectivity

– Searchable Encryption can assure that critical data is usable and still safe even after compromise, as critical crypto keys never leave trusted cloud hardware

– Attestation can assure that a platform is either in a trusted state (secure), or detected as untrusted (compromised)


Thank you!


End to end example


End to end example

● Time: Manufacturing

– Device is programmed with● Device ID (e.g., serial number)● Start-up Entropy (e.g., devices contrained)● Manufacturer public key (used for verification of

software/firmware/configuration updates)

● → Manufacturer puts bootstrap information onto device


End to end example

● Time: Installation

– Device gets software update:● Signed by private key of manufacturer (e.g., verify)● Contains provider public key

– Device can verify (control) messages from cloud– Provider can decrypt (data) messages from

device

● → Provider puts more bootstrap information onto device


End to end example


– Device authenticates to CaaS

– CaaS sends to device● Signed by private key of provider● Additional entropy (e.g., from (Cloud-)HSM) to support

strong crypto● Server's ephemeral EC details for ECDH key agreement● Can be encrypted with initial symmetric key (e.g.,

device id + pin)


End to end example


– Device sends to CaaS● Encrypted with public key of provider● Device's public key ● Device's ephemeral EC details fro ECDH agreement

– Device and CaaS use ECDH to derive a shared symmetric AES key

– Device has public key of provider

– CaaS has the public key of device

– Device and CaaS can communicate securely


End to end example

● Time: Usage

– CaaS/server to device:● AES symmetric encrypted control message● Signed by CaaS with CaaS private key● Verified by device with CaaS public key

– Device to CaaS/server:● AES symmetric encrypted status message● Signed by device with device private key● Verified by CaaS with device public key


End to end example

● VM has NO keys

● CaaS/server has keys

● Device has keys

– Device keys generated with help of CaaS/HSM

trusted cloud hardware and advanced cryptographic solutions

Documents