Opsmate Crypto Details
This document contains technical details about how Opsmate uses cryptography to keep your data secure. It is intended to help security professionals assess the security of Opsmate's cryptography. Opsmate publishes these details because we believe in being transparent about how we protect your data. For a higher-level overview of Opsmate's security, see the security page. For end user documentation about Opsmate's security features, see security options and key management.
Algorithms and parameters
- AES-256 in CTR mode is used to encrypt data (file contents) and metadata (filenames and file attributes). When starting a backup, separate AES keys are generated for data and metadata. The 128 bit CTR value is formed by combining a 64 bit nonce, which starts at 0 and increases with every distinct object encrypted, and a 64 bit block counter, which starts at 0 and increases with each 16 byte AES block encrypted in that object. Safety valves abort the program if any 64 bit counter overflows. Since brand new AES keys are generated for each backup, and the counters increase sequentially, there is no risk of reusing the same CTR value with the same AES key. All counters are accessed from a single thread to avoid data races.
- RSA with OAEP padding is used to encrypt the per-backup AES keys. The encrypted AES keys are uploaded to the Opsmate servers along with the encrypted backup content.
- RSA with PSS padding is used to sign backup data to protect against tampering. SHA-256 hashes of encrypted file objects are placed into a Merkle tree whose root is signed. File objects refer to other objects, such as data blocks, by hash, so the authenticity of a data block can be verified by tracing a chain of hashes up to the RSA-signed root hash.
- Separate RSA keys are used for encrypting the data AES key, encrypting the metadata AES key, and signing backups. Signing keys are 2048 bits long, and encryption keys are 4096 bits long. All RSA keys use a public exponent of 65537.
- HMAC-SHA-256, with an account-specific key, is used to hash unencrypted data to determine if a data block can be de-duplicated. An HMAC is used instead of a plain hash to avoid leaking information about the data. The only exception is that a plain SHA-256 hash is calculated of entire files that might be application files. This hash is transmitted to Opsmate for comparison against a list of files from popular applications to determine if the file can be de-duplicated. However, this is only done of files in directories that contain predominantly application files (/bin, /boot, /lib, /sbin, and /usr, except /usr/local) and can be disabled by the user.
- The user's private RSA keys and HMAC-SHA-256 key are stored in the key ring, which is stored on the user's filesystem with restrictive permissions. Keys in the key ring can optionally be uploaded to Opsmate servers for backup or to enable web browser-based features. Keys in the key ring can be encrypted with a passphrase as described below.
- PBKDF2 with HMAC-SHA-256 is used to derive keys from passphrases. 500,000 iterations are used by default.
- AES-256 in CTR mode and HMAC-SHA-256 are used to encrypt and authenticate keys in the key ring. The HMAC is applied to the ciphertext (i.e. encrypt-then-MAC). PBKDF2 is used to derive the AES and HMAC keys from the user's passphrase. The CTR value starts at 0 and increases by 1 for every AES block encrypted. Since the AES key is derived using PBKDF2 with a 128 bit randomly-generated salt and is used only once, there is no risk of re-using the same CTR value with the same AES key.
Opsmate uses OpenSSL's libcrypto library for all cryptography and does not implement any cryptographic primitives. Meticulous attention is paid to properly checking error conditions and ensuring that safe parameters are used. All sensitive material, such as keys, are stored in C++ wrapper objects which automatically zero the memory before deallocating it (care is taken to ensure that this is not optimized away by the compiler). Secrets are compared only using constant-time comparisons that do not leak timing information.
Have a question?
If you have a question that's not answered here, send an email to firstname.lastname@example.org.