Retroactive Interactive Key Sharing

“Distribute first, give access later”

RIKS enables end-to-end encryption for live data over the full data lifecycle from producer to consumer(s). Data is protected in an unbroken chain over time, in transfer and at rest. RIKS also supports end-to-end encryption in dynamic groups where users and devices come and go.

Key sharing at decryption

Traditional encryption works by knowing who you encrypt for. You use the recipients public key to encrypt with, making it impossible to access and read without decrypting the data with the recipients private key. This works fine in messaging or setting up an encrypted tunnel like TLS or VPN, but it effectively prevents encryption in an unbroken chain in most IT-systems, where you don’t know the recipient at the time of data production. You can only protect the data hop-by-hop, having to trust every node in the chain since it has access to the data in clear text.

HYKER changes all this with the RIKS (Retroactive interactive Key Sharing) protocol. By sharing the key upon request at the decryption stage the data is never exposed in clear text, not even in storage, effectively removing the cloud provider from the security equation. You don’t have to trust them since they never have access to the keys to your data.

Asynchronous communication patterns

While some forms of group communication are easily encrypted, protocols limited by asynchronous behavior or central authorities are harder to secure. RIKS adds a novel way of achieving end-to-end encryption for publish-subscribe protocols such as MQTT and AMQP and real-time databases like Google Firebase.

These protocols have a property that makes them hard to secure. Senders are not in control over to whom the message is delivered. This is instead the responsibility of the broker. RIKS changes that.

Distribute access control to the data producer

RIKS effectively removes the authority of access control from the broker (if there is one) and gives it to the sender. By doing this, the consistency of the secret communication group is in the hand of the sender instead of at a central authority. The transfer of authority is done while maintaining other important properties that might be present in the message protocol, such as e.g. asynchronicity or publish-subscribe.

Encrypt, send and store first, give access later

On top of this, RIKS divides key establishment/sharing and the sending of data. This way, you can decide on who the recipients are after you actually send the message or store the data in the cloud. You also have an option of adding additional recipients later, which is very handy when storing data for later access by another party.

Applications can be, for instance:

  • Cloud enablement without the need to trust the Cloud provider
  • Multiple data owners sharing data storage in an application (e.g. Smart City) while all owners still maintain full control over their data elements.
  • End-to-end encryption in publish-subscribe communication (e.g. MQTT, real-time DBs), where the sender doesn’t know who subscribes to the messages at sending time.
  • A central storage of encrypted data that is only accessible at a later stage when the key is distributed to a group of users or devices.
  • End-to-end encrypted mobile apps based on Google Firebase.
  • End-to-end encrypted channels for dynamic chat groups. Example with source code and more
  • When you need granular control over data in a central application server preventing access by anyone except a specific group of users and devices.
  • Full data lifecycle lock down where data can be stored and transferred in services, countries, and networks that you do not need to trust.
  • Data managed by a third party cloud service where you still maintain control over the encryption keys that never leave the owner.
  • Confidentiality in public blockchains.

 

More reading

Take me to the documentation for a more in-depth description