Tech Specs

Do not use this key to protect real data! The private key has intentionally been published. Each OpSep server generates their own key with strict access controls.

Your can see what the public key looks like by running this:

$ cat rsa_kek.pub 
-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA7q4R3soRD2CrjL13OK6Y
SBG8wpjP5sbfkL0QhpJMH87grlR2SS3CUnbYCOONzQiJ3OuKAViy/lMw1KsmG9Nn
hAot2acg1iNyZRY33LR2jwmfFF+2iRp0itPQeOHY6GS8m3WLCMtC/kWUq0Bl5g1P
Ya9JXwSkTTRJunNH0TPk8uqwFeVhpT336M1H6ed105L8a8W3mpSwlwePron7pLf7
wD32m9RT0nNdnHBDQCsUKS/Gdp+saLYWTgj0rpnQCe8f1p3g36Gm0gTzr3X0Adow
8gIPfxO4HU/0cdL+Pw4mpcsWJ4531taRLLGb+a2la2zAUteYcS+8d4Nb8Omkbz39
PylvKP6R1kHElqlF3BnwUp0AdcAvOLdeX8kYUlbKE8xwjHm/KwwleKlcAZDam7hC
Rw72JUQiod0E7My+SiZ3Ij5zKnxZXmAF5BX8T+YSqSzR4Qdp2QU9L9GgAZo/HPBN
wME9v8usjEzrEItSSg3Nn10+J+ygsCqjrCT8CnSvD8wEyDSdO/Jly9DnWJ6B2HJE
Oc4wxWGFTCE0wiQOwC3IPNxFhuWun6/4tsEQcDs5XHaBXIHry5WCiVkjwa2pc95x
iXcfoQWr1A/jLe/MrZyN4yrgDK9mmQxxNzVfLj8S9NPjJMv+K7BKvtOmvoqsf13K
6hYJGkAdR0d99DNFlllRm7cCAwEAAQ==
-----END PUBLIC KEY-----

The same RSA public key can be re-used for every DEK, so this step only has to be performed once. Users typically save this public key locally in their configuration so they don't need to download it each time they want to encrypt a record in their database. Next, we'll use a unique DEK to symmetrically encrypt each record.

Your key should look something like this:

$ cat symmetric_dek.txt
2c7776dacc5542cceecee5e7867afa08ca251c6d9d91f97856e9a01c6fcd64a6

At 256-bits, this random symmetric key is quite long. An encrypted version of it will later be stored in your database and not something you ever have to remember.

Each record you want to secure in your database will be encrypted with its own unique symmetric DEK. This will be important in step 9 when we discuss Rate Limiting.

At the time you encrypt your data with a unique DEK, your OpSep server will not have access to this DEK. If you later use OpSep to decrypt your data, your OpSep server will be able to reconstruct this symmetric DEK with the data you supply. Recovering your plaintext requires both your ciphertext (which never leaves your server and your OpSep server never sees) as well as this symmetric DEK.

If you get a Extra parameters given error, it likely means you're on an outdated version of openssl or an alternate program like LibreSSL that is being called instead. Please go back to the first step (Upgrade OpenSSL) for instructions on how to upgrade.

You can verify this does indeed appear encrypted (your result will be slightly different):
$ cat secret.symm_enc
Salted__??a3??=Hz???l'??f?\?

This is the data you would save to your database (along with symmetric_dek.asymm_enc in the next step) for later retrieval and decryption.

-aes-256-cbc instructs openssl to use AES in Cipher Block Chaining mode. While asymmetric encryption is slow and has size constraints, this is a very fast symmetric encryption algorithm that can handle large files sizes.

You can encrypt a whole file (to_encrypt.txt) by first saving it and then passing it into openssl (no need to pipe it in):

$ openssl enc -aes-256-cbc -kfile symmetric_dek.txt -in to_encrypt.txt -pbkdf2 > secret.symm_enc

Instead of -kfile symmetric_dek.txt. you can enter -k 2c7776dacc5542cceecee5e7867afa08ca251c6d9d91f97856e9a01c6fcd64a6 if you prefer. Note that the -k is lowercase, and replace the hexademical string after it with your symmetric_dek.txt generated above.

