VIBE Cybersecurity Whitepaper
Modern Security for the Internet of Things

Delivering Authentication, Ironclad Security, Confidentiality and Trust for Today’s & Tomorrow’s Internet of Things

About VIBE Cybersecurity International LLC

VIBE Cybersecurity International, LLC (hereafter, VIBEcyber) is headquartered in Hamilton, Bermuda, with resources based in APAC, the EU and the Americas. Its patented, certificate-less, cryptographic technology disrupts traditional authentication and key management/exchange protocols, eliminating the need for Public Key Infrastructure.

VIBEcyber’s mission is to use its technology to eliminate cyberattacks, thereby rendering our world a safer place.

Publication Acknowledgements

Contributors

Olivier Rouit Senior Embedded Security Architect
Dr. Paul Germouty Cryptographer
Mike Larkin Chief Marketing Officer
Dr. Hisham Lamei Chief Operating Officer

Information Sources

  • Statista
  • TechCrunch
  • CSO Online
  • Accenture
  • International Airport
  • IDC
  • Markets and Markets
  • Review
  • Ponemon Institute
  • Network World
  • Bain and Company
  • Altman, Valandrie & Co
  • Kaspersky
  • Security Week
  • Verisign Inc.
  • The Independent
  • ThreatPost
  • Swift
  • New York Times
  • Akamai

Target Audience

This whitepaper is intended for individuals, governments, and enterprises that are engaged with Internet of Things initiatives as either an end customer, service or platform provider, or manufacturer.

It is structured to appeal to CEOs, CSOs, CISOs, CTOs, Cryptographers and IT and IoT Infrastructure Specialists.

Executive Summary

This document is intended to assess the state of the Internet of Things (IoT), examine the effectiveness of the current cryptographic approach to IoT Security, and explore the potential of better protecting IoT and its many stakeholders, through application of modern cryptographic schema.

Our connected world has and will continue to undergo dramatic change as more and more devices are connected to the Internet, ushering in an era that is commonly referred to as the Internet of Things or IoT. Pundits forecast over 75 billion IoT devices by 2024, and by 2030 IoT’s impact on global GDP will be $14.2 trillion US dollars. The IoT security market alone is projected to reach almost $70B by 2025. And while the rapid emergence of IoT holds rich promise for so many industries, in the quest for market share, device manufacturers and IoT service providers alike have widely eschewed security. Lack of security may be considered acceptable in some consumer devices, but it is anything but for industrial IoT applications. The list of cybercrimes in this segment includes documented attacks on power grids, water systems, nuclear facilities and hospitals – all considered critical infrastructure. As a consequence, studies by respected industry analysts like Bain and Company confirm that security is the single largest barrier to IoT adoption.

Efforts are being made to shore up IoT security but, unfortunately, the approach that is being adopted by every company that Network World considers a Top 20 IoT Influencer (and every other market player) relies on a cryptographic protocol designed last century – Public Key Infrastructure (PKI). PKI is thought to bring value when properly implemented for corporate environments, but is woefully inadequate for IoT on so many levels. It’s highly vulnerable to outside attacks (a fact that has been repeatedly proven), it’s highly complex to the point where experts estimate that only 5% of all PKI deployments are implemented correctly, and it is very costly to deploy and maintain. Further, PKI cannot easily or economically scale to the levels required for IoT. Put simply, PKI is technology conceived and deployed in another era, for another purpose. The world needs to explore modern cryptography for IoT as a means of better protecting nations, their infrastructure, their businesses and the people that they serve.

The solution to IoT security lies in adopting a standardized cryptographic schema, Identity Based Encryption (IBE), that was first commercialized in 2001, and has since been improved through recent academic research that has rendered IBE modern, and ideally suited for protecting the Internet of Things and all that term encompasses. Commercial IBE was the product of a Stanford University Research project, funded by the US Department of Defense (DoD). IBE carved out a strong market position in the encrypted email and payment markets, and while an effective, secure cryptographic schema in these niches, IBE from 2001 is not suitable for IoT. Like PKI, this version of IBE is vulnerable – particularly to man-in-the-middle attacks – and is not operationally viable for IoT.

Modern or Verifiable IBE (VIBE) was conceived in 2012, is patented in the US, China and the EU, and was further improved in 2019 (patent pending).

VIBE is an ingredient that can be easily embedded in others IoT solutions, including devices, products, gateways, platforms and services. The VIBE embedding process is accomplished using VIBE’s Software Development Kit (SDK), which includes Application Programming Interfaces (APIs), with more being developed on an ongoing basis. VIBE has an extensive list of supported hardware, including leading HSM and semiconductor providers, and it continues to expand its supported-hardware roster.

As illustrated by images in this document, VIBE enables the creation of a system in which every ‘thing’ in a given IoT ecosystem has a VIBE-embedded chip inside, and is registered in a VIBE Trusted Centre (TC). The TC is housed in a Hardware Security Module (HSM), with both the TC and the HSM owned and operated by the end client or its designate (VIBE Cybersecurity or its agent has no access or visibility to any identities registered in the TC). Once set up, the TC can be taken offline, and from that point forward, all registered devices/people can securely communicate with other members from the same TC. Each message is fully authenticated as coming from and going to devices/people registered in the TC, and all communications are peer-to-peer (P2P).

There are no digital certificates with VIBE, so it easily scales. Tampering becomes impossible in what amounts to a tightly-closed, decentralized security loop. Should members in one TC need to communicate with members of another, this is easily accomplished through permission-based rules. For example, vehicles registered in one TC could, with permission, communicate with the transportation devices (like street lights) housed in another - all peer-to-peer, with both TCs offline.

In summary, a VIBE cryptosystem is less complex, significantly less costly (50-60%) and substantially more secure than current PKI crypto systems. VIBE offers advantages to every IoT ecosystem, including securing consumer applications, however its greatest value lies in its ability to effectively and economically protect Industrial IoT embedded infrastructure from outside threats.

Organizations that are involved in providing Industrial IoT services, platforms, products and components are encouraged to explore the potential inherent in Verifiable Identity Based Encryption (VIBE), particularly if their offerings are part of mission-critical infrastructure.

Chapter 1: Setting the stage for IoT and M2M Security

The Internet of Things (IoT) broadly refers to devices and equipment that are readable, recognizable, locatable, addressable and/or controllable via the Internet. This includes everything from edge computing devices to home appliances, from wearable technology to cars, from simple connected things to mission-critical ones embedded in critical infrastructure, such as energy grids, water supply systems and nuclear facilities.

Machine-to-Machine (M2M) communication (which we consider a sub-set of IoT) is when two machines exchange data without human interface or interaction. M2M communication is point-to-point between machines, sensors and hardware, over wireless or wireline networks.

With over 23 billion devices already deployed (source: Statista) [1], the IoT is already dramatically changing our connected world, delivering benefits on numerous fronts across virtually every industry. Unfortunately, there are some very serious security issues with IoT, which are severely limiting its growth, and are ushering in an era of unprecedented danger.

In this paper, we will elaborate on the current state of IoT Security, and examine Verifiable Identity Based Encryption as a means of delivering economical, scalable, ironclad security to the Internet of Things.

1.1 IOT BY THE NUMBERS

The number of deployed IoT devices is projected at 75.44 billion by 2025.

Fig 1: Projected IoT device increase

By 2030, the IoT is projected to have a $14.2 Trillion impact on the Global GDP [2].

Table 1: IoT trends in numbers

The market for IoT security is large and growing rapidly, with Markets and Markets projecting that it will reach $29.02B by 2022 [3].

Fig 2: IoT market growth 2017 - 2022

Assuming the forecasted 34% CAG continues, the IoT security market size will be approximately $69.8B by 2025.

1.2 CURRENT IOT LANDSCAPE

The sheer size and projected growth of the IoT market has attracted vendors that address virtually every segment within the vast IoT ecosystem. IoT devices are quickly becoming part of a consumer lifestyle as everything from refrigerators to thermostats to the clothing we wear is being embedded with sensors that enable them to communicate over the Internet.

Industrial IoT (IIoT) is a paramount, very active market segment as businesses worldwide strive to leverage the many advantages inherent in accessing addressable and controllable devices. Examples of productivity improvement due to IIoT installations abound in industries such as agriculture, manufacturing, transportation, construction and health care.

The rapid growth of IoT is currently driven by consumer applications in the smart home, personal wellness (wearables), and connected vehicle infotainment segments (source IDC) [4]. The consumer IoT segment represents 20% of the current market, and it is the second largest IoT segment after manufacturing. Once 5G networks are broadly deployed, however, we can expect to see business IoT markets quickly grow with the process industries, transportation and energy sectors expected to account for almost 50% of the global market by 2022.

According to Network World [5] the 20 most influential IoT participants are as follows

Table 2: Leading IoT market players | Source: Network World; 2018

But despite many of the world’s largest, most successful companies being fully engaged in the IoT market, the state of IoT security is best described as dire. IoT security breaches are seemingly an everyday occurrence, and the list of serious cybercrimes includes documented attacks on connected cars [6], power grids [7], water systems [8], nuclear facilities, and the critical infrastructure supporting hospitals [9], and airport security systems [10].

