Home Blog Contact

Key Management

Client Key Management

Client private key is:

  • Stored in Permanent Storage directed by SeaCat SDK
  • RSA 4096 bits length
  • Protected by 3DES (3DES is preferred over AES for its slower decryption process which makes attacks against it harder)
  • Accessible for SeaCat SDK only (inaccessible for other applications)

For enhanced Client private key protection of SeaCat SDK Permanent Storage, allow the use of the following cryptographic techniques:

  • Password protection
  • HW-specific salt
  • NFC HW tokens
  • Android Keystore System or iOS Secure Enclave
  • Combinations of this options

Integration with Android Keystore System or iOS Secure Enclave

For advanced Client private key protection, the Android Keystore system or iOS Secure Enclave (the Keystore) is supported by SeaCat SDK. The Keystore stores cryptographic keys in a secure container. It prevents extraction of the private key from the device (e.g., by a malicious app or super-user).

The following actors participate in advanced client private key protection:

  • Android Keystore System or iOS Secure Enclave
  • SeaCat SDK
  • Memory
  • Permanent Storage

Private keys are generated by the Keystore, and they never leave it. They are used for cryptographic operations (encrypt, decrypt, sign, verify). The Keystore offers facilities to restrict when and how cryptographic keys are used, such as user authentication for key use (e.g. Touch ID on iOS) or limiting the ability to use cryptographic key only in certain cryptographic modes.

Two operations related to the Keystore exist:

  • Onboarding (when the cryptographic keys are generated for the first time)
  • Standard Client connection (for every Client authentication)

Client Onboarding

The following diagram describes the onboarding sequence (Client initialization phase).

Certificate Authority Chain validation role

1) Application Crypto Request

The onboarding sequence is started once Application is launched for the first time, typically just after its installation. During this sequence, the Vernam key and SeaCat Client key pair are generated by SeaCat SDK and stored in Permanent Storage. Also, the Keystore is instructed to generate a Keystore Provider key. Vernam key is used for Vernam encryption. It has the same length as SeaCat Client private key. SeaCat Client private key is used for Client authentication.

2) 3DES Encryption of Client Private Key

SeaCat Client private key is encrypted by 3DES. Additional authorization method for enhanced security is supported (e.g. user PIN, user password, hardware token).

3) Vernam Encryption

The Vernam cipher is a symmetric stream cipher in which the plaintext (SeaCat Client key in this case) is combined with a random or pseudo-random stream of data (Vernam key in this case) of the same length to generate the ciphertext using the Boolean “exclusive or” (XOR) function.

The Vernam cipher is considered to be unbreakable if the pseudorandom data stream (Vernam key) remains private. The privacy of the Vernam key is assured by asymmetric encryption performed by Keystore. After Vernam encryption, the Vernam key and SeaCat Client key are discarded from its memory.

4) Asymmetric Encryption

Keystore performs asymmetric encryption using a Keystore Provider key as a private, remotely (from SeaCat SDK) triggered function. The processing function is hidden, and the KeyStore Provider key remains private.

Standard Usage

The following diagram describes a common Client connection sequence.

Certificate Authority Chain validation role

1) Application Crypto Request

When Application requests a connection to Application backend, SeaCat SDK remotely triggers the Keystore decrypt function with an encrypted Vernam key as an input.

2) Asymmetric Decryption

Keystore decrypts the encrypted Vernam key. It uses the KeyStore Provider Key for this operation, and that key doesn’t leave a Keystore.

3) Vernam Decryption

Vernam key is used for the reverse operation of Vernam encryption against encrypted SeaCat Client private key (XOR operation). After Vernam decryption, Vernam key is discarded from its memory.

4) 3DES Decryption

SeaCat Client private key protected by 3DES is decrypted. SeaCat Client private key is used for signing the communication data frames to SeaCat Gateway and decrypt data sent by SeaCat Gateway to Application.

Server Key Management

SeaCat Gateway Key Management

SeaCat Gateway private key is:

  • Signed by TeskaLabs root Certificate Authority
  • Stored on SeaCat Gateway in /opt/seacat/etc/gateway.key (default location)
  • RSA 4096 bits length
  • Without password protection (more secure variants are available)
  • Accessible to root user only
  • Enhanced by 2048 bits long generated DH prime stored in /opt/seacat/etc/dh.pem (default location)

The seacatd daemon is executed in root user context. But for every single Client Connection, de-privileged child process exists. So during a compromised Client Connection, the attacker is unable to reach SeaCat Gateway private key. For better SeaCat Gateway private key protection, we recommend using the following cryptographic techniques:

  • Password protection
  • Hardware-specific salt
  • NFC HW tokens
  • Hardware cryptographic modules
  • Combinations of these options

TeskaLabs’ Root Certificate Authority Key Management

TeskaLabs’s root Certificate Authority certificate is available online with:

  • Fingerprint 64 24 25 0c e4 aa 5a e5 ab f2 f2 03 ad 50 59 37 e9 50 62 a6
  • Serial number 00:EE:C4:67:F9:22:19:57:3B
  • RSA 4096 bits private key length

The TeskaLabs’ root Certificate Authority private key is password protected and encrypted. It is stored in two bank deposits geographically separated, and is accessible by two people only.

The purpose of TeskaLabs’ root Certificate Authority is limited to Client Signing Requests signing that are sent from only newly-deployed SeaCat Gateways. These Client Signing Requests signing are done offline (without any network connection) and by a dedicated computer.

Entropy

SeaCat Gateway uses by default /dev/urandom as the source of entropy. We recommend using SeaCat Gateway on CPU architectures that support RDRAND instruction. More information about Linux Random Number Generator is provided here.

Advanced scenarios are supported as well; please contact us for more details.