Securing API Keys

How Keys are Stored on the Platform

• Stored in a database that is encrypted at REST
• There is no direct public access to the database
• Database is only accessible to Paradigm compute workloads on a private AWS VPC network

Types of API Keys

Paradigm handles two main types of API keys:

1. Exchange API Keys: Used by Paradigm to submit trades on their behalf when users orders match
2. Paradigm API Keys: Authenticating and interacting with the Paradigm API.

Exchange API Key

Users may have multiple exchange API keys per venue, each will need a unique label as it’s identifier. API Keys differ between venues but generally consist of a pair of tokens.

Encryption

• Keys are encrypted before being saved into the database
• Keys are only decrypted as needed when submitting matched trades to the exchange
• Keys are symmetrically encrypted using the AWS Encryption SDK (backed by AWS KMS) using AES-GCM 256-bit encryption.
  • AWS Encryption SDK leverages two keys to perform encryption: Primary key and data key
  • Primary key provides generation, encryption, and decryption of data keys
  • Data keys are used to encrypt the actual Exchange API Keys and are unique per set of exchange credentials
• Access to the KMS key is strictly limited to systems that needs access to decrypting for submitting trades to exchanges
• Employee access to KMS keys are strictly limited to those with admin privileges
• We use AWS CloudTrail to log and monitor access of KMS keys

With these protections, should a bad actor somehow gain access to unencrypted contents of the DB, they would not feasibly be able to decrypt customers’ Exchange API Keys.

Paradigm API Key

This consists of an access key and a signing key. A desk can have multiple keys but a unique label is required for them.

1. Access key is to identify desk
2. Signing is for signing request

Key Generation

• Access keys
  • 24-byte character string generated from a 62-character set, resulting in 142.9 bits of entropy
  • First 8 characters are stored unhashed as a key identifier
  • Hashed before storage
• Signing keys
  • Randomly generated 36-byte string, resulting in 288 bits of entropy
  • Base64-encoded for transit
  • Stored as raw bytes due to signature verification
• Both generated from system source of randomness adequate for cryptographic use

Encryption

• Access keys
  • Salted and hashed using the SHA-256 hashing algorithm before storage in the database. SHA-256 chosen over traditional password-hashing algorithms since the key is generated from a secure random source
  • One way hashing prevents Paradigm from having access to customer’s Paradigm API Access Keys. We can only verify API request validity by comparing hashed results.
• Signing keys
  • Stored in the database directly because it is needed for generating and comparing request signatures
  • Provides no value without the Access keys