The -pbkdf2 flag is only used to surpress a *** WARNING : deprecated key derivation used error that would confuse this exercise. Without this flag, we get a warning that for (regular) symmetric encryption you want to use a key derivation function. Since our key is already a massive 256 bits long, there's no reason to suffer the performance hit of a KDF. However, for this demo we let openssl perform this unneccsary KDF for simplicity. You're welcome to get rid of -pbkdf2 throughout these examples if you like; you may then want to add 2> /dev/null to your openssl commands to silence this the error.

By using a JSON file, OpSep supports powerful restrictions on future decryption. For example, we can add an RFC3339 timestamp called deprecate_at that will mark the key as deprecated at a certain time in the future. This notation occurs client-side and does not immediately leave your client. However, if your OpSep server decrypts this file in the future and the deprecate_at date has passed, then OpSep can refuse to return this deprecated key.

Your OpSep server also supports the client_record_id and risk_multiplier (see OpSep server for details).

If you get a parameter setting error, it likely means you're on an outdated version of openssl or an alternate program like LibreSSL that is being called instead. Please go back to the first step (Upgrade OpenSSL) for instructions on how to upgrade.

You can verify this does indeed appear encrypted:

$ cat symmetric_dek.asymm_enc

This is the data you would save to your database (along with secret.symm_enc).

Base64 ciphertext is easier to work with than binary data. Encryption performance is not meaningfully affected as this is only the symmetric DEK, which are a small fixed size (unlike your plaintext which could be very large).

While each record you want to secure will require its own unique symmetric DEK, you can encrypt all of them with the same RSA public key. The corresponding private key (rsa_kek.priv) is stored in OpSep's HSM, and useage is controlled by a rate-limit policy, access controls, and an intrustion alarm system.

Notice that all the encryption took place locally and is non-interactive, which is great for performance. If you needed to revoke decryption access during a suspected breach (or OpSep were to ever experience downtime) your regular data encryption would continue unaffected.

For the purpose of this demo we're not bothering to throw away your DEK, because it will make it slightly easier to keep track of what's happening.

If you want to throw away the DEK, enter the following:

$ rm symmetric_dek.txt symmetric_dek.json

We're using '$(cat ...)' as a fancy of way passing in the contents of symmetric_dek.asymm_enc into the json payload that we're POSTing. Normally, your client library would handle all this complexity for you.

If you prefer, you can manually substitute so that your -d flag looks something like this:

-d '{"key_retrieval_ciphertext":"jx70uVbQaZeQ...CfTIFI8iqdYX73E"}'

We can confirm this returned key matches the original by running the following:

$ diff symmetric_dek.txt symmetric_dek_recovered.txt
$

Using python3 is a verbose way to parse the JSON that OpSep's API returns. If you have jq installed you can instead do:

$ cat opsep_api_response.txt | jq -r '.keyRecovered' > symmetric_dek_recovered.txt 

While your OpSep server did gain access to your symmetric DEK (symmetric_dek_recovered.txt), it never saw your ciphertext (secret.symm_enc) and it has no ability to access your plaintext. In fact, it doesn't even know what type of data you're protecting (binary, string, integer, boolean, etc), which database you use to store your ciphertext, or even where it is hosted.

Most of our users set their rate-limit so that their maximum exposure from a breach is < 0.1% of their data. This protection remains even if your attacker has physical control of your server! OpSep also keeps a log of every record your attackers attempt to decrypt. These rules are easy to set and adjust using our web UI with strong multi-factor authentication. We automatically alert you to suspicious decryption requests 24/7 so that you can quickly discover if your servers have been compromised.

You can see these rate limits by running:

$ cat opsep_api_response.txt

Note that the api response will be easier to read if you pipe the output to a json parser like this:

$ cat opsep_api_response.txt | python -m json.tool

Or like this if you have jq installed:

$ cat opsep_api_response.txt | jq

In order to effectively use the audit log feature you will want to store this hash digest (symmetric_key_asymmetric_enc.digest) in your database alongside your asymmetrically-encrypted symmetric DEK (symmetric_dek.asymm_enc) with an index on this column so you can query it easily. In the event of a suspected breach, you can query and see which hash digests your attacker attempted to decrypt.

You can manually confirm that symmetric_key_asymmetric_enc.digest is the same as what was returned in opsep_api_response.txt by inspecting the two files. The API returns asymmetric_ciphertext_sha256 as a convenience for the avoidance of ambiguity, stricly speaking your client software already has the ability to calculate this hash digest on its own.