Well, almost, someone has to know about it, after all the secret was created by someone and it might be intended for someone else. So one or two users need to know it. What would it be like if all secrets were knowable by authorized users but invisible to everyone else? If they were hidden and could be seen only by those who knew what they really were?
It turns out that this is possible through a technique called Steganography. It is a special category of the broader field of cryptography. But unlike the more common cryptographic method of encryption that leaves evidence that something important exists (.i.e. the string of characters that replaced the unencrypted information is an indication that something important is hidden there), steganography is a method of hiding information in plain sight. Simply put, steganography is hiding secrets inside something else like an image.”
So we know that hidden secrets are possible through steganography. But what about vanishing secrets? Secrets that are unknown or unpredictable and that appear for a short time and then disappear? It turns out that these are possible, too. Before going further, I want to explain the term ‘secrets.' In the context of this article, secrets is a general category name for keys, tokens, tickets, passcodes, passwords or similar character strings that protect information.
Vanishing Secrets are useful in situations such as data-in-transit or other short-term operations in the Cloud. Their qualities don't make them particularly useful for longer-term protection such as encryption of data at rest. The keys for long term storage of data at rest need to persist and are the kind that need to be vaulted. But short-term encryption probably doesn't need that. Transport Layer Security (TLS) is a good example. The TLS session token exists for a short period of time and then expires. When a new session begins, a new TLS encryption key is exchanged and the communications between endpoints are once again protected. The TLS session token is an example of a vanishing secret.
Key Exchange and PKI
But here’s the problem with symmetric encryption keys for data-in-transit applications. How do both sides of a data exchange get the identical key needed for encryption and decryption? The sender has a key to encrypt the data, and the receiver must have the identical key to decrypt it. The solution to this “key sharing” problem was discovered by Whitfield Diffie and Martin Hellman. The Diffie-Helman key exchange protocol is an “asymmetric” encryption protocol and is an important feature of “public key cryptography.” The Diffie-Hellman key exchange protocol allows two parties (with no prior knowledge of each other) to jointly establish a shared secret key over an insecure channel. The protocol is fundamental to “public key infrastructure” (PKI), which is essential to identity and trust throughout the Internet. PKI involves additional keys - a public key and a private key - as a key pair for each party, but ultimately the protocol exchanges a symmetric key (the shared secret) that the two parties use to encrypt and decrypt information exchanged with each other. A condition of PKI is the persistent secure storage of each party’s PKI key pair. The private key must be kept secret and not shared with anyone. This presents another problem: where and how is each Private Key secured so it stays secret? You can begin to see that every secret key needs to be locked up, but every lock needs another key; an endless chain of keys and locks could be created.) Another less-complicated way of creating and using vanishing secrets is a novel method of key generation and rotation called “Codes Hidden In Plain Sight'' or CHIPS for short. It's a variation on the concept of steganography.
CHIPS is a patented method that uses dynamic Internet information as input to an algorithm that generates a cryptographic key. The dynamic information is “hidden in plain sight” and it exists for other reasons, such as news or weather information. But CHIPS uses that same information to generate a cryptographic key. The key that CHIPS produces depends on several things, including the time that the algorithm is processed (when it ‘runs’). The CHIPS algorithm, the dynamic input information, and the time that the algorithm runs are the three things that are needed to generate a key. And if two separated parties run the same algorithm at nearly the same time, then they will generate an identical key.
Once a key is generated, it can be used with any cryptographic cipher, such as AES, to encrypt information. This is no different than any other key generation and information encryption process. Let's return to the situation where information needs protection for only a short period of time. For example, in secure messaging, where the information must remain private or secure during transit. In this situation encryption protects messages as they travel and then when they reach their destination they are promptly decrypted, read, and used by the intended recipient. Another example is protecting data that is used in an important process, such as a financial computation. It’s important that the data be tamper-proof and trusted before the computation, but once it has been used, its value does not need to be kept secret any longer. In these short-term protection situations, the encryption key doesn’t need to be kept secure for a long time nor is it reused multiple times, as might be the case with data stored at rest. Instead the key can be ephemeral and short-lived and can vanish or auto-destruct once it has served its purpose. Vanishing secrets have the quality of disposability and don’t need to be stored.
Vanishing secrets built from CHIPS technology enables symmetric message encryption without the need for the additional key pair of PKI, or the secure storage of long-term private keys, or the PKI symmetric key exchange. Instead, a CHIPS algorithm is used by separate parties to build an identical key at the moment they need it. For secure messaging, two parties with the same CHIPS algorithm can run their algorithms at the same time (independently from one another), and produce an identical key. The keys that CHIPS produces don’t require secure storage after they’re used and the messaging session is finished. Once they have served their short-term protection role they automatically self-destruct.
API Secrets Across the Cloud
Consider the situation of a cloud microservices environment, where each microservice uses an API to communicate. A group of microservices may exchange data in API messages to perform a critical business process. Classic Secrets Management for these APIs would require the vaulting and rotation of the key for each API. Vaulting and rotating the API keys is a complex process with operational constraints (such as uptime) and it requires some careful configuration, too (rotation schemes use "leases" to define the time-to-live of a secret). When it comes to API security, vanishing secrets offer some compelling advantages. One of them is the elimination of the “secrets injection” necessary to replace a key at a workload endpoint. Each time the Secrets Manager rotates a secret, it must inject the new secret into the workload that stores the authentic version so that future authentications will be successful. This is easily done within a vendor cloud, such as AWS Secrets Manager, where AWS has access and permissions to change authentic secrets within an app or service, but it is very hard to do in real-time and across different clouds.
CHIPS’ vanishing keys eliminate long-term secure key storage and they don’t have the challenge with key rotation that exists with traditional secrets stores or vaults. Vanishing keys using CHIPS don’t require secrets injection either, instead the key automatically self-rotates without any key exchange or injection. The important detail with CHIPS is for the two API endpoints to run the CHIPS algorithm at nearly the same time. This is where automation helps. The processes for building a key, using it for encryption and decryption and then destroying it are automatically invoked either on-demand or on a time cycle within hopr’s CHIPS technology solution.
There are many use cases for vanishing secrets. The next time your working with data that needs protection for a short period of time, consider that the encryption can be tailored for your use case. It doesn't need to be a "one size fits all" choice where you generate and store keys as you would for a long-term use. Consider, too, if a novel technology, such as CHIPS, could make more sense. It makes vanishing secrets easy to implement with a small amount of code. It could be simpler and easier than your current secrets management practices.