Multiparty authentication and cryptosystems in the IoT – part 3

Multi-party authentication and data protection

Multi-party authentication and data protection can be expressed simply as  “2 +N”, meaning that “more than 2” entities are involved in a shared cryptosystem.  Additionally, this multi-party system can be  “horizontal” and “cascading”[1]

The crux of these multi-party systems is that each participate “recreates” the keys common to the crypto-system versus sharing keys under either symmetric or public key systems.

Multi-party authentication and data protection

Multi-party authentication is not necessarily a novel requirement for access to date; there are many use-cases where many entities need access to a secure resource of info base.

For instance, dozens of public safety personnel need access to the secure, encrypted radio channel. However, trying to secure these infobases using symmetric or public key systems becomes much less secure or exponentially more expensive as the number of participating parties grows.  In the case of symmetric (shared-key) systems, the more copies of the keys that are distributed, the greater the potential a copy “leaks” or is disclosed in an unauthorized manner and compromised the entire system. In the case of public key systems, encrypting the infobase means managing many unique keys one for every participant!

In the IoT, with all its wealth of personally identifiable data flowing around, there will be an operational requirement to be more explicit about what information is available to whom.  For instance, you may grant access to your health information to your doctor working from a hospital system; but not your doctor working from her home systems.  In practice, the combination of your permission plus the doctor’s consent, plus the hospital system’s approval may be required to unlock your info in the data store. In this case, three parties are required to collaborate in a cryptosystem to unlock your health record or the patient, the doctor and a device must be located within the hospital, for instance.

Another example of a multi-party operational requirement might be identical nodes operating in unison as a critical sensor network; or they may be highly interdependent elements performing different tasks.  In either example, it may be the case that fail-safe means to cease operation as soon as one of the elements fails, stops sending data or responding to a heartbeat or beacon.  Since masquerade attacks against these system?? would be a major vulnerability, authenticating each node related to their response to a heartbeat or beacon may be required.   A multi-party authentication system based on a single key that can be re-created among all participants would be far better than a system based on a common key shared among all participants, or worse, a massively expensive public key system.

A consumer-oriented operational use-case could relate to something like photo sharing among friends.  Rather than trying to encrypt the same photos for multiple public keys, encrypt it once using a key that can be created strictly by the 2 +N co-owners model of authentication. In this model of multi-party authentication and data protection, the best elements of shared key and public key are retained, while the weak or expensive characteristics are left out.   No storage of keys is required on the endpoints – just enough memory to initially derive a common key, split it, and distribute the pieces among multiple parties.  To do so it requires only a small amount of memory and processor – enough to generate and split a common key. The only requirement is an awareness of how many parties are actually included in the “multi” part of multi-party: how many peers or participants are needed to recreate the key?

Multi-party Horizontal authentication and data protection

The first form of multi-party authentication is “horizontal” in nature: that is, the system can scale to an unlimited number of equally privileged participants.

“Horizontal” refers to the ability of an unlimited number of peers to derive a common shared key, but from unique credential-properties: none of the participants, or peers, need to share their credentials to derive the same key.  This is like shared key, but the key is derived versus embedded or stored.   Attempting to replicate such functionality under a public key system would require that a shared key be uniquely encrypted by each horizontal peer.

Multi-party Cascading authentication and data protection

Related to horizontal authentication and data protection is multi-party cascading authentication and protection.  The distinction in this case is the ability to split credentials-properties (credentials) assigned to a given party, into potentially an infinite number of times.  Splitting credentials means that an IoT element (person, device, service, whatever) can take their peer to peer,  horizontal credential and split it in n, for the purposes of further controlling usage from a group of hierarchically lower peers.

See Figure 1: Multi-party cascading authentication and credentials

 For example, using health information again:  a hospital encrypts medical records with a key derived from merely two credentials:  one from the patient and one from the hospital.  To decrypt and access this record, the infobase needs the patient credential and a credential from the hospital.  The hospital then splits its own credential into two or three or four different horizontal, peer credentials.   (For instance, hospital systems, insurance systems, privacy ombudsman and an assigned doctor).  In one scenario, for the patient records to be accessed, at least one of the four medical stakeholders must supply their unique credential credentials to generate the single hospital credential, which is then combined with the patients’ own credential to create the key and decrypt the patient records.   In an alternate scenario, the crypto-system designer may require that 2 out of 4, 3 out of 4 or all 4 out of 4 peers in this cascading hierarchy must provide credentials in order to generate the higher level key-half. See Figure 1: Multi-party cascading authentication and credentials


[1] Mathematics to support such authentication and crypto system have long been known, see Euler’s work from 1779 on Polynomial theorems.    The effort now required is to convert these theorems’ to the entropy sources.

Leave a Comment

2 × 3 =