According to Bain and Company, inadequate security is the leading barrier to IoT adoption

Fig 3: IoT adoption barriers

Chapter 2: Cryptographic Schema and Encryption Methods

Exchanging data securely is not a new challenge, and there are several cryptographic schema widely used for this purpose. While each has its place and value, none of the more popular protocols were designed in this era – so by definition they were conceived and commercialized without considering the security challenges inherent in IoT.

2.1 SYMMETRIC ENCRYPTION

Fig 4: Principle of symmetric encryption

A symmetric encryption scheme is where the sender and the receiver must share a common secret to communicate. The best known, and most widelyused symmetric encryption algorithm, is the Advanced Encryption Standard (AES), first published in 1998 and standardized by the US NIST in 2001. In a symmetric algorithm, the encryption and decryption of a message is accomplished by using the same key. In most scenarios, the message sender and recipient do not share common secret information prior to the encryption of a message. The means of exchanging a common key without prior sharing of any information is done using Asymmetric/Public Key Encryption

2.2 ASYMMETRIC / PUBLIC KEY ENCRYPTION

Fig 4: Principle of symmetric encryption

A public key encryption scheme make use of two different keys - a public key to encrypt, and a private key to decrypt a message. A user must publish its public key related to its private key, and the key pair must be unique.

The best known and most widely deployed asymmetric public key encryption is the RSA cryptosystem, developed in 1976, patented (US only) in 1983, and released to the public in 2000 – two weeks prior to the expiration of the patent.

The RSA algorithm involves four steps: key generation, key distribution, encryption and decryption. An RSA user creates and then publishes a public key based on the factoring of two large prime numbers. The prime numbers must be kept secret. Anyone can use the public key to encrypt a message, but only someone owning the Private Key (with knowledge of the factored prime numbers) can decode the message.

RSA and all asymmetric cryptography is relatively slow, and because of this, it is rarely used to directly encrypt/decrypt user data. That is why RSA, like most public key cryptographies, is normally implemented as a hybrid encryption scheme.

2.3 HYBRID ENCRYPTION

Hybrid Encryption (HE) is a cryptosystem which combines the convenience of a publickey cryptosystem with the efficiency of a symmetric-key. By leveraging the strengths of each form of encryption, HE delivers faster speed and a higher level of security.

A Hybrid Encryption cryptosystem makes use of combined encapsulation schemes:

  • a key encapsulation scheme, which is a public-key cryptosystem.
  • a data encapsulation scheme, which is a symmetric-key cryptosystem.

The hybrid cryptosystem is itself a public-key system, whose public and private keys are equal to those of the key encapsulation scheme.

Public-key cryptosystems are convenient in many ways, including not requiring the sender and receiver to share a common secret to securely communicate. However, they require complex mathematical computations, and are generally much more inefficient than comparable symmetric-key cryptosystems. For many applications, the high cost of encrypting long messages in a public-key cryptosystem is an unacceptable threshold.

2.4 IDENTITY BASED ENCRYPTION

Identity Based Encryption (IBE) is an asymmetric cryptosystem first conceived in 1984 by renowned cryptographer, Adi Shamir. However, it wasn’t commercialized until 2001 when Stanford University professors Dan Boneh and Matthew Franklin published a paper on the first full-featured, efficient and provably-resistant IBE.

In the Boneh-Franklin model, the user's public key is calculated based on the identity of the user, which could be the user‘s name, e-mail, mobile phone number, etc. In the initialization phase of the scheme, the services of a trusted, key-generation center are required for the calculation of the user’s private key. At the user's request, and upon completion of a specific authentication procedure, the Trusted Centre provides the private key.

The biggest advantages of IBE is that it eliminates the need for Public Key distribution and ongoing management.

Chapter 3: Understanding Public Key Infrastructure (PKI)

PKI is a set of policies and procedures designed to establish secure information exchange. It uses a combination of public and private "keys" to encrypt messages, and to authenticate the identity of the sender of a message.

PKI implementations include: digital certificates which hold the public keys; a Certificate Authority (CA), which issues and validates the certificates; a Registration Authority (RA) which tells the CA whether to issue the certificate, and one or more directories to hold the certificates. By accessing a public directory which houses certificates, the sender uses the recipient's public key to encrypt a message, and the recipient uses its private key to decrypt it.

3.1 PKI ARCHITECTURE

There are five steps required in the end-to-end PKI process, with each described below the following graphic.

Fig 6: PKI communication concept
  1. To ensure the authenticity of its public key, the subject sends a certificate to the relying party.
  2. To get a certificate on its public key, the subject asks a Registration Authority (RA).
  3. The Registration Authority then issues a certificate request on the public key of the subject. This request is made to the Certificate Authority (CA), which could be a government, or any independent, trusted third party.
  4. To create a certificate, the CA needs its own certificate delivered by a more secure party called the root CA. This root CA is online only to issue CA certificates, making it more difficult to compromise.
  5. The root certificate allows the relying party to verify the certificate of the subject.

PKI also requires a Certificate Revocation List (CRL) to deal with stolen or expired certificates, adding another layer of complexity to the architecture.

Fig 7: Handling Revocations in PKI

This CRL list can also be modified by the root CA in case an entire CA is compromised.

3.2 PKI STRENGTHS

PKI has been quite effective in providing security for large corporate or government environments when properly implemented (which is the operative phrase, and the exception).

3.3 PKI WEAKNESSES

PKI is Vulnerable to Cyber Attacks: The weaknesses identified in PKI-protected data have been known for some time. Respected publications like Security Week [12] exposed the inherent problems with PKI over seven years ago, citing cases of hackers taking control of Certificate Authorities, and numerous instances of stolen certificates.

In 2014, researchers from the University of Maryland released an academic report [13] which confirmed that there is a serious problem with PKI certificate abuse that traces back to nation-state attacks such as Stuxnet and Flame. And as the research confirms, this is hardly a one-of-a-kind situation. Of 150,000 malware samples examined, over 2% originated with “valid” certificates. Digitally-signed malware can bypass systemprotection mechanisms that only install or launch programs with valid signatures. It can also evade antivirus programs.

More recently, according to Akamai, attackers have been tampering with TLS signatures at a scale never before seen by using cipher-stunting – a TLS tampering technique that helps malicious bot activity masquerade as live human traffic on the web [14].

“The TLS fingerprints that Akamai observed before cipher stunting was [first] observed [in Oct 2018] could be counted in the tens of thousands,” the researchers said. “Soon after the initial observation, that count ballooned to millions, and then recently jumped to billions.”

The analysis also worryingly showed that the majority (82 percent) of the malicious traffic (including application attacks, web scraping, credential abuse, etc.) that Akamai witnesses is carried out using [theoretically] secure connections over SSL/TLS [which relies on PKI].

PKI is Complex: According to CSO Online, ”complexity is the enemy of good computer security” [15]. The more moving parts a solution has, the easier it is to find weaknesses, and the harder it is to implement. Few computer security defenses have more moving parts than PKI.

Not only do users make mistakes due to PKI’s complexity, so do most PKI administrators. Estimates from experts in the field are that only 5 percent of PKIs are set up correctly. Most have multiple errors. In fact, most have critical errors -- which is unacceptable when PKI is supposed to be the building block of one‘s security strategy.

PKI is Costly: Estimates vary but most place the three year total cost of ownership (TCO) of a large fully-managed PKI solution at $167 per user/thing. An outsourced corporate system supporting 100,000 users/things would cost approximately $16,700,000 or $5.67m annually. Smaller systems in the 1,000 to 10,000 range are more costly, with the three-year TCO rising to $333/user. (Source: Swift/SEALWeb – Feb 2012) [16].

3.4 PKI COMMON APPLICATION SEGMENTS

3.4.1 DIGITAL SIGNATURE AND AUTHENTICATION

A digital signature is a mathematical scheme for verifying the authenticity of digital messages or documents. A valid digital signature gives a recipient reason to believe that the message was created by a known sender (authentication), and that the message was not altered in transit.

Digital signatures employ asymmetric cryptography, and are a standard element of most cryptographic protocols. They are commonly used for software distribution, financial transactions, and in other cases where it is important to detect forgery or tampering

Digital signatures and authentication are most commonly deployed using Public Key Infrastructure.

3.4.2 SECURE SOCKET LAYER (SSL) / TRANSPORT LAYER SECURITY (TLS)

TLS and its predecessor, SSL, are cryptographic protocols designed to provide communications security over a computer network. Several versions of the protocols are widely used in applications such as web browsing, email, instant messaging, and voice over internet protocol (VoIP). The vast majority of websites use TLS to secure communications between their servers and web browsers.

