HYKER trust based security model


Security is, and always has been, a basic requirement for quality products. It has been a part of every serious system since the start of networked computing in the late 1900s and is now a part of everyone’s life having moved some parts of our lives to the internet. However, it has always been hidden under the surface. It has not been publicly advertised by neither the media nor the system builders.

The situation has changed. Nowadays, security breaches are front page news on the most respected newspapers and system builders openly discuss their security model as a part of their marketing.

The HYKER model

HYKER takes a strike at securing the data in a system, as opposed to securing the infrastructure. HYKER separates the access control of data from the process of sending it. A message or data protected by HYKER does not have an explicit addressee. There is no recipient, and nobody can decrypt it. Instead of encrypting it for a known recipient, the message is tagged with metadata of how to acquire the key. It is then up to a consuming party to request access to the decrypting key.

This makes the system highly suitable for pub-sub systems, especially when you have multiple parties involved, or the data is stored over time, or people in the system come and go.

This is all done using end-to-end encryption, protecting the data in an unbroken chain from producer to consumer. There is no central storage of decryption keys. The important thing is that sensitive data does not touch any part of a system it does not need to.

Securing a certain part of a system is always easy. Using good encryption, installing a firewall, separating processes, etc., are all great ways of doing this. The hard part is getting the overall security good. In other words, being sure that there is no part of the chain that is weaker than the rest. HYKER eliminates the need to trust the ultimate security of every part of the chain by focusing on securing the data instead of the infrastructure. This is done through a trust based security model.

Key insight: Encryption is easy

Want to encrypt something? Good, go get a state-of-the-art implementation of a world-class algorithm. This is available in a multitude of open-source libraries. For free.

Key insight: Key Distribution is hard

So, you have a good way of encrypting your data. How do you obtain the key? In simple systems, you can use a classic PKI (Public Key Infrastructure). But what if you don’t know the recipient at the time of sending your data? What if the recipient belongs to another organization that does not use a PKI? What if the keys need to be replicated?

Key distribution and key management are generally recognized as problems with no one-size- to-all solution. This is a major reason why securing a system is difficult. The owner of the keys controls the data, and key management controls key ownership.

Key insight: Access Control is all about trust

Since access control governs access to data, it is very closely related to trust. Access control separates authorized entities from outsiders. Therefore, the part of the system that runs the access control is all powerful, if it is compromised or erroneously configured it can give access to anything it wants – even itself.

In traditional hop-by-hop systems, access control is based on a set of rules. There are various parts of a system which hold data, and they give access based on the given rule set. This rule set can be circumvented, either by a configuration error or mischievous behavior from external attackers or insiders. In a system like this, you are forced to trust the data holders since they have full power.

If the access control is instead based on end-to-end cryptography, you do not need to trust the data holders with access control. You can strip them of all power and handle access control through cryptography instead of rules.

HYKER believes in a security design where you can select what you want to trust not what you need to trust. This way your system design and security model are not dependent on each other, you don’t need to trust a part of your system just because data flows through it.

Key insight: Data ownership is nuanced

Saying that data is secure because it resides in a secure infrastructure messes with data ownership. Only in very simple systems are the system maintainers and data owners the same people. Therefore, since infrastructure ownership and data ownership are separate concepts, they need separate security solutions.

Secure communication

How the data is secured

All security is based on conditionally selecting trusted parts of a system to handle your data. To enforce security – i.e. the exclusion of untrusted entities – we use tools, rules, and cryptography. Rules are prone to human error or malicious intent. Cryptography, on the other hand, is highly resistant to these flaws.

Securing every part of the system (Hop-by-Hop)

Most people that have come in contact with computer security have heard about the common techniques for connection security and end-node security such as TLS and firewalls.

These technologies are very good, but the purpose is to secure the infrastructure, piece by piece, or as we call it in the industry, hop-by-hop. This means that when for example sending an email, the email is encrypted in transit and in storage, but the parties delivering the email are able to decrypt the message. This is a weakness. There can some parts of the chain that are vulnerable, and others that are malicious.

While traditional security models like this are good for securing infrastructure that is owned in its entirety, it is not designed to protect data which does not explicitly belong to the owner of the system.

Securing the data at the end nodes (End-to-End)

When you do not control 100% of the infrastructure – as when using cloud services, or when the data does not belong to the system (e.g. chat services or email systems) – protecting the infrastructure is not enough. Additionally, you need to secure the data itself. If the data is encrypted at the message sender, and the decryption key is only made available to the intended recipient, you achieve what is called end-to-end security (E2E). This type of security eliminates the need to fully trust every part of the system, making for a reduced attack surface and brings data ownership back from the system to the data producer.

There are many technologies available for E2E, e.g. HYKER, PGP, Signal, and OSCoAP. They all achieve fully secure E2E, but with important differences making them suited for different purposes.

Data Life Cycle Security

What is trust?

Trust is related to abilities. What abilities do I trust a certain party with?

In a secure system, trusted parties are those who have access to data, i.e. those who are able to obtain decryption keys. This entails that in a hop-by-hop system, all hops are trusted. In end-to-end systems, however, only the end points are trusted. This means that we should opt for an end-to-end based system if it involves sensitive data, or data not owned by the system administrators.

Data life cycle

Data is data, unrelated to what system it flows through. Therefore, we need to focus on the full data lifecycle, from production to consumption, over time, using any system. This is what HYKER does and these are the logical endpoints in a HYKER end-to-end. An endpoint is usually considered to be a device like, for instance, a mobile phone. A HYKER endpoint can be a user device, server, application, or anything that produces or consumes data in the system.

The HYKER solution provides the fundamental separation of encryption and access control. This is the enabler for trust-based security, where you can select trusted parts of a system based on the data, not on how the infrastructure is designed. It also enables voluntary delegation of control and retroactive access.

Retroactive access

Think of a document sharing service, like Dropbox. The amount of data stored in the cloud can grow very large over time. If you want to add people who are allowed to read the documents, how do you do that? How can you keep control over the data without having to resend it?

When designing, a system based on hop-by-hop security, you do not need to worry about knowing all recipients beforehand. The central server can take care of adding additional recipients. But in these systems, you give up the control over your data. The central server being able to add recipients is enabled to do so through letting it control your data, demanding total trust in it.

To re-take control, you can introduce end-to-end security. But this introduces another problem. In a conventional end-to-end security system, the intermediate parties (e.g. storage servers), have no access to the data. This means that the end nodes have no control, resulting in no possibility to add recipients without resending the data.

HYKER solves this through a concept we call retroactive access control. This concept brings the best of both worlds: you can have full control over who gets access to your data, and you don’t have to resend it. This is done by separating the key sharing from the data sharing.

Access Control Delegation

It is easy to wind up in a binary world when reasoning about end-to-end vs hop-by-hop, especially when considering access control. In systems that are fully hop-by-hop, the central service is in full control. In systems that are fully end-to-end, the end nodes are in full control.

We have talked about why you might not want to give full control to a central server. There are also cases where you don’t want full control in the end nodes either. An example could be an enterprise communication platform where a decentralized security model with elevated control for middle managers could be desired.

The picture below illustrates the differences between centralized, decentralized, and distributed systems.

We solve the binary situation by using delegated access control, making a combination of distributed, decentralized, and centralized trust models possible.

Delegated access control is a concept where an end node can voluntarily delegate permission of key sharing to any other node. If an employee delegates the decryption key responsibility to the nearest manager, that manager gains the possibility to let other employees access the data. Another example is an IoT sensor which should not have any say in who can access the information. That sensor can delegate the access control to the sensor owner or a group of owners.