To access this content fill in:

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.