TLS connections should have the following properties:

  • The connection is private (or secure) because cryptography is used to encrypt the data transmitted. The keys for this encryption are uniquely generated for each connection, and are based on a shared secret that was negotiated at the start of the session (aka The TLS Handshake). For performance reasons, bulk data is usually encrypted using symmetric cryptography, though TLS can encrypt data using asymmetric or public key cryptography.
  • The identity of the communicating parties can be authenticated using public key cryptography.
  • The connection is reliable because each message transmitted includes a message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission.

Chapter 4: IoT Security Challenges

In the rush to market, most IoT device manufacturers eschewed security in the absence of a practical, economical way of protecting their products from outside attacks. As a result, according to a recent Ponemon Institute report [17], a staggering 80% of all IoT devices have security vulnerabilities, meaning the billions of connected devices today represent an immense attack surface of non-secure endpoints and web interfaces for hackers to exploit. A 2017 Altman, Vilandrie & Company survey [18] showed that almost half of all U.S. companies that use IoT devices have been hit by a security breach. This is alarming, and it’s also very costly. The same survey pointed that out that the average cost of an IoT security breach for a $5m company was $650,000, with larger companies absorbing costs of over $20m.

So, the IoT security challenge becomes not only about protecting future devices and the networks, platforms and applications which engage them – the entire IoT ecosystem – but dealing with the security risk inherent in the embedded IoT base. And part of dealing with the existing risk is accepting that it cannot be retroactively eliminated: rather, it needs to be managed as well as possible which might include detecting and minimizing the impact of IoT breaches when they occur.

In the longer term, vulnerable IoT devices need to be replaced by ones that are secure. Unfortunately, that’s not as easy as it sounds as the vast majority of them possess minimal processing and storage space. Still, this challenge can be addressed with modern cryptographic schema that have significantly less power and space requirements.

Securing the entire IoT ecosystem going forward brings its own set of challenges:

Challenge #1: End-to-end security
VIBE provides end-to-end security, as it creates communities of trusted users. Each communication between users/things is secured and authenticated because of the nature of the VIBE technology, which guarantees that only the receiver can extract the data and verify that it was sent by the proper sender. VIBE is an ideal technology to implement security at the application layer, and can be added to any application using a simple Application Programming Interface (API).

Challenge #2: High number of exchanges
In a communication scenario involving a very large number of devices, it is important not to overload the network. Because VIBE doesn't require certificates nor their verification, in a network of n devices VIBE reduces the number of exchanges from O(2n) to O(2n). The size of the overhead during an exchange is also smaller, as only the IDs are exchanged. The data used to protect a symmetric key and sign the data is only 1KBit. This makes VIBE an efficient protocol to secure high numbers of single data exchanges.

Challenge #3: Protecting the Keys
In order to ensure a high level of security, the Private Key of a node needs to be well protected. If the Private Key is corrupted or stolen, all communication between that node and others can be intercepted and corrupted. To avoid that type of scenario VIBE can be embedded in a hardware secure element (HSE). VIBE only requires 17Kbytes of RAM to execute, so HSE capacity is not an issue. Also, as VIBE is based on an ECC pairing (as outlined in Chapter 13.2), it can use standard hardware accelerations.

Chapter 5: Assessing the Current Approach to IoT Security

Today, the vast majority of efforts to secure the IoT rely on Public Key Infrastructure (PKI). Looking only at the IoT platform providers among the top 20 IoT companies, reveals that PKI is effectively their de-facto approach to security, with most directing their customers to acquire their own certificates from a CA of their choice.

Table 3: Despite better solutions, PKI is still the technology of choice

The threats identified by most IoT platform providers are consistent. Microsoft Azure, for example, identifies the core elements of a threat model, as follows:

  • Processes (both under your control and external items)
  • Communication (also called data flows)
  • Storage (also called data stores)

The Azure documentation goes on to identify the major methods used by cybercriminals to exploit IoT configurations.

Spoofing (S): An attacker may extract cryptographic key material from a device, either at the software or hardware level, and subsequently access the system with a different physical or virtual device under the identity of the device the key material has been taken from.

Tampering (T): An attacker may partially or wholly replace the software running on the device, potentially allowing the replaced software to leverage the genuine identity of the device if the key material or the cryptographic facilities holding key materials were available to the illicit program. For example, an attacker may leverage extracted key material to intercept and suppress data from the device on the communication path, and replace it with false data that is authenticated with the stolen key material.

Information Disclosure (I): If the device is running manipulated software, such manipulated software could potentially leak data to unauthorized parties. For example, an attacker may leverage extracted key material to inject itself into the communication path between the device and a controller or field gateway or cloud gateway to siphon off information.

5.1 TECHNOLOGY CONSTRAINTS IN IOT

While IoT deployments offer many benefits, including cost savings, energy conservation, process improvements and superior monitoring and control, IoT presents many technological challenges. Devices designed for optimal performance often compromise privacy, and when well-designed solutions are available, they often face implementation barriers which aren’t always solvable at the device/sensor level, creating demand for new, modern IoT architectures.

Protecting privacy and delivering trusted IoT offerings requires security measures such as authentication and encryption. Both, however, are difficult to implement in lowpower networks, lightweight sensor hardware void of key acceleration technology, and in power-hungry computing devices.

Other technology constraints exist in IoT solutions that might require continuous network availability, such as Vehicle-to-Vehicle (V2V) applications. In this segment one has to differentiate between Vehicle-to-Backend (V2B) 4G & 5G connectivity and V2V or V2X connectivity. While car manufacturers have been securing their V2B connections via PKI, this crypto technology is totally inadequate for short-range radio V2V connectivity, where backend connectivity to a Certificate Authority cannot be guaranteed. Securing V2V communication has to, therefore, be accomplished by allowing offline secure operation as loss of connectivity (through mobile network disruptions, roaming handover cuts, etc.), and the resultant inability to communicate V2V, would create a very dangerous, life-threatening situation.

Considering the over 1.2 trillion vehicles on the planet today, a much leaner, more manageable security technology for both authentication and encrypted communication is needed, none of which can be provided with the current PKI-based approach to securing the IoT.

5.2 THE CLEAR CONCLUSIONS

The current PKI-based approach to IoT security is woefully inadequate, and is failing miserably. PKI is not designed for IoT, and the forced-fit approach into this market has exposed its many weaknesses. PKI is costly, complex and doesn’t scale to the massive levels required in IoT. Further, given the vast number of fake and un-revoked certificates in market today, PKI has known vulnerabilities that have, and will continue to be, repeatedly exploited.

The stakes are incredibly high. With the rapid emergence of IoT, and seemingly unchecked connection of non-secure devices to critical infrastructure, threats to nations globally are growing exponentially. And the IoT devices are not the only weak link in the digital chain, as IoT’s scope is much broader, encompassing tens of billions of embedded sensors intelligently transmitting data over a mix of wired and wireless networks. To make matters worse, while we tend to know which devices are connected to our infrastructure, and have put some effort into authenticating them – flawed as those efforts are – we have no visibility nor means of authenticating the vast number of sensors embedded in critical infrastructure.

The situation is dire, and the solution lies in understanding and applying the principles inherent in modern Verifiable Identity Based Encryption – VIBE.

Chapter 6: Identity Based Encryption and IoT

6.1 THE INITIAL IBE SCHEMA

The Boneh-Franklin IBE cryptosystem, the foundational standard upon which VIBE is based, has enjoyed great commercial success in one market in particular - encrypting email. The IBE protocol protects tens of millions of corporate email users worldwide, economically eliminating the complexity of key management that plagues so many email systems, while providing a relatively high level of security.

And while an effective, proven standard, IBE was conceived and commercialized long before the emergence of the Internet of Things. Like PKI, the classic IBE schema has weaknesses, and is therefore lacking in is ability to fully protect an IoT ecosystem.

6.2 DEFICIENCIES OF THE INITIAL SCHEMA FOR IOT

IBE has two inherent weaknesses that render it ineffective for IoT:

  1. IBE cannot viably validate the sender of a message. In IBE, the identity of the message recipient is the secret key that is used to encrypt a message. This guarantees that the message is sent to the intended recipient. And while this is an important feature, what’s equally crucial is to know the identity of the sender of the message. This is effectively impossible and highly impractical with the initial IBE schema, given the very high computational requirements and related prohibitive communication costs.
  2. IBE is susceptible to Man-in-the-Middle attacks on the Public Parameters. IBE relies on Public Parameters (PP) - an information string generated by the authorized authority (e.g. Trusted Centre “owner”) that manages the IBE system. A traditional IBE configuration attaches the PP to the message packet, enabling the user to use the PP to encrypt and send the message to the receiver, who decrypts it with the Private Key. And while effective, there are operational, financial and security drawbacks with this method. The larger amount of data that needs to be exchanged increases cost, requires more power and is more time consuming, as full message encryption/decryption is required. Also, the public parameters need to be stored in a secure environment, significantly increasing costs.
    When the public parameters are changed, which is a fairly common occurrence in a dynamic IBE environment, there is no way of verifying that they haven’t been altered, placing the entire IBE system at risk.

The IBE Initial Schema, while very effective in its niche market, is not suitable cryptography for the IoT.

Chapter 7. Introducing VIBE: Modern IBE designed for IoT

