Identity and Cryptography

You may have noticed that each Enclave system that you enrol has an identifier attached, (for example, V88RY or 968K2). These identifiers come from each system's certificate.

When you enrol a system, the installed agent issues a certificate signing request to our platform, along with an Enrolment Key retrieved from your portal account. Provided the key is valid (and the enrolment attempt meets the correct conditions), we then issue a signed certificate.

Here's an example certificate provided after enrolment:

"Certificate": {
    "Version": 0,
    "SerialNumber": "n7JLyhs/mUivvK1ALOnxjA==",
    "PermittedUse": "Endpoint",
    "SubjectDistinguishedName": "R8WLQ",
    "SubjectPublicKey": "GwkfXjwAqxJheLzVWhF+V8JEa0R9od74ysQfC6i2Yas=",
    "NotBefore": 1673538715,
    "NotAfter": -1,
    "IssuerDistinguishedName": "Enclave Networks Primary Intermediate G1",
    "IssuerPublicKey": "WwZg4p39Swi3J/z/XfqWPV1Ld466U0VVr11x8bclPOs=",
    "Signature": "rVEmjvZUbiaa7SSnfdYPhV87tGWI1B3Sdrn2kU2Ir/Wj2XSdId1IwxAi3GXgRPEbH2LPlH8ysWe5jLvhLf99Dg=="
},

It's not very complicated; we don't represent certificates in X509 format, and you can find your own certificate in your profile file.

The Subject Distinguished Name is a globally unique identifier for the system, generated during certificate signing, that is used to reference it in APIs and the portal.

You can find your profile file in the "profiles" directory stored in C:\Program Files\Enclave Networks\Enclave\Agent\profiles on Windows, and /etc/enclave/profiles on Linux and macOS.

Signatures are generated using the Ed25519 EdDSA algorithm. The 512-bit private keys for a given certificate are generated locally on the agent (and never leave the device).

We take steps on each platform to reduce the chance of exfiltration of private key material, including (but not limited to) machine encryption with DPAPI on Windows, appropriate secure storage on mobile devices and root-only file permissions on Linux.

Info

All our cryptographic implementations are provided by the industry standard NaCl/libsodium library.

System/Certificate Revocation

When you remove a system in the Enclave Portal, or via the API, it permanently revokes that system's certificate; the system will be no longer be introduced to any other systems by the discovery service, regardless of the effective policies. Systems that have been revoked must be re-enrolled to get connectivity back.

Key Exchange

Every time a tunnel comes up between two peers, we use the Curve25519 ECDHE key agreement algorithm to generate brand new per-session keys, providing perfect forward-secrecy, and ensuring that no other party is able to decrypt the data stream between two peers.

The Curve25519 algorithm provides a 256-bit shared secret, which is then expanded into two separate 256-bit secrets, one for each direction of transmission between peers.

Tunnel Encryption

On platforms that support AES256 hardware acceleration (requires Intel SSSE3, aesni and pclmul instructions), tunnel encryption uses AES256-GCM AEAD with a 128-bit block size and a 96-bit counter nonce, non-repeating and monotonically incrementing. We switch to a new key before reaching 2^36 bytes or 2^32 messages encrypted with the same key.

On any platform that does not support hardware acceleration, we use ChaCha20-Poly1305 AEAD (ChaCha20-Poly1305-IETF), with a 512-bit block size, a 64-bit counter nonce, non-repeating and monotonically incrementing. We switch to a new key before reaching nonce re-use with the same key.

Summary

To summarise the cryptographic algorithms we use:

Purpose	Algorithm	Key Size	HW Acceleration Required
Public-key signatures	Ed25519	512 bits	No
Key Exchange	Curve25519		No
Tunnel Encryption	AES256-GCM	256 bits	Yes
Tunnel Encryption	ChaCha20-Poly1305	256 bits	No