Secure TLS 1.3 deployment based on Trusted Execution Environment (TEE) (SGX) - QC-144
Preferred Disciplines: Computer science, Network security, Formal verification (Masters)
Company: Ericsson Canada
Project Length: 18 months (3 units ; Master fellwoship)
Desired start date: As soon as possible
Location: Montreal, QC
No. of Positions: 1
Preferences: Language: English or Bilingual
Ericsson as a major international telecom operator, and one of the top ten R&D investors in Canada, is both cloud service provider and cloud user. As a cloud service provider, investing over a billion dollars in building a massive ICT R&D center in Quebec, it is very important for Ericsson to have contingency plans for Disaster Recovery in place. Ericsson has also demonstrated its corporate responsibility for energy efficient and green solutions based on a long history of research in energy consumption and Life Cycle Assessment (LCA).
The usage of security protocols such as TLS or IPsec in order to secure a communication between two nodes relies on security credentials, which are implicitly assumed to be maintained in a secure place. In the case of a web server using TLS such assumption is fulfilled by having a Hardware Security Module (HSM) attached to the TLS server. Unfortunately, the model where the owner of the web server that owns the security credentials and the cloud provider hosting the web server represent the same entity is not widely considered anymore. Typically, the following examples illustrate the problem and the approach the current project is considering.
Our specific use-case considers the deployment of complex services composed of multiple containers or Virtual Machines (VMs) that securely communicate using TLS. These services may be deployed over untrusted infrastructure. In such scenario, the main challenge is to be able to keep the security credentials secret from the cloud provider while being able to deploy and run the service on the cloud infrastructure. Therefore, the purpose of this project is to define the interface to a cryptographic service that protects the usage of the security credentials. In addition, the cryptographic service is expected to be hosted in trusted execution environments, securely and remotely provisioned.
The project is focused on the Little Usage of Remote Keys (LURK) architecture. The Lurk architecture aims at splitting the cryptographic operations necessary to set TLS sessions within a Key Server from the remaining part of the service. The cryptographic service must provide some interface to protect the security credentials (private key) and prevent unintentional usage of the private key. This includes the ability to replay an exchange.
There is ongoing work for TLS 1.2 and a proof of concept. The project is willing to:
- Extend LURK for TLS 1.3
- Formally analyze the security model using Proverif / Tamarin
- Evaluate performance associated with LURK deployed in Trusted Execution Environment (TEE) – Typically SGX as well as TEE provisioning protocols
The intention is to bring this work to the IETF both by the RFC publication and the IETF Hackathon, as well as to publish code and results with scientific publications.
Design TLS1.3 cryptographic service and a LURK extension. The design will include formal verification of the specification as well as a performance analysis of the implementations (SGX and non SGX). The results will also be positioned and analyzed toward other mechanisms.
The goal is to be involved in team work to produce conference papers, IETF standard, IETF hackathon as well as open source code.
Expertise and Skills Needed:
The candidate is NOT expected to be familiar with all these technologies. Based on the skills or expertise, she/he will be assigned tasks that match the skills and willingness to learn.
- MOTIVATION (mandatory!)
- Programing language: Python3, C
- TLS programing: openssl or TLS 1.3 implementation
- Trusted Execution Environment (TEE) SGX
- Formal security analysis: Tamarin/ Proverif
For more info or to apply to this applied research position, please