VIBE (Verifiable Identity Based Encryption) applies recent academic research which yields much greater efficiency in the computation of pairings over elliptic curves than IBE, creating a more secure, very practical public key scheme.

As an Identity Based Encryption scheme, the ‘public key’ is an identity string which is combined with a set of public parameters to compute an encrypted packet used to protect a symmetric key that then encrypts a larger set of data. The private key is generated by the Trusted Centre (TC) using its Master Key and the identity of a device.

VIBE differs from a classic, certificate-based PKI crypto system in many ways. Unlike PKI, VIBE doesn’t require certificates to verify the identity of the devices registered in a given TC. The private key of each participant verifies the validity of the public parameters, which guarantees that they haven’t been tampered with, and that the encryption is being done for a recipient belonging to the correct system. VIBE also authenticates the sender, using its private key to trace the sender of a message, thereby eliminating the threat of a man-in-the-middle attack.

VIBE removes the need for certificates, greatly simplifies key management, and is well suited for peer-to-peer communication.

The computation of pairing requires more computing power and memory than classic public key cryptography like RSA or ECC. However, it can still be efficiently implemented in a Secure Element as long as one can provide a hardware public key accelerator, and at least 17Kbyte of RAM.

Like any public key scheme, VIBE can be securely implemented in any computing environment that provides secure storage to protect its secret key, a trusted space for the execution of the algorithms and optionally, a hardware public key accelerator to achieve better performance.

VIBE eliminates the two main obstacles which prevent IBE from being suitable for IoT. Specifically:

VIBE Verifies the Sender of a Message: Unlike IBE, with VIBE the keys used to encrypt a message are also used to sign the message, thus the sender of the message is clearly identified. (If this feature is not desired, encryption can be done without the signature). Seamlessly and simultaneously verifying the sender and recipient of a message represents a giant step forward in securing our connected world.

VIBE Eliminates the Need to Protect the Public Parameters: VIBEverifies the PP with a patented, unique, much faster encryption/decryption algorithm than is used in IBE. Verification with VIBE can be done before any encryption, providing assurance that the PP have been computed by the same TC. This modern algorithm renders the message communication process substantially faster, while dramatically reducing power consumption. Further, it eliminates the need to store the public parameters in a secure environment, significantly reducing costs. Most importantly, VIBE completely eliminates the threat of MITM attacks that are possible in IBE.

Chapter 8: VIBE Components and Architecture

In the following sections we will outline the Components utilized in a generic VIBE cryptosystem, the end-to-end VIBE Software Architecture, and a VIBE Trusted Execution Environment using both a Hardware Secure Module (HSM) and a Secure Hardware Element (HSE)

8.1 VIBE COMPONENTS

VIBE can be securely implemented in any computing environment that provides secure storage to protect its secret key, and a trusted space for the execution of the VIBE algorithms. Optionally, a hardware public key accelerator can be utilized to achieve better performance.

The following diagram shows the components of the VIBE implementation in a generic trusted environment. The components can vary depending on the hardware architecture of the trusted environment. For example, some components can be replaced using hardware that provides higher security and optimizes performance, such as a True Random Number Generator (TRNG), a Public Key Accelerator (PKA), and a Hardware Key Storage driver to store the VIBE system’s secret keys.

Fig 8: Components utilized in a typical VIBE Cryptosystem

8.2 VIBE SOFTWARE ARCHITECTURE

The following diagram shows the software architecture of a VIBE Cryptosystem that delivers and ensures end-to-end secure communication. The uniqueness of VIBE is that this superior level of security can also be achieved over a non-secure communication channel.

Fig 9: End-to-end VIBE architecture

8.3 VIBE TRUSTED EXECUTION ENVIRONMENT

Optimum security is realized when VIBE is deployed in a Trusted Execution Environment (TEE). There are many TEEs available today, providing different levels of security. The highest level of security is achieved by a hardware secure element chip. A reasonable level of security can be attained using, for example, the Trust Zone of ARM core processors.

When the back-end application being supported is considered mission-critical (e.g. all critical infrastructure and Industrial IoT applications), the VIBE Trusted Centre and encryption algorithms must be deployed on a Hardware Security Module (HSM). This TEE configuration ensures both optimum security, and superior throughput.

8.4 VIBE - HARDWARE SECURITY MODULE (HSM)

An HSM is a powerful Trusted Execution Environment which enables high-level security for back-end applications. It provides a safe execution space for cryptoalgorithms, secure storage for secret keys, and a high entropy True Random Number Generator (TRNG) for key generation.

An HSM accommodates standard interfaces like PKCS11 and CNG, as well as a native interface that can be used to implement any proprietary protocol like the one required for the VIBE Trusted Centre (TC).

An HSM is the recommended security device to house the VIBE TC that provides the root of trust in a VIBE-enabled system. The VIBE TC is tasked with creating the TC Master Key which requires the highest TRNG quality possible. It also needs to store this key in a highly-secure storage module. Because a VIBE TC doesn’t need to store much data, the same HSM can easily be used to host several TC Master Keys, allowing it to manage several VIBE applications.

Fig 10: VIBE Hardware Security Module architecture

8.5 VIBE - HARDWARE SECURE ELEMENT (HSE)

A Hardware Secure Element is a System On Chip (SOC) that provides an MCU, RAM, Secure Flash, a hardware accelerator for public key operation, a True Random Number Generator (TRNG), and a safe execution space for the crypto-algorithms. The HSE also provides a hardware interface, like I2C or ISO7816, when connected to a main computer system or to an IoT board.

The Secure Flash of the HSE is used to store sensitive data like the private key, and the pre-calculated data used to optimize the algorithm execution for the most utilized connected devices.

As the computing power of an HSE is often limited, it provides a Hardware Accelerator dedicated to optimizing the calculations needed for the sophisticated mathematics of cryptography. The most secure HSEs also provide hardware counter measures to prevent side-channel attacks during the execution of the algorithms, as well as physical attacks against the secure flash memory.

The software architecture of a VIBE implementation is very similar, regardless of hardware. The following diagram shows the specifics associated with implementing VIBE in an HSE.

Fig 11: VIBE Hardware Secure Element architecture

8.6 VIBE CRYPTOSYSTEM - MESSAGE EXCHANGE

Once deployed, the VIBE-enabled communication process is fast, simple, economical, and completely eliminates the threats inherent in PKI

Fig 12: VIBE Message and Communication process

When a device needs to request data from another, it first sends its ID. When all the devices have been setup within the same community this is the only parameter that the peer needs to send.

VIBE uses an asymmetric algorithm that, like any asymmetric scheme, can only protect a limited amount of data, such as a symmetric key. The sender device verifies that its TC parameters haven’t been compromised using its Private Key, then it generates a secret key that is protected using the VIBE encryption algorithm. This encryption is done combining the public ID of the peer device with the TC public parameters. It is to be noted that the peer device can only decrypt the secret if its own Private Key belongs to the TC community, meaning that its key was created by a single Trusted Centre or within a predefined community of TCs. The sender can sign the data with its Private Key in order to authenticate the communication, and make sure that the data hasn’t been compromised.

To note, by its nature the VIBE key exchange mechanism is impermeable to a man in the middle attack as the public key is the ID of the device and the TC parameters are verified before the encryption, making the peer-to-peer communication fully authenticated. Also, to note is that the verification of the integrity of the decrypted data is done by the peer device using its Private Key, and does not involve any public parameter other than the ID of the sender. The complete mechanism doesn’t require any connection to the Trusted Centre in order to verify the identity of the peers, which makes it particularly efficient in term of bandwidth usage as there is no need for any certificate exchange.

Chapter 9: Implementing VIBE

This section will focus on what’s involved in deploying a VIBE-protected IoT ecosystem, and will include insight into the VIBE Modular SDK & API toolkits, VIBE Private Key Registration, VIBE Key Revocation and Reissuance and VIBE Trusted Centre Optional Set-up for Critical Infrastructure Configurations.

9.1 VIBE MODULAR SDK AND API

First, it’s important to note that VIBE is not a stand-alone product or service. It is a sophisticated cryptographic “ingredient” that can be integrated into any type of application to provide stellar end-to-end security. The ingredient is provided in a Software Development Kit (SDK) that enables integration of the VIBE technology into any existing system, thereby rendering it and the applications it provides, highly secure and trusted.

A VIBE-secured cryptosystem requires a VIBE Trusted Centre (to manage the system’s keys), and a secure implementation of VIBE for each of the system’s nodes. Both components are provided via a set of Application Programming Interfaces (APIs) that allow for embedding VIBE security within every element of a system.

A VIBE Trusted Centre is implemented in a backend server as a REST API, and the VIBE algorithms are preferably housed in a Hardware Security Module to ensure the highest level of security. The Trusted Centre API enables the integration of the VIBE key management capability, and the maximum security for the control server of the system.

The following diagram shows the software architecture of a VIBE Trusted Centre using an HSM, and shows the REST API layer used to integrate VIBE into a system.

Fig 13: VIBE Trusted Centre WEB API

