A trust based security model

Hyker Security
14 min readSep 14, 2017

--

With the HYKER security model 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.

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 20th century 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. This has not been advertised by the media or 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.

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. HYKER is able to give the user the control over who receives the key. This “map” of key access is designed by the data owners.

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 ensuring overall security. 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. A trust based model is one which has a clear structure in which parties are allowed to receive keys. HYKER’s separation of encryption and key control is a departure from other models and one designed for the needs of cloud computing, IoT and multi-party transactions.

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. Furthermore, this is available free of charge.

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. This is driven by what we call the trust model, or “map” (which could be defined by end points, roles, organization boundaries etc.).

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.

HYKER separates the access control from the data. Only those who have been included in the trust “map” will be allowed to receive and/or share keys.

Trust by design, not as a happening

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.

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 be 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.

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.

The data producer will develop his own “map” of trust for who receives keys. This may be defined by an individual but much more likely by an architect using a pre-defined structure to ensure only the right recipients (which could be logical or physical) receive the keys. As mentioned above, this can be altered retroactively to add recipients.

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.

A HYKER model analogy

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 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.

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 central nodes have no control, resulting in no possibility to add recipients without end nodes 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 through separating the key sharing from the data sharing.

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 differences between centralized, decentralized, and distributed systems

HYKER 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. Again, this delegation permission is defined by the trust “map” mentioned earlier.

Sensors produce encrypted data and the HYKER control node manages what applications, devices or services that can subscribe to this data. This enables a highly detailed granular control over every data element.

In the simplest form of predictive maintenance, where all the infrastructure is owned by the same company that conducts the maintenance and the data is not sensitive, there is little need for HYKER. Traditional security will do the job.

However, as soon as we start to enter more evolved scenarios, such as predictive maintenance-as-a-service, military operations, or critical infrastructure, we start having to deal with the questions posed above. What part of the system is exposed to third parties? Does the system use any kind of cloud service? Who is collaboratively using data? The list goes on. A single RPM value from an engine is probably not sensitive at all, but aggregated data from continuous predictive maintenance can be powerful information mapping the properties, systems, and the current state of an organization.

An example of predictive maintenance data being considered sensitive is available in a recent report from ICF, where the question of data ownership is explored and deemed central. This is where a trust-based security model can be of help.

Take a critical infrastructure example: a power plant. The power plant uses one firm to conduct the automatic infrastructure surveillance, and various contractors to repair and replace parts. We have many different parties acting in a shared system with different data access rights.

An operation like this would be difficult to properly secure with conventional techniques since you would have to put unnecessary trust in the different parties. With a trust based security model like HYKER however, it would be much easier since you can selectively pick which parties should be trusted with what data on a very granular level.

In a recent report from the Swedish Defense Research Agency, it is concluded that the current computer security at Swedish critical infrastructure (power plants etc.) is severely substandard. The report suggests that cutting the cord, i.e. disconnecting all infrastructure from the internet, is a viable solution. The HYKER model can transform this situation.

An end-to-end encrypted group messaging channel with retroactive access to data history, where the history is stored in encrypted format in the cloud.

Telco systems are complex networks of communication links, relaying nodes, routers, servers, data storages, etc. Many of these nodes are from different 3rd party suppliers. Each link and each node is usually protected with perimeter security models, like encrypted tunnels, SSL/TLS protocols, etc. This is network security, or hop-by-hop security. Data is encrypted in transit over a link, but decrypted into clear text in each node and re-encrypted for the next link.

This means that the Telco, and the Telco customers, must trust each and every node, the staff that has access to the node, and the developer and supplier of this node.

Many customers have high requirements on security and are uncomfortable or even legally required not to trust 3rd party networks or cloud storages. Through GDPR they are required to maintain full control over their and their clients’ data, disregarding who they have contracted to store or process that data.

HYKER provides technology where data is protected in an unbroken chain from the data producer to the data consumer, in transit, at rest, and over time — independent of network technology. It’s a form of end-to-end encryption technology but with managed trust and data access control.

Instead of having trust distributed and delegated because of the different network and cloud suppliers’ models, the customer can take full control over the system and manage trust to best suit the security needs and logics of their application.

Extended offering

A Telco that sells connectivity and capacity to transmit sensitive data for a client can extend their offerings with HYKER end-to-end encryption and managed trust. This can be done in different ways depending on the business models of the Telco.

Some general examples:

· You can differentiate offers on the security level, with a premium communication service that is fully end-to-end protected, even when you share network resources with other Telcos. You can be the most secure communication link that the customer doesn’t have to trust from a data access point of view. You can provide service and application developer partners with a new security tool that protects their data through the full data lifecycle.

· You can offer storage or cloud services to customers with sensitive information. You can store their encrypted data and at the same time have no access to the keys, thus having no access to the data itself.

· If the Telco provides message-broker services, like MQTT servers for IoT, HYKER uniquely adds an end-to-end encryption layer that fully follows the traffic patterns of one-to-many publish-subscribe communication, enabling a data producer to encrypt the data without knowing the recipient(s).

Information of different sensitivity flows between many parties, some direct and some via cloud providers, some broadcasted, some real-time and some stored in databases. Disregarding from where, to whom, over what network and who owns that specific data it must be protected.

Logistics generates and consumes an abundance of data from many sources. Some of this data is highly sensitive or have other business value. Big Data is a huge trend that will have a major impact on logistics business.

Data is the key success factor of big data, and as such it is of great value. Logistics systems have many endpoints, for instance tracking devices on trucks, sensors and tracking devices on goods and containers, driver devices (cell phones, tablets) with work orders and reports, etc. There are also central endpoints like dispatch management terminals, analytics software, and so on.

Since logistics revolves around a hot pot of different systems and actors, data ownership can be a real challenge using traditional security. The important thing

is to have control over what data should be accessed by whom and when. Should a customer be able to follow their shipment in real-time? Should trucks be able to communicate directly with other trucks? With some trucks but not all trucks? Organized in groups that change constantly?

Instead of having trust distributed and delegated as a result of the different network and technology suppliers’ models, the customer can use HYKER to take full control over the system and manage trust to best suit the security needs and logics of their application.

From a HYKER point of view this is very similar as to the Logistics case. However, the real-time element with direct point-to-pint communication is much more important where delayed or wrongful data can have lethal consequences. Also, privacy protection is in important issue when cars have private owners.

Autonomous vehicles are going to communicate constantly. The most basic form of communication is car-to-car, where vehicles share things like current speed and direction, known obstacles, etc. with nearby vehicles. If the vehicle is part of a fleet, it will also have to be able to communicate things like current position and payload to a traffic management system.

As this information can be sensitive it is important for the vehicle to be able to set rules for how the data propagates and with whom it is shared. That is, detected obstacles can be public data, position, and heading made available to nearby vehicles, and routing plans are shared only with associated vehicles (e.g. within the same fleet). The groups formed will be of varying dynamicity; the group of nearby vehicles will be highly dynamic while the fleet remains fairly consistent.

The forming of these groups and the maintaining of a healthy state over time by including and excluding members is a central problem for autonomous systems, as agents need to trust the consistency of such groups in order to trust the data.

This is a basic example of the security needed in a self-organizing system where agents can reach consensus in a distributed way. It also suggests how to restrict propagation of sensitive information without human administration.

In a scenario like this, with a shared infrastructure that is constantly changing, security will be unobtainable using traditional infrastructure-based methods.

Instead, we will need a trust based model like HYKER.

--

--

Hyker Security

HYKER End-to-End Security protects the full data lifecycle from a data producer to data consumers, in an unbroken chain, over time, anywhere.