VICTORIA UNIVERSITY OF WELLINGTON Te Whare W¯ananga o te ¯ Upoko o te Ika a M¯aui
School of Engineering and Computer Science Te Kura M¯atai P ¯ukaha, P ¯urorohiko
PO Box 600 Wellington New Zealand
Tel: +64 4 463 5341 Fax: +64 4 463 5045 Internet: office@ecs.vuw.ac.nz
Cloud Key Management
Sriram Venkatesh Supervisor: NOT STATED
Submitted in partial fulfilment of the requirements for Master of Computer Science.
Abstract A short description of the project goes here.
Acknowledgments
Any acknowledgments should go in here, between the title page and the table of contents.
The acknowledgments do not form a proper chapter, and so don’t get a number or appear in the table of contents.
i
ii
Contents
1 Introduction 1
1.1 Motivation . . . 1
1.2 Problem . . . 1
1.3 Contributions . . . 1
2 Background 3 2.1 Security System . . . 3
2.1.1 What defines a secure system? . . . 3
2.1.2 Cryptographic Basics . . . 3
2.1.2.1 Symmetric Encryption . . . 4
2.1.2.2 Asymmetric Cryptography . . . 4
2.1.3 Basic Key Management . . . 4
2.1.4 Trust . . . 5
2.1.5 Authentication . . . 5
2.1.6 Authorization . . . 5
2.1.7 Access Control . . . 5
2.2 Key Management . . . 5
2.2.1 What is Key Management? . . . 5
2.2.2 Importance of Key Management . . . 5
2.2.3 Public Key Infrastructures . . . 5
2.3 Defining the Cloud . . . 5
2.3.1 Cloud Service Models . . . 5
2.3.2 Security in the Cloud . . . 5
2.4 Vendors . . . 5
2.4.1 Amazon Web Services . . . 5
2.4.2 Luna SA . . . 5
2.4.3 DNSSEC . . . 5
3 Problem Domain 7 3.1 Description of Baseline model . . . 7
3.2 Threat Modeling . . . 7
3.2.1 OWASP Threat Modeling Technique . . . 7
3.3 Application Architecture . . . 7
3.3.1 User Roles . . . 7
3.3.2 Key Retrieval . . . 7
3.3.3 Key Bootstrapping . . . 7
3.4 Trust Model . . . 7
3.4.1 Application Assumptions . . . 7
3.4.2 Power of attacker . . . 7
3.5 Threat Scenario Evaluation . . . 7 iii
3.5.1 Threat Analysis . . . 7
3.5.2 Threat Matrix . . . 7
4 Possible Solutions 9 4.1 Eso . . . 9
4.1.1 What is Eso? . . . 9
4.1.2 System Process . . . 9
4.1.2.1 Key Retrieval . . . 9
4.1.2.2 Key Bootstrapping Process . . . 9
4.1.2.3 Key Revocation . . . 9
4.1.3 Security Analysis . . . 9
4.1.3.1 System Threats . . . 9
4.1.3.2 Threat Model Evaluation . . . 9
4.2 CloudHSM . . . 9
4.2.1 What is CloudHSM? . . . 9
4.2.1.1 What is a HSM? . . . 9
4.2.1.1.1 . . . 9
4.2.2 System Process . . . 10
4.2.3 Architectural Overview . . . 10
4.2.4 Role Based Access Controls . . . 10
4.2.4.1 Key Retrieval . . . 10
4.2.4.2 Key Bootstrapping Process . . . 11
4.2.4.3 Key Revocation . . . 11
4.2.5 Security Analysis . . . 11
4.2.5.1 System Threats . . . 11
4.3 SoftHSM . . . 12
4.3.1 What is SoftHSM? . . . 12
4.3.2 System Process . . . 12
4.3.3 Architectural Overview . . . 12
4.3.3.1 Key Retrieval . . . 12
4.3.3.2 Key Bootstrapping Process . . . 12
4.3.3.3 Key Revocation . . . 12
4.3.4 Security Analysis . . . 12
4.3.4.1 System Threats . . . 12
4.3.4.2 Threat Model Evaluation . . . 12
5 Implementation 13 5.1 Program Architecture . . . 13
5.1.1 Scenario . . . 13
5.1.2 High Level Overview . . . 13
5.1.3 Process Overview . . . 13
5.1.4 Key Bootstrap Process . . . 13
5.1.5 Key Retrieval Process . . . 13
5.1.5.1 Credential Storage . . . 13
5.1.5.2 Design . . . 13
5.2 Experimental Design . . . 13
5.2.1 Performance Metrics . . . 13
5.2.2 Comparison with traditional use case . . . 13 iv
6 Evaulation 15
6.1 Security Threat Matrix Evaluation . . . 15
6.2 Results and Findings . . . 15
6.2.1 Security Analysis . . . 15
6.2.2 Performance Tests and Comparaison . . . 15
6.3 Costing Analysis . . . 15
7 Conclusions 17
v
vi
Figures
vii
viii
Chapter 1
Introduction
1.1 Motivation 1.2 Problem
1.3 Contributions
1
2
Chapter 2
Background
2.1 Security System
2.1.1 What defines a secure system?
Before someone can determine whether something is secure or not, we have to first create a baseline for what is a secure system. In computer security, a typical approach is to require confidentiality, integrity, access control, availability, authentication and non-repudiation in the system[?].
These six attributes are described as follows:
1. Confidentiality is to ensure that secret information is never disclosed to unauthorized entities.
2. Access Control is to ensure that authorized entities are granted permissions to the resource.
3. Integrity is to ensure that data will not be corrupted.
4. Availability is a guarantee of accessibility of data in the system.
5. Authentication is the ability to verify the identity of an entity.
6. Non-repudiation means that one cannot claim that certain actions were never per- formed. For example, if a message is transmitted or the act of signing the message.
Although it is important to consider all these security attributes when designing a web ap- plication, its not always possible or necessarily required that all six attributes be fulfilled completely.
2.1.2 Cryptographic Basics
The basic aim of cryptography is to enable two people to communicate over an insecure chan- nel in a secure way. The term cryptography describes a range of cryptographic services including techniques for providing both confidentiality and authentication.
3
2.1.2.1 Symmetric Encryption
Symmetric Encryption, has a single secret key that it can use to encrypt plaintext. Then using the same secret key another user can decrypt it [?]. Symmetric key encryption is an essential mechanism for protecting data at rest. We can use this to reduce the risk of unauthorized access to sensitive data. However, the use of symmetric key encryption brings with it certain dangers. Most important is that, once encrypted, we need a robust mechanism to ensure the encryption key is protected from unauthorized access. The key management system needs to grant access to trust worthy entities, and restrict unauthorized entities to ensure that the key is secure.
2.1.2.2 Asymmetric Cryptography
Asymmetric Cryptography is a cryptographic algorithm which requires two separate keys, one of which is private and one which is public [?].
The public and private key pair comprise of two uniquely related cryptographic keys. The public key is made available to everyone via a publicly accessible repository or directory.
While on the other hand the private key must remain confidential to its respective owner. Be- cause the key pair is mathematically related, the public key is used to encrypt the plaintext, whereas the private key is used to decrypt the ciphertext produced by the public key. There- fore, Asymmetric cryptography can provide confidentiality, as the user with the private key is only one able to decrypt the message [?].
2.1.3 Basic Key Management
Encryption Key Management is the administration of tasks involved with protecting, stor- ing, backing up and organizing encryption keys or secrets. [?]. It considers the general management of cryptographic keys, and the means by which public keys are distributed.
The study of key management can be broken down into phases concerning the life-cycle of a cryptographic key. These four phases are:
1. Key Generation which covers the creation of the keys
2. Key Establishment which is the methods by which the keys are distributed to the relevant users in the network.
3. Key Update which the techniques used to renew or refresh the keys in the system 4. Key Destruction which covers the deletion and disposal of keys when they are no
longer of use.
Establishing and distributing keys over an unsecured channel is an important considera- tion to make. An elegant and widely-applied scheme for establishing a shared key across an insecure channel is the Diffie-Hellman key exchange. The Diffie-Hellman key exchange is a specific method of exchanging cryptographic keys. The Diffie-Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communication channel.
4
2.1.4 Trust
2.1.5 Authentication 2.1.6 Authorization 2.1.7 Access Control
2.2 Key Management
2.2.1 What is Key Management?
2.2.2 Importance of Key Management 2.2.3 Public Key Infrastructures
2.3 Defining the Cloud
2.3.1 Cloud Service Models 2.3.2 Security in the Cloud
2.4 Vendors
2.4.1 Amazon Web Services 2.4.2 Luna SA
2.4.3 DNSSEC
5
6
Chapter 3
Problem Domain
3.1 Description of Baseline model 3.2 Threat Modeling
3.2.1 OWASP Threat Modeling Technique
3.3 Application Architecture
3.3.1 User Roles 3.3.2 Key Retrieval 3.3.3 Key Bootstrapping
3.4 Trust Model
3.4.1 Application Assumptions 3.4.2 Power of attacker
3.5 Threat Scenario Evaluation
3.5.1 Threat Analysis 3.5.2 Threat Matrix
7
8
Chapter 4
Possible Solutions
4.1 Eso
4.1.1 What is Eso?
4.1.2 System Process 4.1.2.1 Key Retrieval
4.1.2.2 Key Bootstrapping Process 4.1.2.3 Key Revocation
4.1.3 Security Analysis 4.1.3.1 System Threats
4.1.3.2 Threat Model Evaluation
4.2 CloudHSM
4.2.1 What is CloudHSM?
To define a CloudHSM, we must first understand what is a Hardware Security Module (HSM) is, and how it functions.
4.2.1.1 What is a HSM?
A HSM is a dedicated secure coprocessor that is designed for the management of the key during the keys’ lifecycle. HSM act as trust anchors that protect the cryptographic functions of an application by securely managing, processing and storing crytopgraic keys inside a hardend, tamper resistant hardware device. A HSM does not output decrypted data or decrypted program instructions on the bus except in encrypted form, therefore this means it can assume a level of security to protect itself from eavesdropping or emission attacks. There are also protections, whereby memory is zeroed when attempts of probing or scanning are sensed.
4.2.1.1.1
9
4.2.2 System Process
4.2.3 Architectural Overview 4.2.4 Role Based Access Controls
• Each HSM partition has a special access control role called the ”Owner”
• Access to destructive HSM commands (init) can be only be done if via the admin in- terface which is only available through the SCLI (i.e it is not permitted via Network Trust Link)
The standard administrative roles associated with the Luna appliance and HSM are:
Admin, who has the possibility to perform all possible commands.
Operator who can perform a subset of commands, including some that affect the state of the appliance or its HSM.
Monitor who can perform observational commands only, but cannot affect the state or con- tents of the appliance or its HSM
4.2.4.1 Key Retrieval
Each HSM Client is assigned one or more specific HSM partition, and they communicate with the CloudHSM interface via a ”Network Trust Link” and authenticate with a digital certificate exchange and unique HSM partition challenge.
The Network Trust Link is a layer built on top of SSL that provides a secure transport of information between the HSM Client and CloudHSM. The network trust link compromises of three parts:
• The network trust link server, which is hosted via the CloudHSM.
• Network Trust Link Agents, which is installed on the client server
• Network Trust Link, is the secure connection that connects between the network trust link server and agent.
This Network Trust Link uses a two way digital certificate authentication, and SSL data en- cryption to protect the information flow between the HSM client and CloudHSM. The SSL protocol used within the network trust link used to connect the Network Trust Link agent and server creates a trusted secure channel for communication. Any application running an agent will be able to connect to the HSM via the network trust link.
AuthenticationThe HSM has a three layer authentication scheme that is used to authenti- cate and role based access control model to achieve high level of security between the client processes and HSM partitions. This important as the CloudHSM is different from the tradi- tional HSM due to the fact that the HSM now exposes a network API to communicate and offer cryptographic functions.
The three layers are:
10
1. HSM Partiion Activation: An HSM partion within the HSM remains inaccessible to clients until an administrator logs on and explicitly activates an HSM partition. HSM activation requires authentication with a password
2. Network Trust Link Activation Before an application can connect to the HSM. The administrator must authorize access for the client to access the HSM. The registra- tion involves a generation of a self signed certificate on the server which is bound to the host name and IP address. After the client creates the certificate, the client and the HSM exchange their certificates via a ”secure file transfer process”. After this ex- change the admin with register the certificate using against the HSM.Once this process is complete, the client is able to create a network trust link.
3. To gain access to the data within the HSM partition, an application process running must first provide an HSM partion password to te LUNA sa. The password is gener- ated during the creation of the HSM partion. The agent running the client machine, combines the password with a unique one time challenge. The application the login is a normal process of providing a password via the API call, and the additional secu- rity provided by the one-time challenge mechaninism is internal to the Network Trust Link.
4.2.4.2 Key Bootstrapping Process 4.2.4.3 Key Revocation
4.2.5 Security Analysis 4.2.5.1 System Threats
The thing to note here is that this process ensures that the key material we are protecting and placing in our HSM (in our case the private key used to encrypt/decrypt our database password) is kept safe. This is because the key material does not leave the HSM partition. In other words, the key material is not exposed within the network trust link. So, if an attacker is able to obtain the client’s SSL private key it DOES NOT pose a risk to the security of the key material stored in the HSM. However, because we store the private key that is used to encrypt the database password, it does not matter. This is because if the attacker has the SSL private key, he is able to make an authenticated response, to decrypt the password using the private key stored in the HSM.
Upon reading some documentation on the Luna’s HSM. It mentioned that an attacker must have logical network access to steal the private key and certificate in order to move them to another platform. And, highlighted that it is necessary to have physical access to configure the network in order to masquerade as legitimate client on the network. This process seems to hide the fact, that we are working in a cloud environment. In this cloud environment we have a virtulized instances which can be easily replicated, and do not require physical access to the clients. This means that one of the assumptions that Luna make conflicts with the assumptions made when moving such an process to the cloud.
Another problem faced with model is that there is no control over malicious applications that can be executed on a legitimate server where a client is located. This stems from the fact, there are not any low level authentication mechanisms that could be used to uniquely identify different applications if they are run by user, as all authenicated checks are checked via the a verfication of user of the calling process,
11
4.3 SoftHSM
4.3.1 What is SoftHSM?
4.3.2 System Process
4.3.3 Architectural Overview 4.3.3.1 Key Retrieval
4.3.3.2 Key Bootstrapping Process 4.3.3.3 Key Revocation
4.3.4 Security Analysis 4.3.4.1 System Threats
4.3.4.2 Threat Model Evaluation
12
Chapter 5
Implementation
5.1 Program Architecture
5.1.1 Scenario
5.1.2 High Level Overview 5.1.3 Process Overview 5.1.4 Key Bootstrap Process 5.1.5 Key Retrieval Process 5.1.5.1 Credential Storage 5.1.5.2 Design
5.2 Experimental Design
5.2.1 Performance Metrics
5.2.2 Comparison with traditional use case
13
14
Chapter 6
Evaulation
6.1 Security Threat Matrix Evaluation 6.2 Results and Findings
6.2.1 Security Analysis
6.2.2 Performance Tests and Comparaison
6.3 Costing Analysis
15
16
Chapter 7
Conclusions
The conclusions are presented in this Chapter.
17
18
Bibliography
19