VIBE enables secure and authenticated, peer-to-peer exchange between devices registered in a given Trusted Centre. The Trusted Centre provides a root of trust as only devices that obtain a private key from the Trusted Centre can communicate.

The VIBE API set is designed to fit any type of hardware configuration, ensuring that virtually any device can be protected by VIBE. VIBE accommodates multiple secure storage options to protect private keys, ranging from hardware secure storage when maximum security is required, to software protection like white box cryptography when a lesser level of security is required, or hardware secure storage cannot be used.

VIBE provides the identical integration API, regardless of the hardware architecture. It is currently available in C for all Windows OS, Linux and Linux-embedded, as well as for micro-controllers.

VIBE has been implemented on the Infineon SLE 97, so it can be added as a security ingredient to an application running on that HSE, or as a standalone security application supplied to a micro-controller host when used as a companion chip.

The following diagram shows the VIBE software API provided to an embedded application that uses a companion HSE to execute the VIBE secure exchange. In this configuration the application calls the VIBE API which handles all the cryptography involved to secure an exchange.

Fig 14: VIBE API to enable security for an embedded application with a companion HSE

The following diagram shows the VIBE API when using an embedded system or a computer that doesn’t provide hardware secure storage, and where no secure element is available to delegate the execution of the VIBE algorithm. The VIBE API which is available to the application remains the same, which makes the integration of VIBE totally transparent to the execution environment.

In the case, when VIBE is not already available for a given hardware and software configuration, it can seamlessly be adapted to that new configuration.

Fig 15: VIBE API to enable security for a non HSE configuration

9.2 VIBE PRIVATE KEY REGISTRATION

A critical step in the VIBE set-up process is the creation and registration of the private key for each device that needs to be secured. The private key of a device is generated by the VIBE TC using its Master Key and the device identity, and it is subsequently securely installed on the device. Once the private key is securely installed, there is no way to impersonate this device as there is a direct link between the device identity and its Private Key, and its home TC Master Key.

The Private Key must be protected with the highest possible level of security, so the ideal approach for installing a Private Key for a device and a given TC, is to pre-install devices with a deployment key which is also installed in the secure storage of the device.

The device Private Key installation process is as follows:
  • The System Administrator authenticates to the deployment server
  • The device is connected to the deployment server
  • The private key is requested for the device
    • The TC generates the key, and
    • encrypts it using the deployment identity and public parameters
  • The deployment server transmits the key to the device which deciphers and installs it
  • The device then deactivates the deployment key

The following diagram shows the end-to-end configuration for the private key deployment. The Trusted Centre is implemented with a multi-tenant HSM which allows for multiple independent systems to be managed by the same HSM. The deployment server is used to create the VIBE firmware, and to manage the key deployment.

Only the administrator of a given system can authenticate to the TC, and install the private key of a device for this system.

Fig 16: VIBE Private Key deployment

9.3 REVOCATIONS, REISSUANCE AND IBE KEY ESCROW CHALLENGES

One of the big challenges of classic IBE is the handling of Key Reissuance, Revocation and Escrow. The IBE concept inherently enables the entity managing the Trusted Centre to recreate any given Private Key (Key Escrow). This is useful in many scenarios, but not in every business segment (e.g. financial services, logistics, healthcare) where there must be assurances that information remains unchangeable/unmodifiable. In addition, traditional IBE requires reissuance of all member Private Keys if even one Key is revoked or reissued.

VIBEcyber has developed a unique approach that solves the IBE Key Revocation, Key Reissuance, and Key Escrow challenges. Details are not available in this white paper, pending filing of patents which are imminent.

9.4 VIBE SCALABILITY & EASY DEVICE DEPLOYMENT

One of the many challenges inherent in any technology deployment is scalability – defined as the capability of a system, model, or function to cope and perform well under an increased or expanding workload or scope. Unlike PKI which is plagued by the burden of certificates to store, manage and exchange for each transmission, VIBE’s certificate-less schema affords its users the opportunity to easily and economically scale to any level on a peer-to-peer basis – including the massive deployment models that characterize IoT.

The VIBE deployment model for a manufacturer makes use of different VIBE groups (VIBE0 and manufacturer VIBE). These communities/groups are completely independent. VIBE0 keys needs to be deployed physically during the Trusted Centre registration process. The deployment is done as follows:

Fig 17: VIBE device enrollment and deployment process
  1. The manufacturer registers with a given Trusted Centre (TC) community called VIBE0.
  2. Once registered, the manufacturer creates its own master private key and publishes the corresponding master public key (which is part of the Public Parameters).
  3. Any TC can then get a user private key for its identity “idTC” in the manufacturer group. This key will be sent by the manufacturer to the TC using the secure channel of the community VIBE0.
  4. The manufacturer then creates private keys for every user/device for the manufacturer group using the identity of the device. This key is called a deployment key.
  5. The device can now connect to any TC, and ask for a private key belonging to that TC and corresponding to the identity of the device. This is done by a simple request, and the TC responds using the manufacturer VIBE secure channel. Note that at this step, TC1 will authenticate to the device via VIBE (manufacturer VIBE).

Chapter 10: VIBE Value-Added Benefits

VIBE has two very market unique benefits that further render it ideally suited for protecting IoT applications

10.1 VIBE IS SOCIAL BY DESIGN

One of the strengths of the VIBE model is that only users registered within the same Trusted Centre can encrypt, decrypt, sign and authenticate messages to each other. However, there might be instances where users registered in a VIBE Trusted Centre have a requirement to securely communicate with users outside the Trusted Centre. This is easily accommodated in the VIBE schema whereby a given Trusted Centre authorizes users in another Trusted Centre to communicate with its members.

In essence, VIBE accommodates an environment of trusted identities, allowing for the creation of open, trusted social groups. A use case example of a “social by design” model might see Traffic Light devices registered in one Trusted Centre authorized to communicate (peer-to-peer) with Vehicular devices registered in another. In this example, The Trusted Centre for a Traffic Light would belong to the group it is managing, and would also belong to the Trusted Centre for Vehicles under a status called VIBE0. With VIBE0 status, the Traffic Light Trusted Centre enables all members in the Trusted Centre to communicate with the Vehicular Trusted Centre users, and vice-versa.

Note that the VIBE0 has no power over other groups. The Trusted Centre of VIBE0 is not able to create keys for groups that are not VIBE0. VIBE0 keys need to be deployed physically during the Trusted Centre registration process.

10.2 VIBE - OFFLINE OPERATION

One of the most powerful and unique features of a VIBE system is that, once every device has completed the registration process, the Trusted Centre can be taken offline, completely eliminating the threat of cyberattacks on the TC. From that point forward, all registered devices can encrypt, sign and authenticate to each other, peer-to-peer. This feature renders VIBE ideal for authenticated machine-to-machine communications, as no third-party management is needed once the registration step is complete.

The Trusted Centre can easily be brought back online to accommodate adds, deletions, changes and any other required modifications. Once the necessary work is done, the Trusted Centre can be returned to offline status.

Chapter 11: VIBE Total Cost of Ownership (TCO)

VIBEcyber’s cryptographic schema is offered as licensed technology, with several available licensing models ranging from not-for-resale annual license fees for governments and enterprises, to fee-per-device licensing for IoT Managed Service Providers and IoT Device Manufacturers.

11.1 VIBE SYSTEM INFRASTRUCTURE AND COMMUNICATION COSTS

As VIBE is only a cryptographic ingredient, VIBE Systems are always built, owned and operated by an end client or its designated supplier, or by a 3rd party Managed Service(s) Provider. The infrastructure for a VIBE system is significantly less than that required for PKI, as the VIBE schema does not require the storage and management of what could be hundreds of millions of keys in an IoT ecosystem.

For example, a typical HSM can accommodate 3,500 certificates, so one would need approximately 100 HSMs to handle an IoT ecosystem of ~350,000 devices. The same IoT ecosystem protected by VIBE would require approximately 20 HSMs, representing an 80% cost reduction.

VIBE also completely eliminates the monthly and one-time fees which are payable to a Certificate Authority, dramatically reducing overall communications costs. A University of Michigan study determined that 99.7% of all certificates delivered are of the RSA variety, which becomes problematic since RSA key size grows exponentially as the security parameters change. For 128 bits AES security, an RSA key size of 3,072 bits is required. For a 256 bits AES security, a 13,000 to 16,000 bit RSA key is needed.

The reduced communication requirements for VIBE versus PKI with RSA is illustrated below.

Table 4: VIBE vs PKI RSA – communication overhead comparison

RSA has emerged over decades as the de facto standard for encrypting and signing messages, as it is a very fast algorithm which is practical since the security requirements for encrypt/sign tend not to be too high.

In TLS 1.3, RSA is not used for encryption, but it is used for signature and authentication. Comparing the communication costs of a VIBE system to PKI using ECDHE as encryption and RSA for the authenticate/sign shows significant communication cost savings.

Table 5: VIBE vs PKI ECDHE-RSA – communication overhead comparison

