"LURK"
Project description
pylurk
implements the Limited Use of Remote Keys (LURK) framework as well as it extension for TLS 1.3.
LURK is a generic protocol whose purpose is to support specific interactions with a given cryptographic material, which is also known as Cryptographic Service (CS). This module provides a framework for LURK as well as defines the CS for TLS 1.3 - including both a TLS client and a TLS server. The current module doesn't integrate the LURK extension that was defined for TLS 1.2 and while the two LURK framework do share a number of lines of codes, this version of LURK has undergone a major rewrite.
This module implements the specifications detailed in draft-mglt-lurk-lurk for LURK as well as in draft-mglt-lurk-tls13 for its TLS 1.3 extension.
It has been proven that splitting the TLS 1.3 into to sub services namely a TLS Engine (E) and a CS interacting via LURK does not weaken the TLS 1.3 security. As result, running the CS into a TEE environment provides hardware base protection to the authentication credentials and is perceived as a way to enforce additional trusted to TLS. In particular, it enables a service provider to run an infrastructure on a public cloud while keeping the authentication credential private - that is not sharing them with the cloud provider.
+----------------------------+
| TLS Engine (E) |
+------------^---------------+
| (LURK/TLS 1.3)
+------------v---------------+
| Cryptographic Service (CS) |
| private_keys |
+----------------------------+
TLS being split into a CS and an Engine
pylurk
implements the CS as a library, a TCP server or a persistent TCP server.
Both TCP servers are able to run into an SGX enclave using Gramine.
pylurk
provides in examples/cli
the crypto_service
to start the CS in various modes.
The CS can be started with all default parameters by simply typing:
$ cd example/cli
$ ./crypto_service
--- Executing: pylurk.git/example/cli/./crypto_service with Namespace(connectivity="'tcp'", host="'127.0.0.1'", port=9400, sig_scheme="'ed25519'", key=None, cert=None, debug=False, test_vector_mode=None, test_vector_file=None, gramine_sgx=False, gramine_direct=False, gramine_build=False)
cmd: ./start_cs.py --connectivity tcp --host 127.0.0.1 --port 9400 --sig_scheme ed25519 --key pylurk.git/example/cli/sig_key_dir --cert /home/mglt/gitlab/pylurk.git/example/cli/sig_key_dir
mglt@nuc:pylurk.git/example/cli$ --- Executing: pylurk.git/example/cli/./start_cs.py with Namespace(connectivity="'tcp'", host="'127.0.0.1'", port=9400, sig_scheme="'ed25519'", key=PosixPath('pylurk.git/example/cli/sig_key_dir'), cert=PosixPath('pylurk.git/example/cli/sig_key_dir'), debug=False, test_vector_mode=None, test_vector_file=None, gramine_sgx=False, gramine_direct=False, gramine_build=False)
cs_template_conf: {'log': None, 'connectivity': {'type': 'tcp', 'ip': '127.0.0.1', 'port': 9400}, ('tls13', 'v1'): {'sig_scheme': ['ed25519'], 'public_key': [PosixPath('pylurk.git/example/cli/sig_key_dir')], 'private_key': PosixPath('pylurk.git/example/cli/sig_key_dir'), 'debug': {'trace': False}}}
pylurk.git/example/cli/sig_key_dir is not a file but a directory
WARNING: Generating new keys
- private_file: pylurk.git/example/cli/sig_key_dir/_Ed25519PrivateKey-ed25519-pkcs8.der
- public_file: pylurk.git/example/cli/sig_key_dir/_Ed25519PublicKey-ed25519-X509.der
Configuration Template (from end user arguments ):
By default, the CS is started as a TCP server on port 9400. Unless detected, the key is automatically generated, by default following the signature scheme ed25519.
To start the CS in a SGX enclave, one need first to make sure Gramine is installed, then build the enclave (with --gramine_build
) and then start the enclave (with --gramine_direct
).
For a complete detail of the options type ./crypto_service --help
.
pylurk
depends on pytls13
that defines all the necessary TLS 1.3 message structures and in return implements all TLS 1.3 cryptographic operations.
As a result the usage of the CS is extensively described in the documentation of the pytls13
module where the EPID attestation is described in a step-by-step approach.
Installation
Currently there is no pip3 package, so one need to install it manually.
- Install Gramine (if you want to use SGX)
- Install
pytls13
.pylurk
is highly depend onpytls13
sopytls13
needs to be installed. This is currently done by git clone the repositorygit clone https://github.com/mglt/pytls13
- Git clone the repository
git clone https://github.com/mglt/pylurk tls13
- Update in
crypto_service
,lurk_ping
,start_cs.py
,secret_prov_service
the following environment variables:
CS_GRAMINE_DIR
: the location of thepylurk.git/example/cli
directoryGRAMINE_DIR
the directory of the Gramine directory- The path of the
pylurk
andpytls13
modules indicated by thesys.path.insert
directive.
TODO:
- Build a proper packages that we can install using
pip3 install pylurk
. Thi s includes:- integrating the example/cli in the package and having the
crypto_service
,lurk_ping
,sercret_prov_service
installed in a ./local/bin directory. - ensuring there is a directory that contains the keys - which can be read by gramine.
- REMOVE the source/pytls13 directory that contains a version of pytls13 - that version is only used to generate the documentation.
- integrating the example/cli in the package and having the
- Include the
client
andsecret_prov_service
into apylurk.gramine
module. This consists in integrating a compile c code into a Python module as well as providing an python binding. - Refine the
python.template
. Currently this file is designed to be unmodified.- We should try first limiting the python packages to be embedded. Maybe these could be defined by the
pipreqs
package. - The key file is currently below the gramine directory, there is probably some means to make that directory more flexible and dynamically configure the template with it.
- Define a class that generates the template
- We should try first limiting the python packages to be embedded. Maybe these could be defined by the
- The public key is currently configured via a list of files. We may consider having a single file with all certificate chain.
- Logging may be configured via the CLI and we may introduce a log_level
- ECDHE keys have their own ECDHE class in the crypto_suite module while signature keys are handled in the conf module. We may consider harmonizing the API between ECDHE and SIG keys and have them in a single place.
- lurk_tls13 is a bit too long, so we may consider splitting the TLS client and TLS server messages in distinct modules.
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.