11.2 VIBE TOTAL COST OF OWNERSHIP

When compared to a PKI solution, VIBE’s Total Cost of Ownership (TCO) is substantially lower.

Fig 18: VIBE vs PKI cost comparison

Numerous infrastructure components are not required by VIBE, which not only reduces one-time costs but also recurring ones, as VIBE’s scalability and simplicity significantly reduce auditing and training requirements.

Hardware devices needed for both crypto technologies (such as HSMs) scale significantly better with VIBE, yielding roughly a 400% to 500% improvement when compared to PKI.

VIBEcyber’s efforts to embed VIBE cryptography in all major HSM, HSE and IoT processors allow customers to easily integrate into their IoT devices, applications, solutions, gateways and platforms, reducing installation and configuration costs.

When compared to PKI, the reduction in communications costs, the reduced infrastructure requirements and the ongoing operational improvements that VIBE provides deliver substantial savings for end customers, as follows:

  • 60% cost savings for one-time costs,
  • 40% cost savings on recurring costs, and
  • 30% cost savings on resource costs (personnel and space)

When compared to a 5,000 user Verisign Managed PKI [19], VIBE yields cost savings of 55%. Verisign lists a TCO of $58/user/year for its Managed PKI service, whereas a VIBE-based implementation would cost approximately $22/user/year.

(To note, the Verisign Whitepaper used minimal secure facilities and infrastructure cost assumptions based on a 24/7 Network Operations Centre (NOC) costing $300,000 up front, and $300,000 per year thereafter).

The VIBE solution introduces significant one-time cost savings from omission of costly HW components required for PKI, such as Root CA, and from a substantial reduction in the number of HSMs required for VIBE vs PKI.

The largest cost savings stem from reduced operational overhead (fewer staff due to low complexity and better scalability, and less training and auditing requirements) and less infrastructure (no need for certificates and certificate management).

Overall, when compared to managed PKI, the VIBE-based implementation eliminates the need for complex implementation policies, greatly improves manageability and can be delivered for significantly reduced one-time and ongoing costs.

Chapter 12: VIBE Implementation Use Cases & Implementation Scenarios

The Internet of Things (IoT) is widely accepted as an enabler for myriad improvements to the functions and services upon which our modern world relies. Critical infrastructure supporting hospitals, cities, grids, organizations, and homeland security can all benefit from IoT deployments. And while the benefits of IoT are clear, the current approach to IoT is creating serious security concerns that are exposing our connected world to dangerous risk which is, and should be, preventing IoT adoption. This chapter illustrates how VIBE seamlessly addresses the security concerns plaguing IoT, opening the doors for widespread adoption of this disruptive technology in every market segment.

In today’s IP architecture, data exchange between nodes is secured at the transport level via Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS). TLS delivers secure communications through providing:

  • peer-entity authentication and key exchange (using asymmetric cryptography)
  • data authentication, integrity, and anti-replay (through message authentication code)
  • confidentiality (using symmetric encryption)

Peer-entity authentication and key exchange is performed by the TLS “handshake” which initiates each communication.

The consensus largest issue that exists in IPSec and transport layer communications is that they are dependent on intermediary nodes to ensure complete end-to-end security. Such security can only be assured by utilization of highly-trusted, intermediate systems.

A different approach to addressing these trust issues is to provide complete end-toend security at the application level. This method simplifies the complexities of security deployment in underlying layers, and significantly reduces communication costs in terms of packet-size and data processing, as only the applications need to be secured, and only per-data overhead is introduced. Additionally, multicast communications and in-network data aggregation in encrypted domains are more easily implemented at the application level.

This “different approach” is precisely what VIBE delivers – unforgeable, ironclad security technology that identifies communicating participants, providing a superior level of trust and authenticity.

VIBE use cases can be found in every industry segment, including some that are profiled below:

12.1 VIBE IN ENERGY AND BUILDING AUTOMATION INFRASTRUCTURES

Smart Grids (SGs) have made power systems operation more efficient by the application of distributed computing schemes in grids’ interoperation. However, these schemes have triggered various security issues which are of major concern. While physical attacks and natural disasters have long been an issue, today cyberattacks are the newest serious threat to SGs deployment, exposing the grid to potential infrastructure failure, blackouts, energy theft and breaches of customer privacy.

While SGs are often attack surfaces for cyber criminals, connected devices and sensors form another large gateway for intrusion, take-over and exploitation. Owners and operators of power systems need better ways of knowing what assets in their production environments have computing capability, and which are connected to the Internet.

Most buildings today, are “smart”, with a remote building automation system (BAS) that can integrate with the local BAS of multiple buildings within its network. Each local BAS connects to many different subsystems, including HVAC (Heating, Ventilation, AirConditioning), surveillance, access control, transportation (elevators) and energy systems.

Based on various analyses and research reports, almost 50% of publicly accessible BAS are vulnerable to cyberattacks. Intruders can leverage this channel to move laterally and…

  • gain control of other subsystems at the automation level
  • gain control at the management level to orchestrate a larger, coordinated attack
  • raise the temperature setpoint in a data center to cause business disruption
  • control the doors and gain access to forbidden areas
  • lock people in buildings/elevators, and demand ransom
  • initiate fire alarms and cause panic
  • stop water pumps and interrupt water supply
  • intrude and disrupt buildings and their occupants in many other harmful ways

Building Automation Systems today rely mainly on PKI, and often fail to establish the safety and privacy framework required for such mission-critical systems. This occurs primarily due to incorrectly managed and/or deployed PKI – largely due to its complexity - and to non-secure networked devices, routers and gateways.

To strengthen security for cyber-based business processes and transactions, new hardware architectures that embed secure element components and trusted execution environments are needed, together with easy scalability, and a seamless, easily-managed and operated cryptosystem.

VIBE is the ideal technology to provide ironclad security at the application level to securely authenticate connected devices and nodes on large and complex networks, such as those that manage business processes for the wholesale electric market, as well as building automation

Fig 20: VIBE V2V scenario

In a building automation scenario, each sensor and intelligent device in the building communicates with VIBE-secured routers and gateways. The BAS would interface/engage the VIBE Administration Console which associates every endpoint device to the appropriate Trusted Centre for creation of its Private Key. As VIBE secures at the application layer, any access-control list and role structures for maintenance or facility-management personnel can be easily associated with the devices by creation of independent Private Keys for each device user. All building gateways would have been initialized at activation when registering at the VIBE Trusted Centre with their pre-configured deployment key, which is needed to obtain its VIBE Private Key for communication. Based on the BAS application, keys can be issued as permanent, or time or session-driven renewable ones, as determined by the building’s security and implementation policies.

As most of today’s sensors do not offer enough memory nor a Trusted Execution Environment (TEE), one has to secure the sensor to a communication gateway by decoupling it from the public internet. In such a scenario, each building sensor or device is then identified by its unique identifier, and transfers its data over the internal, non-public, secure building network. Communication between building gateways and the backend is conducted over the Internet using VIBE’s unforgeable encryption schema. In Figure 19 above, a sample setup of a smart meter communication within a BAS environment is shown.

12.2 VIBE IN VEHICLE-TO-VEHICLE/EVERYTHING (V2V/V2X) ECOSYSTEMS

Vehicles are becoming increasingly connected. While connectivity has in recent years been a means to electronically update navigation and media libraries, today’s vehicular technology can supply car manufacturers with data used to support product improvements, and for constant vehicle surveillance to improve maintenance and increase vehicle longevity.
Vehicle to Manufacturer (network, V2N) integration handles sensitive user data which has to be kept private, such as geolocations, usage habits, media contents and Internet access.

In most new vehicles, sensitive functions (steering, brake control, etc.) are digitally interconnected via internal communication networks called buses which are vulnerable to intrusion and exploitation. These developments have ushered in an era where communication with vehicles has to be encrypted, and all connecting entities authenticated.

Advances in broadcasting technologies and sensor electronics have led to a further increase in vehicular communication, introducing the ability to wirelessly (dedicated short range radio) exchange information about the speed and position of surrounding vehicles. This technology shows great promise in helping to avoid crashes, ease traffic congestion, and improve the environment. The greatest benefits from V2V, however, can only be achieved, when all vehicles are enabled to securely communicate with each other.

Cross manufacturer vehicle communication is supported through VIBE’s social by design architecture in which Trusted Centres can, with permission, be interconnected to enable cross-brand communication. Further, vehicles registered in a Trusted Centre, could also be enabled to securely communicate with other Trusted Centres that might, for example, house registered and authenticated devices like traffic lights or toll systems (V2I).

The technology underlying V2V communication allows vehicles to broadcast and receive omni-directional messages (up to 10 times per second), creating a 360-degree “awareness” of other vehicles in proximity. Vehicles equipped with appropriate software (or safety applications) can use the messages from surrounding vehicles to determine potential crash threats as they develop. The technology can then employ visual, tactile, and audible alerts - or, a combination thereof - to warn drivers giving them the ability to take action to avoid crashes.

And while this technology is both exciting and filled with promise, it is imperative that this “essential” information on which these applications rely be communicated securely.

Encryption technologies which require online-verification (such as PKI) are inadequate and useless for V2V, as one can never expect cellular coverage 100% of the time. VIBE is an ideal platform to setup secure car communities, in which each car is authenticated and encrypt/decrypt is transmitted in every information exchange.

A VIBE Vehicle-to-Vehicle secured scenario would require either a vehicle owner or a manufacturer, upon sale of a vehicle, to register the vehicle in its VIBE Trusted Centre to issue and upload the vehicle’s Private Key into the vehicle’s hardware secure storage. As VIBE can be implemented to run on typical HSE elements used by automotive manufacturers, such as the Infineon SLE 97 or equivalents offered by other vendors, vehicles are able to securely communicate peer-to peer (P2P) offline, and independent of any backend connectivity.

Cross manufacturer vehicle communication is supported through VIBE’s social by design architecture in which Trusted Centres can, with permission, be interconnected to enable cross-brand communication. Further, vehicles registered in a Trusted Centre, could also be enabled to securely communicate with other Trusted Centres that might, for example, house registered and authenticated devices like traffic lights or toll systems (V2I).

12.3 VIBE FOR MEDICAL DEVICE, SENSOR AND DATA INTEGRITY CONTROL

The Internet of Things (IoT) has the potential to transform the healthcare sector. From pacemakers, to heart-lung machines, to blood-pressure cuffs, to vital health parameter surveillance devices, IoT healthcare can help health care professionals better manage diseases, remotely monitor patients, and improve treatment outcomes. And while these potential transformations are promising, they come with substantial risk when it comes to securing health-related data and devices, and protecting personal privacy from hostile outside sources.

Sensitive patient data collected and stored via connected healthcare devices is extremely valuable to hackers who can use the stolen information for blackmail or medical identity theft – or worse. For example, hackers that recently accessed patient radiology records manipulated MRT scans to show or hide cancer information, cruelly unleashing massive personal tragedy for the impacted patients

Despite these inherent risks, IoT is rapidly invading the health care sector to the point where it is now essential that aggressive steps be taken to ensure patient safety. And it’s not only healthcare data that needs to be protected from unlawful access and theft. All uses and devices that touch the health care digital ecosystem must be fully authenticated, controlled and managed, or medical institutions, health care professionals and the patients they serve will be put at greater risk.

Some positive developments have occurred. For example, the rise in hackable medical devices and numerous security breaches have led to the USA Federal Drug Administration (FDA) issuing formal guidance on how medical device makers should handle reports about cyber vulnerabilities. That’s encouraging, but it’s not enough. VIBE affords the industry the opportunity to take giant leaps forward in protecting the health care sector.

First, VIBE eliminates the need for costly complex PKI solutions, which are today widely used to protect health care information, and to deliver secure transactions. PKI operates under tight framework requirements with narrow rules and definitions which are rarely properly implemented, rendering PKI implementations highly vulnerable.

Unlike PKI, VIBEcyber’s certificate-less, authentication and encryption technology is easy to implement and maintain, is far less costly, and scales seamlessly to the levels required to easily manage any number of connected medical devices, sensors and wearables. Once implemented in the appropriate connectivity gateways or medical devices, VIBE authenticates every user/device connecting to the backend, and ensures privacy and immutability of collected and transferred medical information through encryption.

As an example, envision a medical scenario in which a pacemaker containing a VIBE private key embedded at the manufacturing side is deployed. The control and programming device would either contain a TPM/HSE-enabled VIBE implementation, or would connect to its respective medical center’s secure LAN environment to access its assigned Trusted Centre. There, it would obtain a limited-usage Private Key for programming and communicating with the implanted pacemaker. Once the programming and adjustment session is accomplished, the Private Key is automatically revoked upon session termination.

Every communication and connection to the pacemaker would initiate a pacemaker authentication, and trigger issuance of a new session Private Key for read-out or programming/adjustment of the pacemaker. As the VIBE architecture and cryptographic schema eliminates the possibility of phishing or MITM attacks, unforgeable private communication is assured.

The Health Care sector will continue to add IoT devices, and the approach that best meets the industry needs in terms of securing health data, and protecting the lives and privacy of the patients it serves, begins with VIBE. VIBE eliminates the threats posed by PKI solutions, is significantly less costly, is far less complex and ushers in an era of unlimited scalability.

Chapter 13: VIBE Security

13.1 SECURITY LIFECYCLE MANAGEMENT

Fig 21: VIBE Security Lifecycle Management process

To ensure seamless IoT security deployment, VIBEcyber maintains, manages and controls embedding of its VIBE technology through a detailed Security Lifecycle Management (VIBE-SLM) approach which governs the complete IoT enrollment, set-up, operations and ongoing management processes, including key reissuance and revocation.

VIBE’s technology not only enables offline operation of trusted community groups, it also allows for criteriabased (time, rule, or application-controlled) Private Key issuance and usage.

As an embedded technology building trust and privacy via its SDK and API’s at the application layer, VIBE is network protocol and layer agnostic, and supports flexible setups, once embedded and made available in the hardware platforms. As an end-toend technology, VIBE can be implemented in diverse Trusted Execution Environments (TEE’s) such as HSMs and HSEs, and in secure processors in a wide variety of devices such as routers, gateways, and eSIMs, and in application processors such as the Infineon Aurix and ARM platforms.

The VIBE-SLM process ensures, scalability, sustainable growth, and optimized TCO, and sets the framework for privacy and authentication of IoT infrastructures and devices.

13.2 SECURITY GRADE AND ASSURANCE LEVEL

VIBE is based on IBE, long proven to be highly secure. And while VIBE has greatly enhanced the operational and functional efficiency of IBE, rendering it ideal to secure the IoT, the fundamental strong security that underlies IBE remains intact with VIBE.

The technology wrapped in VIBE is called a pairing, and its security has been witnessed and constantly validated by cryptographers from the finest academic research centers, and approved by the academic research community. VIBE uses elliptic curves with security configurable from 128 to 256 AES security for data encapsulation.

In essence, VIBE is proven to be as secure as the technology inside it, meaning that breaking any piece of VIBE is as hard as breaking the pairing computation. In layman’s terms, VIBE can be seen as a chain, where a chain link is the pairing and where every link is as hard as the pairing itself. This kind of architectural security is not new - RSA was built this way. However, RSA is based on prime number factorization, a hard problem which is known to be considerably weaker than the ability to mathematically and computationally break pairing.

13.3 CERTIFICATION REQUIREMENTS FOR SECURE ELEMENTS AND DEVICES

When it comes to industrial or critical infrastructure implementation, security technologies have to be sufficiently tested, and have passed extensive vulnerability and intrusion examinations. To prove this to potential customers, security vendors normally indicate that their products have passed specific certification levels which provide assurance that their products or solutions can be trusted, and have gained acceptance by an independent third-party. Two of the most commonly known certification procedures are Common Criteria (CC) and FIPS 140-2.

Common Criteria (CC) is an international set of guidelines and specifications developed for evaluating information security products, specifically to ensure they meet an agreed-upon security standard for government deployments. Common Criteria is more formally called "Common Criteria for Information Technology Security Evaluation."

Common Criteria has two key components: Protection Profiles and Evaluation Assurance Levels. A Protection Profile (PPro) defines a standard set of security requirements for a specific type of product, such as a firewall. The Evaluation Assurance Level (EAL) defines how thoroughly the product is tested. Evaluation Assurance Levels are scaled from 1-7, with one being the lowest-level evaluation and seven being the highest-level of evaluation. A higher-level evaluation does not mean the product has a higher level of security, only that the product went through more tests.

FIPS, the Federal Information Processing Standard, 140-2 is the benchmark for validating the effectiveness of cryptographic hardware. If a product has a FIPS 140-2 certificate it indicates that it has been tested and formally validated by the U.S. and Canadian Governments. Although FIPS 140-2 is a U.S./Canadian Federal standard, FIPS 140-2 compliance has been widely adopted around the world in both governmental and non-governmental sectors as a practical security benchmark, and realistic best practice.

Organizations use the FIPS 140-2 standard to ensure that the hardware they select meets specific security requirements. The FIPS certification standard defines four increasing, qualitative levels of security:

Level 1:
Requires production-grade equipment and externally tested algorithms.

Level 2:
Adds requirements for physical tamper-evidence and role-based authentication. Software implementations must run on an Operating System approved to Common Criteria at EAL2.

Level 3:
Adds requirements for physical tamper-resistance and identity-based authentication. There must also be physical or logical separation between the interfaces by which “critical security parameters” enter and leave the module. Private keys can only enter or leave in encrypted form.

Level 4:
This level makes the physical security requirements more stringent, requiring the ability to be tamper-active, erasing the contents of the device if it detects various forms of environmental attack.

The FIPS 140-2 standard technically allows for software-only implementations at level 3 or 4, but applies such stringent requirements that none have been validated.

To submit a product for evaluation, the vendor must first complete a Security Target (ST) description, which includes an overview of the product and product's security features, an evaluation of potential security threats, and the vendor's self-assessment detailing how the product conforms to the relevant Protection Profile at the Evaluation Assurance Level the vendor chooses to test against. An independent accredited laboratory then tests the product to verify the product's security features, and evaluates how well it meets the specifications defined in the Protection Profile. The results of a successful evaluation form the basis for an official certification of the product.

As VIBE is a cryptographic technology that integrates at the application layer, and is by standard implemented (embedded) on certified platforms, the certification process per se, can only occur in combination with the specific use case or hardware platform implementation on which VIBE is embedded or running. However, VIBEcyber has taken the necessary actions to prove its underlying crypto mathematics are correctly implemented and numerically and conceptually correct and secure. VIBEcyber’s patent claims have been verified by a vendor-neutral third party.

This process is a fundamental step for any subsequent implementation certification by a state-body such as the BSI in Germany or NIST in the US. The mathematical proof of correctness has been covered by a renowned professor in cryptography specialized in IBE at the Université de Limoges, France, one of the lighthouses in cryptography worldwide.

Further implementation certifications are pending and subject to ongoing solution implementations with partners. Practically, this means that VIBE will be certified on each platform on which it is implemented as most, if not all these devices have achieved CC and/or FIPS 140-2 certification, the certification process is significantly shorter than starting from scratch.

Chapter 14: Conclusion

The current approach to securing IoT is based on PKI-based cryptographic systems developed in another era for a different purpose. These systems are costly, complex and have myriad vulnerabilities that are easily exploited by cyber criminals. While society in general seems to have become numb to security breaches, given the almost daily occurrences of hacks at some level, accepting breaches as an inherent part of our connected world is not acceptable – not when the stakes are as high as they are today.

Cyberattacks on critical infrastructure by rogue actors or nations threaten our very existence. It is entirely conceivable that any nation in good standing with the United Nations could see its electrical grid, its water supplies, its military or even nuclear systems penetrated, and shut down.

VIBEcyber’s patented cryptographic schema is modern technology which takes advantage of recent academic research that renders it ideally suited to protect the Internet of Things. A VIBE system is less complex, less costly and substantially more secure than current PKI systems. VIBE offers advantages to every IoT ecosystem, including protecting consumer applications, however its greatest value lies in its ability to render Industrial IoT embedded infrastructure truly secure.

Organizations that are involved in providing Industrial IoT services, platforms, products or components are encouraged to explore the potential inherent in Verifiable Identity Based Encryption, particularly if their offerings are part of mission-critical infrastructure.

APPENDIX A: Abbreviations

API : Application Programming Interface - a set of methods, structures or classes exposed to a developer to build an application for a given technology.

CA: Certificate Authority - an entity that issues digital certificates and maintains a revocation list. A digital certificate certifies the ownership of a public key by the named subject of the certificate.

HSE: Hardware Secure Element - a microchip that provides a hardware protection of the flash memory, hardware or software level of countermeasures against tempering and side-channel attacks.

HSM: Hardware Security Module - a computing device used to protect secrets and code execution with the highest achievable level. A HSM provides a high level of performance and can perform thousands to millions of cryptographic operations when using a public key accelerator.

IBE: Identity Based Encryption – an encryption scheme developed by Shamir that uses an identity string and public parameters to do the encryption. The private key for a given identity is generated by a key generator.

IoT: Internet of Things - is the extension of Internet connectivity into physical devices and everyday objects. Embedded with electronics, Internet connectivity, and other forms of hardware (such as sensors), these devices can communicate and interact with others over the Internet, and they can be remotely monitored and controlled

IIoT: Industrial IoT - refers to interconnected sensors, instruments, and other devices networked with industrial application computers, including, but not limited to, manufacturing and energy management. This connectivity allows for data collection, exchange, and analysis, potentially facilitating improvements in productivity and efficiency, as well as other economic benefits.

M2M: Machine-to-Machine - refers to direct communication between devices using any communications channel, including wired and wireless.

PKA: Public Key Accelerator - a hardware implementation of mathematic operations required when implementing RSA or ECC-based algorithms.

PKI: Public Key Infrastructure - a public key encryption system that uses certificates and a certificate authority to verify the validity of participants of a system.

RSA: RSA - is one of the first asymmetric public-key cryptosystems and is widely used for secure data transmission. The acronym is derived from the initial letters of the surnames of Ron Rivest, Adi Shamir, and Leonard Adelman, who first publicly described the algorithm in 1977.

SDK: Software Development Kit - a set of libraries and documentation to facilitate the development of a complete application with a software technology.

SLM: Security Lifecycle Management - process managing the conception, deployment, operation, revocation, reissuance, surveillance and control of a security implementation.

TC: Trusted Centre, - the “root of trust” in a VIBE system which manages the identities and the private keys of the participants. However, it is not comparable to a root Certificate Authority (CA) in PKI systems.

TCO: Total Cost of Ownership - a financial approach intended to help buyers and owners determine the direct and indirect costs of a solution or system.

TEE: Trusted Execution Environment - is a secure area inside a main processor. It runs in parallel to the operating system, in an isolated environment. It guarantees that the code and data loaded in the TEE are protected with respect to confidentiality and integrity.

VIBE: Verifiable Identity Based Encryption - an IBE cryptosystem improved to avoid tampering of the public parameters, and that also includes the signature of sent data.

V2X: Vehicle-to-Everything - communication is the passing of information from a vehicle to any entity that may affect the vehicle, and vice versa. It is a vehicular communication system that incorporates other more specific types of communication including V2I (Vehicle-to-Infrastructure), V2N (Vehicle-to-Network), V2V (Vehicle-toVehicle), V2P (Vehicle-to-Pedestrian), V2D (Vehicle-to-Device) and V2G (Vehicle-toGrid). The main motivations for V2X are road safety, traffic efficiency, and energy savings. There are two types of V2X communication technology depending on the underlying technology being used: WLAN-based, and Cellular-based.

APPENDIX B: References

[1] Statista.com: Statista Research Department, Feb 2016
[2] Accenture: Winning with Industrial Internet of Things, 2015
[3] Markets and Markets: IoT Security Market, 2018
[4] IDC, Forecast Worldwide Spending on the Internet of Things; Jan 3, 2019
[5] Network World: Most Powerful Internet of Things Companies, Feb 2018
[6] Kaspersky: Jeeps Hacked Again, Aug 2016
[7] The Independent: Russian Hackers Attack US Power Grid, July 2018
[8] New York Times: The Water System: a Perfect Target for Cybercriminals, Nov 2018
[9] TechCrunch: Russia Hacking Into Nuclear and Other Critical Infrastructure, Jun 2018
[10] International Airport Review: Hackers Access Airport Systems for $10, July 2018
[11] Bain and Company: Cybersecurity the Key to Unlocking IoT Demand, 2018
[12] Security Week: Examining Threats Against PKI and SSL, Feb 2012
[13] ThreatPost: Assessing Weaknesses in Public Key Infrastructure, Feb 2014
[14] Akamai: Billions of Malicious Bots Take to Cyber-stunting to Hide, May 2019
[15] CSO Online: Fatal Problems with PKI, June 2015
[16] Swift: TCO of Managed PKI solution, Feb 2012
[17] Ponemon Institute: Study Reveals 80% of IoT Apps are Not Secured, Jan 2017
[18] Altman, Valandrie & Co; Half of US Companies Hit by IoT Security Breach, Jun 2017
[19] Verisign Inc. Whitepaper, Total Cost of Ownership for PKI; Mar, 2005

APPENDIX C: Table of Figures

Figure 1: Projected IoT device increase
Figure 2: IoT market growth 2017 - 2022
Figure 3: IoT adoption barriers
Figure 4: Principle of symmetric encryption
Figure 5: Principle of asymmetric encryption
Figure 6: PKI communication concept
Figure 7: Handling Revocations in PKI
Figure 8: Components utilized in a typical VIBE Cryptosystem
Figure 9: End-to-end VIBE architecture
Figure 10: VIBE Hardware Security Module architecture
Figure 11: VIBE Hardware Secure Element architecture
Figure 12: VIBE Message and Communication process
Figure 13: VIBE Trusted Centre WEB API
Figure 14: VIBE API to enable security for an embedded application with a companion HSE
Figure 15: VIBE API to enable security for a non HSE configuration
Figure 16: VIBE private key deployment
Figure 17: VIBE device enrollment and deployment process
Figure 18: VIBE vs PKI cost comparison
Figure 19: VIBE Smart Meter security architecture
Figure 20: VIBE in V2V environments
Figure 21: VIBE Security Lifecycle Management

APPENDIX D: Table of Tables

Table 1: IoT trends in numbers
Table 2: Leading IoT market players
Table 3: PKI is despite better solutions still the technology of choice
Table 4: VIBE vs PKI RSA – communication overhead comparison
Table 5: VIBE vs PKI ECDHE-RSA – communication overhead comparison

VIBE Whitepaper – Version 1-6-TCO-2019 | © Copyright VIBE Cybersecurity International LLC