6 Future Proof Security [Shields]

Student Learning Objectives

Using IEC 62443 and other evolving standards, as inspiration for requirements, Chapter 6 is dedicated to the importance of both security and authentication in providing secure integrity management for systems now and the foreseeable future.

The student will be introduced to Autonomous Key Management (AKM) and its importance in replacing Blockchain – because it is more secure and offers advanced features against quantum computing.

Security Landscape

New and evolving threats to security include not only attacks on the security of the protected assets (both “in-motion” and “at rest”), but also to the validity of the protected assets.  Requirements focused on both simultaneously securing the data as well as authenticating the source of the data are rapidly increasing in significance.

Standards like IEC 62443 (ISA, 2021), have evolved over the past five years to address this exact problem.  IEC 62443 specifies a framework to address and mitigate current and future security vulnerabilities in industrial automation and control systems (IACSs).  It also provides a firm foundation for other industries that are neither mission critical nor safety critical, but whose applications are just as important to their stakeholders and for whom value security and authentication as much as the stakeholders in mission critical and safety critical applications.

Security and Protecting Critical Assets

Malware on the rise and intruders increasing the scope, sophistication, and frequency of their attacks, the realization has been made that encryption alone cannot protect a system.  The consensus is that a more wholistic approach must be taken and this is where IEC 62443 and other similar methodologies come to bear. (Michelle Michael, TÜV Informationstechnik GmbH, TÜV NORD GROUP, 2021)[1]

In parallel, those whose responsibility it is to provide network and asset security have accepted the notion that breaches are inevitable and thus, constant analysis of the system and its assets must be done perpetually for the life of the system.  What this means, is that it is not enough to simply focus on protecting files and/or data.  The focus initially shifted to intrusion detection, but then quickly expanded beyond that to include monitoring the entire system and integrity management.

Each data set, each hardware element, and each electronic component, must be identified, verified, and validated:

Asset Authentication = Asset Identity Validation + Asset Identity Verification         (Eq 6.1)

Identity Validation refers to the concept that the identity is valid.  That it is real.  For instance, the verification of a social security number will determine if the number is a legitimate social security number, but not necessarily if it belongs to a specific individual.

Identity Verification refers to the concept that the validated identity is verified as being associated with the context it is being tested for.  Again, using the concept of a social security number, not only is the social security number valid (i.e., associated with a real, living person), but it is indeed associated with the specific person who is claiming it as their own.

Put the two together and the result asset authentication.

By authenticating each asset, the integrity of the overall system is maintained.  Additionally, authenticated physical assets, can then, themselves, become trust anchors and a means for extending the overall integrity and security of the entire system.

One-time authentication is not sufficient for protecting the overall system integrity.  It is a process that must be repeated from power-on to power-down/reset and for the lifetime of each individual device and the system as a whole.

The driving factor for this is that the issues and concerns of what was once the dilemma of the Information Technology (IT) domain has now crept into the Operational Technology (OT)[2] domain as well. It is especially true for the critical infrastructure subset portion of OT represented by Industrial Automation Control Systems.  This is because in an effort to interconnect OT and IT systems, OT systems now have many of the same components as IT.  Thus, they automatically inherit and/or are susceptible to the same problems.

The problem with that is while there are plenty of security solutions for IT, OT presents a more difficult landscape to protect because of its diversity of systems, including systems that are comprised of many (if not all) proprietary solutions.

The below Table 6.1, obtained from a whitepaper created by TUViT (Michelle Michael, TÜV Informationstechnik GmbH, TÜV NORD GROUP, 2021), illustrates the disparity differences between traditional IT Security and IACS Security (and is also largely true for many OT systems because of proprietary and non-standard OT implementations):

Table 6.1: Differences between Traditional IT Security and IACS Security

Source: (Michelle Michael, TÜV Informationstechnik GmbH, TÜV NORD GROUP, 2021)

The takeaway from Table 6.1 is that while IT systems are challenged to keep up with the rapidly changing and increasing complex and sophisticated security attacks, OT faces almost insurmountable obstacles to overcome just to get near the same level of protection as IT.  The challenge for OT Industrial Automation Control Systems they are almost always managing critical infrastructure that must operate in an environment of continued availability and stability.  Not only is there an additional constraint that these systems can ill-afford to go offline because of the safety concerns of the resources they are managing, but these systems must be continually operational.

The foundation of why new and more comprehensive approaches for providing security and integrity services to OT, particular those managing critical infrastructure, have evolved.  But one need not think that these approaches are limited to and benefit only OT critical infrastructure systems.  These approaches also can provide great benefit to IT based systems, particular those which directly or indirectly impact the very fabric of our society.

Protecting Industrial Control Systems via Comprehensive & Secure Integrity Management & Monitoring

Having now established that security solutions for systems require more than simply encryption of data.  That the basic integrity of those systems must also be maintained.  The question then becomes, how to do this?

First, it will be easier and more straightforward to consider systems whose operating environment can be limited.  That is systems that operate mostly as closed systems, with little to no interaction to external networks.  Second, and with the aforementioned in mind, focusing on Industrial Control Systems (ICS) will have the greatest impact.  As these systems can least afford to have a breach and the resultant behavior as consequence of a breach, can be catastrophic to both human life and property.  Protecting these systems provides the ultimate ROI, by saving both money and human life.

Given this focus, the logical progression for thoroughly examining the challenges Industrial Control Systems face:

1) Describe characteristics of what sets Industrial Control Systems apart from typical IT systems.

2) Outline what an ideal solution would be

3) Given the ideal solution provided in (2) above, describe how current solutions fit within this framework, and

4) Provide alternative, perhaps yet to be defined solutions that can address the goals of the framework described in 2) above.

Secure Communication & Integrity Management & Monitoring Challenges for Industrial Control Systems

Systems which are typically considered as Industrial Control Systems, usually manage mission and/or safety critical types of systems, including critical infrastructure systems (that manage essential services).  Typical examples of such systems are:

•  Electricity: Power Generation and Power Distribution.
•  Petroleum/Natural Gas: Exploration, Extraction, Pipeline, Production.
•  Wastewater: Treatment/Purification.
•  Transportation:
  •  Aviation: Traffic Control, Aviation Vehicles.
  •  Rail: Traffic Control (BackOffice, Wayside, and Onboard), Other non-traffic, onboard systems.
  •  Maritime: Traffic Control, Onboard Shipping Control systems.
  •  Automotive: Traffic Control, Individual Vehicle Control systems.
•  Manufacturing
•  Mining

These systems come under a variety of names:

•  Industrial Control Systems (ICS).
•  Operational Technology (OT).
•  Supervisory Control and Data Acquisition (SCADA).
•  Programmable Logic Controllers (PLC).
•  Proportional-Integral-Derivative (PID).

And, usually have most, if not all of the following characteristics:

• Communication within the system is local to the closed system. Typical examples of this would be virtually all vehicles and other types of mission and/or safety critical systems.
• Hardware components are static and do not change. Thus, all possible combinations of communication paths are known up front.
• Communication may be physically and/or logically separated into mission/safety critical communication and non-mission/non-safety critical communication.
• Updating of traditional security credentials is often physically prohibitive, difficult to do, and/or financially impractical or costly. Some practical examples of this are:

• Updating the security credentials in automotive vehicles would be inordinately costly and practically impossible in all cases given that some vehicles may never visit an authorized service center to connect to the OEM backend server.
• Remote updating of security credentials of high-security military installations is usually prohibited and done locally. Making the overall security credential update process inordinately costly.
• Remote updating of security credentials of space systems is problematic both for reasons of security and practicality (including huge delays because of time and distance from Earth).
• Updating of security credentials within nuclear facilities must be done locally. Making the overall security credential update process inordinately costly.

• Availability for many of these systems must be at or close to 100%. Meaning, the systems they control must remain online 24-hours a day, 365-days a year, without interruption.  Systems that fall under this category usually have double or triple redundancy systems, but if there is a security breach, depending upon the redundancy is achieved, it may easily affect all of the redundant systems as well.

These systems, particularly those protecting critical infrastructure, are considered to be excellent targets by potential attackers.  A successful attack on such a system can incur a huge loss to both a country and its economy.

Even though these systems usually have limited (or restricted) external network connectivity, because of their operational requirements and the aforementioned potentially catastrophic consequences in the event of failure or breach, their security requirements are far more demanding than most IT based systems.  Careful thought must be given as to what the ideal solution would be to solve the security and integrity challenge for Industrial Control Systems.

The next section focuses on collating suggested requirements for providing security and integrity management to Industrial Control Systems, keeping in mind, the demanding nature of their operational environment.

Ideal Secure Communication & Integrity Management & Monitoring Requirements for Industrial Control Systems

Before delving into the suggested requirements, the concept of a security relationship must be defined.  Which is, a security relationship is a set of two or more endpoints that form a communication network sharing a common set of security credentials.  Another way of viewing the concept of security relationship would be that of a “security mesh”, given that the set of endpoints is not restricted to point-to-point communication, but rather multipoint to multipoint communication.

Logically, it is easier to break this task into two sections.

First, is to examine what the ideal security solution should look like.  Then, using the security framework specified for the ideal security solution, the ideal Integrity Management framework can then be examined as well.

Ideal Secure Communication Requirements for Industrial Control Systems

Features and associated reasoning for each suggested requirement are provided below:

• Security Credentials should be unique per security relationship, with no interdependencies on security credentials of other security relationships. Different security relationships should have nothing in common with other security relationships.
• Shared secrets that could lead to a breach of one or more security relationships, shall not be communicated between hardware modules and preferably, are never exposed outside of a hardware module’s secure storage. Implies, security credentials are pre-provisioned, with no key exchange.
• Security credentials should never be static and should be updated/refreshed on a regular basis.
• Security credentials should not be predictable.
• Security credentials should have Perfect Forward Secrecy (even if someone discovers the current security credentials, it should not give them any insight as to what prior security credentials were).
• A single set of security credentials should be capable of securing a communication mesh of two or more nodes. That is, it shall be possible to have security relationships of more than two nodes (i.e., a multipoint, security mesh and not simply a P2P security connection). This is a property of scalability.
• Hardware Modules may have multiple, overlaying communication security relationships. Ideally, these security relationships shall be application specific and enable different virtual communication security relationships within the same hardware module. Hardware Modules may have multiple, overlaying communication security relationships.  Ideally, these security relationships shall be application specific and enable different virtual communication security relationships within the same hardware module.  This is also a scalability property.
• Capable of authenticating the transmitting hardware module.
• Has little to zero latency (zero ideally) (There is no session establishment phase, implying that it automatically comes up in “bulk encryption” mode).
• Capable of providing same level of security to small hardware modules (ex. sensors) with minimal processing and storage capabilities, ideally, security related algorithms are of linear complexity and utilize less than 15-KB in executable and runtime storage requirements.
• Initial Provisioning of new security credentials shall be autonomous.
• Refreshing of security credentials shall be both frequent and autonomous
• Prevention of Replay Attacks should be a built-in feature.
• Must be quantum resilient. With the advent of quantum computing on the horizon and serious discussions about the negative implications for existing security, particularly the asymmetric algorithms used for sharing the bulk encryption key in Public Key Infrastructure (PKI).  It is imperative that any proposed ideal solution be absolutely quantum resilient.

The basis for each requirement is:

Unique Security Credentials per Relationship

Ensuring uniqueness amongst different sets of security relationships eliminates the possibility that a breach of the security credentials can provide insight into the credentials of other security relationships (as would be the case with a PKI asymmetric encryption breach of one Public Key/Private Key pair could lead to the breach of other Public Key/Private Key pairs).

No Communication of Shared Secrets

Eliminating communication of shared secrets prevents the attacker from directly discovering security credentials exchanged over the communication network.  Elimination of shared secrets has the side-benefit of mitigating Man-In-The-Middle attacks, as it severely minimizes useful information an unwanted observer could use to launch such an attack.

Continually Refreshed Security Credentials

Security credentials should be updated frequently.  Ideally, they should be updated every session, so that the security credentials are constantly moving target.

Security Credentials Cannot be Derived/Predicted

What this means is that even if an attacker gains access to a prior set of credentials, they should not be able to predict what future sets of credentials are.  Credentials should have a legitimate amount of randomness within the security credential creation process to ensure future iterations cannot be mathematically derived or predicted.

Security Credentials should have Perfect Forward Secrecy

This is a follow-on to the previous requirement, but in the opposite direction.  What this requirement means is that in the event of a breach and if the current security credentials are compromised, there is no way to backwards engineer what prior sets of security credentials were.  In other words, if an unwanted observer had recorded prior sessions, a breach to the current set of security credentials would not enable them to decrypt prior sessions that had been previously recorded.

Security Credentials shall be Capable of Protecting Multipoint Networks (i.e., creating a Security Mesh)

It shall be possible to have security relationships of more than two nodes (i.e., a multipoint, security mesh and not simply a P2P security connection).  Thus, increasing the scalability of a solution.

Hardware Endpoints may Have Multiple, Overlaying Security Relationships

This is another scalability property by allowing security relationships to be application specific with different virtual communication security relationships across one or more of the same physical hardware components.  Thus, enabling hardware endpoints to have multiple, overlaying communication security relationships.

Authenticates Hardware Endpoint

Automatic authentication of the hardware endpoint both ensures against hardware spoofing as well as establishing the hardware endpoint as a local trust anchor.

Significantly Mitigates Latency

Ideally, latency is reduced down to zero, as an efficient solution will not have a session establishment phase.

Provides Consistent High-Level Grade Security Regardless of Processing Capability

The solution should be capable of providing the same high-level of security to small hardware modules (ex. sensors) with minimal processing and storage capabilities as it does with more capable hardware architectures.  Ideally, security related algorithms are of linear complexity and utilize are capable of being compressed down to 15-KB or less in executable and runtime storage requirements.

Initial Provisioning of New Security Credentials is Autonomous

This feature significantly mitigates need for administrative personnel by enabling automatic new security relationships to be established without need for administrative oversight.  The most obvious way to implement this into a security relationship would provide for an in-network management device the ability to automatically configure new security relationships in accordance with the direction of a downloaded (or modified) configuration file or database.

Autonomous and Frequent Refreshed/Updated New Security Credentials

This feature significantly mitigates need for administrative personnel by enabling the frequent, automatic update of new security credentials for perpetuity, presumably in accordance with some preconfigured policy.

Elimination of Replay Attacks

This is an easy enough feature to implement by including an unmodifiable replay counter within every frame.

Must be Quantum Resilient

Effectively, this means that no brute force attack with infinite resources is capable of breaching the security.

Ideal Integrity Management Requirements for Industrial Control Systems

As will be obvious after reviewing the requirements, many of the requirements for the ideal Integrity Management & Monitoring (IM&M) solution are identical or closely related to the requirements for the ideal Secure Communication solution.  Thus, the ideal IM&M solution should be based on the ideal Secure Communication solution and listed below.

The IM&M Validates Hardware Endpoint

Automatic authentication of the hardware endpoint both ensures against hardware spoofing as well as establishing the hardware endpoint as a local trust anchor.  This is identical to the Ideal Secure Communication requirement.

The IM&M Validates Every Software Component

Every electronic image that is part of the core application and required supporting infrastructure should be validated.  This usually consists of a minimum of:

1) The Bootloader.

2) The Runtime Operating System Environment.

3) The Core Application (that implements the actual functionality for which the hardware module was designed).

4) Related Data Files.

Validates Every Subsystem

Every subsystem should be validated, where a subsystem is defined to be a collection of logically grouped, hardware modules.

Validates Every System

Every system should be validated, where a system is defined to be a collection of all subsystems and/or hardware modules within a physically distinct system

The Integrity Management & Monitoring System Shall Enforce the System Configuration

Every hardware module, subsystem, system and shall be defined as designated by a resultant configuration management file capturing the configuration of each individual hardware module, subsystem, and overall system.

Enforcement of the System Configuration shall occur for the Life of the System

The configuration specified for the overall system, its individual subsystems, and hardware modules shall be enforced throughout the life of the system from cradle to grave to comply with the specified configuration (which can and usually will change over time).

Enforcement of the System Configuration shall occur Continuously in Periodic Intervals During Runtime

Every aspect of the configuration, including the overall system itself, the subsystems within the system, and the hardware endpoints within the subsystems, shall be re-validated on a continual, periodic basis throughout the life of the system, including and especially during runtime.

The System Configuration Shall be Simple and Crosschecked with Other Components and Subsystems within an Individual System

The validation process shall be simple, immutable, and crosschecked with other components and subsystems within the system.  Thus, ensuring that one module within a subsystem cannot be changed without simultaneously altering all other modules within the same subsystem.

Normal Operation of the Ideal IM&M, including Enforcement of the System Configuration, Shall be Autonomous

The system should be simple and explicitly designed to automatically enforce the system configuration, so as to mitigate the possibility of nefarious alteration of the associated image integrity code and/or image.  To ensure absolute compliance, images and their integrity codes can be configured to be cross-checked again immediately prior to them being loaded.  Of course, this is the age-old tradeoff of security verses efficiency, and will be determined by the individual customer.

At a minimum, an image to be loaded should have its integrity code recalculated just prior to it be being loaded, to ensure it matches the integrity code value held within the local hardware store of the secure element.

Hardware Endpoints May be Members of Multiple Subsystems Simultaneously

This enables overlaying of security relationships in accordance with customer defined groupings and is an extension to the Secure Communication requirement stating that Hardware Endpoints may have multiple, overlaying, security relationships.

All Communication Between Logical Elements within the System Shall be Secure

All communication between logical elements shall use a secure communication solution that meets the requirements of an ideal secure communication solution outlined previously.

How do Current Solutions fit within the Outlined Ideal Framework for Secure Communication and Integrity Management & Monitoring?

It should come as no surprise that existing solutions (ex. PKI + TLS and/or Blockchain) do not fit within the ideal outlined framework.  The reason for this is simple.  The ideal solution was derived with the goal in mind of solving issues currently plaguing existing solutions.  This set of ideal requirements was created with the specific goal of correcting problems that have been discovered over time in how security and integrity management & monitoring works today.  Thus, the only way to truly address these problems is with a new solution that is specifically and explicitly designed to solve these problems.

Current Solutions vs. the Ideal Secure Communication Solution

It is nonetheless instructive to compare the ideal requirements with the nominal solutions in use today, namely, the Public Key Infrastructure (PKI) Key Management System (KMS) and the Transport Layer Security (TLS) communication security protocol.

How Do PKI + TLS Address the Ideal Requirements for Secure Communication?

Unique Security Credentials per Relationship

PKI (plus TLS) Violation!

PKI is explicitly designed to enable one to many relationships, for as long as the security credential is in operation.  Effectively, PKI is designed to explicitly violate this principal.  Further, for many closed systems (like automotive passenger vehicles), their PKI certificate may never be updated.  Thus, leaving a single certificate for the life of the vehicle.

No Communication of Shared Secrets

PKI (plus TLS) Violation!

The asymmetric key exchange phase of PKI is used to share the symmetric key used for bulk encryption with the other side of the PKI/TLS connection.

Continually Refreshed Security Credentials

PKI (plus TLS) Violation!

In many ICS/OT/SCADA/Etc. applications, security credentials are changed at best, every 9-12 months.  In the case of automotive and automotive related passenger vehicles, these credentials may never be changed and could be static for the life of the vehicle.

In the automotive vertical, the logic used to defend this decision is simple:

1) It would be both prohibitively costly and physically impractical to update the security credentials in automotive vehicles.

2) Because automotive vehicles are closed systems, the likelihood and impact of a breach is relatively small.

Where that logic falls apart is simple.  The goal of an attacker is not necessarily a total and complete takeover of every system.  The goal of the attacker is varied and victory for some attackers could be achieved if they were able to significantly disrupt a specific industry, infrastructure, or company.  A complete devastation of the economy would be at the top of the list of their wildest fantasies.

Just like prior to September 11th, 2001, it was inconceivable that someone would hijack a plane for the sole purpose of crashing it into a building.  Similarly, if a state sponsored attacker wanted to significantly disrupt the economy, they would not need to hack all automotive vehicles, most vehicles, or even a large plurality of vehicles.  A very minute subset, strategically placed, would do just fine.

We already know that many of these attackers have engineering backgrounds and could easily work within any number of vehicle manufacturers.  All it takes is time, motivation, and planning and anything is possible. (Department of Sociology, University of Oxford, Manor Road Oxford OX1 3UQ, 2008) [3]

Transportation Terrorist Scenario [4]

Let’s take the following example. (CENSEC, DK, 2019)

Suppose a state sponsored terrorist organization was able to gain insight into the security credentials used for twenty vehicles each of five of the major automotive companies.  Meaning, a total of 100 vehicles.  Suppose also they were patient in planning this, with their plans measured in years, not months or days.

If you had personnel who worked at these automotive manufacturers, discovering the security credentials programmed into a small subset of vehicles is very much within the scope of reality.

Now, suppose they planned the attack as such:

1) On the first day of the attack, they took over control of ten (10) vehicles of OEM brand 1 during peak traffic hours, causing all the ten vehicles to crash.

2) One week later, the attackers launch the second attack. This time doing the same thing to ten (10) vehicles of OEM brand 2.

3) Then, just to mix things up a little, the attackers waited for two weeks and one day, and launched a similar attack on ten vehicles of OEM brand 3.

4) Then, some arbitrary number of days later, they launched the same attack on ten vehicles of OEM brand 4.

5) They wait another arbitrary period of time and launch another attack on ten vehicles of OEM brand 5.

6) They, then wait another arbitrary period of time and launch a second attack on five vehicles of OEM brand 1.

7) They again wait some arbitrary period of time and launch a second attack on five vehicles of OEM brand 2.

Keeping in mind that at this point, they still have forty (40) vehicles at their disposal, how far into this series of attacks do you think it would take before significant numbers of people simply stopped driving their cars? The answer is, of course rhetorical, one should look no further than the current COVID-19 crisis to know this would devastate our infrastructure, our trust in government, our economy, and our entire way of life as we know it.

Now, to add a bit of excitement into this thought experiment, suppose that they anticipated that people would at some point switch to mass transit, so they also infiltrated companies that manufactured busses used for public transportation.  Thus, after there was significant paranoia and anxiety created by the automotive vehicle attacks, they started doing the same thing to public transportation.

Suppose they anticipated that if people stopped using both private and public transportation, they would switch to a work-from-home based economy as a stopgap measure.  Thus, delivery trucks would become even more important than they are today.  Suppose this really patient group of attackers, had also infiltrated companies that made delivery trucks for companies like DHL, FedEx, and UPS, and launched similar attacks on these delivery trucks.

Now, for the final coup de grâce, they also infiltrated manufacturers of semi-trucks, doing the same sort of attacks with them, and thus affecting how the vast majority of goods are transported significant distances.

Think about this!

People would stop driving!

People would stop taking public transportation (at least they would stop using busses)!

People working for delivery company would demand something be done before they drive their vehicles again!

Truckers would stop driving and like the delivery truck drivers, would demand something be done before they drive their vehicles again.

Without question, the entire economy of the Western World would come to a grinding halt.

All of this damage could be done to the entire combined economies of U.S., Canada, U.K., and Europe, just by having the ability to hack into less than 200-different vehicles.

All of this could have been avoided if the security credentials were constantly changing, not predictable, and maintained within a tamper resistant KeyStore.

This is well within the realm of reality and it is not a matter of “if”, but “when” someone decides to do this.

Until then, the automotive and related industries will continue to ignore these warnings, citing the extreme unlikelihood of this happening, just like flying planes into buildings seemed equally unlikely prior to 9/11/2001.

The automotive vertical is an extreme case, most other verticals within the ICS/OT/SCADA/Etc. landscape do not maintain static certificates.  Most other verticals do update their certificates on a regular basis, but as stated in the beginning of this section, this is a period of time that is measured in months and not weeks or days (with the recommended period being every 9-12 months).  Thus, leaving as a static target the certificate until it is updated and, in a world, where quantum computing has been presupposed to be a legitimate threat to traditional cryptographic methodologies like PKI and TLS, this does present a significant problem once quantum computing is available.

Even without the availability of quantum computing, traditional cryptographic methods are vulnerable if the attacker is able to garner even a minimum amount of information about the certificate.  From there, it would just be a matter of time before the security credentials were fully or even partially hacked.  The longer the time between updates, the greater the exposure of the security credentials.

Security Credentials Cannot be Derived/Predicted

PKI (plus TLS) Violation!

If the static certificate is breached in any way, even partially, the derived security credentials are predictable.

Security Credentials should have Perfect Forward Secrecy

PKI (plus TLS) Violation!

PKI’s version of Forward secrecy typically uses an ephemeral Diffie-Hellman key exchange to prevent reading past traffic. The ephemeral Diffie-Hellman key exchange is often signed by the server using a static signing key. If an adversary can steal (or obtain through a court order) this static (long term) signing key, the adversary can masquerade as the server to the client and as the client to the server and implement a classic Man-in-the-Middle attack.

Security Credentials shall be Capable of Protecting Multipoint Networks (i.e., creating a Security Mesh)

PKI (plus TLS) Violation!

Standard PKI (plus TLS) is limited to binary security relationships.  Thus, in order for multiple nodes to participate in a multimode secured connection, there must either be an extension/deviation added to PKI (plus TLS) or multiple PKI security relationships must be created in order to provide secure communication to interconnect all nodes within the proposed security mesh.

Example: In order to interconnect 50-nodes using PKI (plus TLS), you would need 1,225 (i.e., [(n-1) + (n-2) + (n-3) + …  3+ + 2 + 1] or [((n-1)**2 + (n-1))/2]) separate PKI (plus TLS) connections.

Hardware Endpoints may Have Multiple, Overlaying Security Relationships

PKI (plus TLS) Violation!

The PKI Public Key/Private key pair is usually reserved for ALL communication between EXACTLY two nodes and does not usually allow different security credentials for different applications between the same two nodes.

Authenticates Hardware Endpoint

PKI (plus TLS) Violation!

This is not a capability of either PKI or TLS.

Significantly Mitigates Latency

PKI (plus TLS) Violation!

PKI requires initialization of security credentials (the asymmetric key exchange phase) before it can begin its initial encryption session.  How does this address or violate the previously stated IIoT Security Ideals?

• Requires an additional step prior to being able to initiate bulk encryption.
• By definition, an asymmetric key exchange is significantly greater than linear complexity.
• In order to avoid initial delay, PKI security credentials (the bulk encryption key shared by the Public Key/Private Key, key exchange) may remain static for a period of time.

TLS always requires a session establishment phase, prior to any bulk encryption phase starting (meaning, in addition to any delay added by PKI, TLS has its own delay).

Provides Consistent High-Level Grade Security Regardless of Processing Capability

Possible PKI (plus TLS) Violation!

Not automatically a violation, but because of the asymmetric encryption, key exchange phase, as well as TLS session establishment, PKI (plus TLS) is challenged when it comes to processor architectures with minimal amounts of processing power and/or storage capacity.

Initial Provisioning of New Security Credentials is Autonomous

Possible PKI (plus TLS) Violation!

Initial provisioning of the PKI certificate itself is definitely a violation, but that is so infrequently done, it is not really worth considering here.  Insofar as the security credentials themselves, the vast majority of the time, the policy will be that new security credentials will be issued when the TLS session is renewed (which could be frequent).

Autonomous and Frequent Refreshed/Updated New Security Credentials

Possible PKI (plus TLS) Violation!

The vast majority of the time, policy will dictate that new/refreshed security credentials will be issued when the TLS session is renewed (which could be frequent).

Elimination of Replay Attacks

Possible PKI (plus TLS) Violation!

TLS only protects the transport and thus it provides protection against modifying or replaying of the encrypted data only.  It does not protect against any kind of modifications or replaying of the data before the encryption or after decryption. Sending the same data again over a TLS connection is actually perfectly valid. The cryptographic nonce and timestamp that are used to detect replay attacks do not protect against modification or replaying. The sender can still use the same data but “protect” these “replayed data frames” with a new cryptographic nonce and a new timestamp.

Must be Quantum Resilient

Possible PKI (plus TLS) Violation!

While no one will argue that PKI in its current form is quantum resilient, there are efforts under way to modify PKI in order to make it quantum resilient.  Perhaps this is possible, but it will be just another band-aid that increases the threat surface of PKI and does not fit within anyone’s concept of an ideal secure communication solution.

In fact, Roger Grimes, a well-known, published security expert had this to say about quantum computing and traditional security mechanisms:[5]

“Quantum computers will likely soon break traditional public key cryptography, including the ciphers protecting most of the world’s digital secrets. These soon-to-be-broken protocols and components include HTTPS, TLS, SSH, PKI, digital certificates, RSA, DH, ECC, most Wi-Fi networks, most VPNs, smartcards, HSMs, most cryptocurrencies, and most multifactor authentication devices that rely on public key crypto. If the list just included HTTPS and TLS, it would cover most of the Internet. On the day that quantum computing breaks traditional public crypto, every captured secret protected by those protocols and mechanisms will be readable.” (Cryptography Apocalypse Preparing for the Day When Quantum Computing Breaks Today’s Crypto, 2021)

Current Solutions vs. the Ideal Integrity Management & Monitoring Solution

When considering technologies for configuration management, a common technology for consideration is blockchain, mostly because of its immutable ledger capabilities.  Thus, given blockchain’s relative popularity in this regard, it will be examined for its capabilities as an Ideal Integrity Management & Monitoring solution.

How Does Blockchain Address the Ideal Requirements for Integrity Management & Monitoring?

Blockchain is a technology (and not a product) that is primarily used for protecting the integrity of the information stored within the Blockchain.  Thus, any Integrity Management & Monitoring product based on Blockchain will need to be developed, since it is not an inherent feature of blockchain.

Blockchain certainly has the fundamental infrastructure to address Integrity Management & Monitoring, but in addition to whatever effort it will take to first design and then subsequently implement an IM&M application, Blockchain is well-known for being a heavy and overly complex solution.

Therefore, because Blockchain is overly complex and heavy, any implementation utilizing blockchain will certainly fall short in terms of processing overhead, ease of use, complexity, security (given that it is based on encrypting its data via PKI), etc.  Thus, it is relatively straightforward to eliminate consideration of blockchain without going into further detail.

Provide Solutions that Address the Goals for Ideal Secure Communication and Integrity Management & Monitoring (IM&M)

There are such solutions that exist today.  As of November of 2020, a leading manufacturer of trains in it is now the official IM&M preferred solution for a major rail manufacturer in Germany has adopted the AKM-based Ideal Integrity Management & Monitoring solution for all of their trains being built in the future and addresses all facets of CENELEC 50701 (a new rail standard adopted in May of 2020 and still in a draft state, that was specifically designed to be the rail application of the ISO standard, IEC 62443 (ISA, 2021) and scheduled for release in mid-2021). (European Railway Association, 2020)

Earlier, it was stated that he ideal IM&M solution should be built on top of a solution that meets the aforementioned specified goals for an ideal secure communication solution.  In keeping with this philosophy, that is exactly what was done for the IM&M solution described here.

Autonomous Key Management (AKM), the Ideal Secure Communication Solution

The secure communication solution is a concept known as Autonomous Key Management (AKM) and was initially conceived in November of 2014 to provide complete communication security for automotive vehicles. (SAE International, USA, 2017) (SAE International, USA, 2017)

AKM is both a Decentralized, Distributed, Ledger-Based, Key Management System (KMS) and Multi-point communication security protocol layer.  AKM can naturally act as a drop-in replacement for PKI + TLS.  AKM uses a Broadcast Architecture, that supports true, multi-point end-to-end encryption. [6]

AKM ideally sits on top of UDP and/or TCP and can be implemented directly on top of a physical layer driver using a proprietary thin transport layer.  And, in fact, it has even been integrated into the MAC layer of a transceiver as the security layer for a deterministic, industrial wireless communication protocol.

Below is a list of AKM features and the underlying basis for how each feature is provided:

• Maintenance Free – Once a security group has been provisioned, no external maintenance should ever be required (thus, all AKM relationships are self-maintained and decentralized and require no external maintenance once provisioning has been completed).
• Real-time Data Analytics – Because AKM is a protocol, Data Analytics are available on a per frame basis and thus, in real-time.
• Intrusion Detection – Because Data Analytics can be constant and immediate, if enabled, intrusion detection is a natural extendable feature of AKM.
• Automatic Breach Recovery and Re-provisioning – If enabled because Intrusion Detection is a natural extendable feature, automatic re-provisioning of infected relationships can be re-configured according to policy. Thus, effectively neutralizing threats as soon as a breach is discovered.
• Secure Boot with Device Authentication – This feature uses the unique AKM Protocol Identifier associated with the device, in combination with an onboard, AKM enabled HSM or hardware secure element to provide a Secure Boot Feature to AKM enabled devices. Thus, ensuring only the precise associated host hardware is being used.
• Anti-spoofing and Network Authorization – Because AKM can uniquely associated with a specific device, and because security relationships are constantly being automatically updated, stale or substitute devices cannot be re-inserted into an AKM protected network without being re-provisioned. This also ensures that only authorized devices can ever be inserted into an AKM protected network.
• Replay Attack Protection – The AKM protocol has a replay counter located within every frame. Thus, preventing previous frames from being retransmitted.
• Perfect Forward Secrecy – Because Next Session Security Credentials are calculated based upon a randomly selected subset of parameters from an AKM security relationship specific vector, termed, the Parameter Data Vector (PDV), there is no mathematically available means to determine which parameters were used in prior sessions for calculating previous session Security Credentials. The PDV minimum size is 128-bytes and can be longer if desired by the customer.
• Security Credentials are Re-Generated and NOT Derived – Because the Parameter Data Vector (PDV) is periodically updated based upon configured policy, next session credentials cannot be predicted subsequent to the replacement of the PDV, which is randomly generated and locally distributed within the de-centralized security group.
• Enterprise Grade Entropy – Because the minimum PDV size is 128 and because the smallest allowable PDV subset is 15, assuming an evenly distributive function is used for selecting the PDV parameter subset, the entropy as calculated by the nPr function (the function which calculates the number of permutations of set size, ‘n’, and subset size, ‘r’), is said to be: 1.72831541602 x 1031. For reference the age of the universe as calculated in seconds is said to be somewhere between 1016 and 1017.  Thus, even with a quantum computer, these parameters cannot be predicated without also knowing information that is never exposed (i.e., the internal seeds which are part of each set of AKM Security Credentials).
• Scalability at IoT Scale – Because AKM may be configured as a broadcast architecture, and Security Credentials can be configured for any number of ‘n’ nodes, where ‘n’ is any value greater than ‘1’, there is no limitation with respect to the number of nodes or size of an AKM Security Group Relationship (a security group is the entity for which the security credentials protect).
• Unlimited Virtual Security Relationships (i.e., Security Groups) – Each security relationship is unique from every other security relationship. Security relationships may be defined according to attributes and may co-exist with other virtual security groups on the same AKM Node.  Thus, communication can be performed securely on a per attribute basis.
• Each member of a security group maintains the same exact ledger containing the security credentials. This is the primary mechanism for how all nodes within the same security relationship can stay in sync with each other because they all have the exact same information stored within their ledger.  Thus, if any information within a particular ledger is not in 100% agreement with the information contained within the same security group ledger for the other members (hardware devices) of the group, then it will become immediately detected and the security group will become out-of-synch.  Thus, a security group ledger may be considered to be immutable.
• All security groups have at least two levels of resynchronization in the event that one or more members of a group becomes out-of-synch. In truth, more than two levels exist within AKM, but the methods beyond the initial two levels are for special circumstances and add additional features; primarily for mobility and dynamic expansion/contraction of a security group and are not covered within this chapter.
• Low-Power and Energy Efficient – Because only linear hashing functions and symmetric encryption are used, implementation of AKM requires minimum computational resources.
• Low-overhead – Because Bulk Encryption begins with the very first frame of an AKM session, there is no appreciable latency (other than the protocol header) associated with an AKM protected network.
• Minimal Digital Footprint – Edge Node AKM Software Applets are typically under 20K bytes and can be compressed down to below 10K bytes.
• True Multipoint End-to-End Encryption – Security Credentials applied to ‘n’ nodes, where ‘n’ can be any number greater than or equal to 2.
• Quantum Resilient – Because no public key is used (as in PKI with asymmetric encryption used for the key exchange, which in a closed IOT system is usually there for the lifetime of the system) and because AKM does not share any secrets, there is nothing for a quantum computing device to attack.

AKM Based IM&M, the Ideal Secure Communication Solution

Based on AKM which was explicitly designed to be an “ideal secure communication” solution, it was simple and straightforward to design a corresponding ideal solution for Integrity Management & Monitoring, building on the principles already present within AKM.  As AKM provides the framework for many of the concepts that the ideal IM&M solution also needs.  This concept of the ideal IM&M was derived over a period of two years, between May 2018 and August 2020 and is designed directly from requirements contained within CENELEC 50701 (which as mentioned previously is the rail application of the ISO standard, IEC 62443).

Features of the AKM-based IM&M solution are:

• Physical Device Validation (i.e., Identification + Authentication of the Physical Hardware) – This feature uses the unique AKM Protocol Identifier associated with the device, in combination with an onboard, AKM enabled HSM or hardware secure element to provide a Secure Boot Feature to AKM enabled devices. Thus, ensuring only the specified associated host hardware is being used.  This guarantees against accidental misconfigurations or intentional spoofing of the hardware.
• Electronic Image Validation (i.e., Identification + Authentication of the electronic image)– This feature Identifies and Authenticates every electronic image within the release set for the specified hardware.
• Subsystem Validation (i.e., Identification + Authentication of the logical subsystem) – This feature uses a combination of a unique AKM Protocol Identifier associated with the subsystem and shared immutable ledgers of all of the physical devices within the subsystem (direct downlinks at the subsystem level).
• System Validation (i.e., Identification + Authentication of the entire system) – This feature uses a combination of a unique AKM Protocol Identifier associated with the system and shared immutable ledgers of all of the subsystems that are immediately beneath the system level (direct downlinks within at the system level).
• User Validation (i.e., Identification + Authentication of the individual users, both human and otherwise) – This feature uses a combination of a unique AKM Protocol Identifier associated with user and a physical ledger item maintained locally within the secure element hardware store of the devices, subsystems, and systems, for which the user is associated with to ensure the validity of the user.
• Remote Access – This feature enables remote access to the system via both legacy mechanisms like RADIUS, as well as AKM protected communication.
• Audit Trail of Assets with Tamper-proof Audit Logs – This feature is derived from the AKM concept of shared immutable ledgers for members of the same security relationship and extends the ledger by adding the capability of an audit trail.
• Military Grade Secure Communication between Devices – This feature comes from multiple facets of the AKM framework. First, because AKM is crypto-agile, any cryptographic function or encryption algorithm may be used.  Second, because of the extremely limited threat surface, protecting the threat surface is straightforward and simplistic.  Third, there is no information that are ever communicated as part of the normal session security credential update process that could ever lead to a breach if intercepted.  Fourth, as is mentioned within the list of AKM features, new and refreshed security relationships are created with Enterprise Grate Entropy (which can be easily increased with minimal increase in overhead).  Last, all sensitive information is continually protected within a hardware secure element or Hardware Security Module (HSM) and is never exposed outside of the hardware secure element or HSM.
• Real-time Data Analytics – This feature is inherited directly from AKM, given that AKM is used to exchange information between hardware devices, and subsystems. Thus, AKM-based IM&M inherits and extends real-time data analytics as well.
• Intrusion Detection – Again, this is an inherited feature of AKM, and is facilitated by an IM&M Network Management Module, which locally manages the entire system (or subsystem if a large system and hierarchical management is required) and utilizes the real-time data analytics gathered by AKM as well as utilizing traditional intrusion detection mechanisms.
• Maintenance Free – This is another inherited feature of AKM. Once an IM&M security group has been provisioned, no external maintenance should ever be required (thus, all AKM IM&M relationships are self-maintained and decentralized and require no external maintenance once provisioning has been completed).
• Automatic Breach Recovery and Re-provisioning – Because an IM&M Network Management Gateway is required within the system or subsystem level (depending upon complexity of the overall network), this feature is always present, but the degree of automation is determined by configured policy. The IM&M Network Management Gateway automatically configures the network and acts as the local trust anchor.  Thus, Intrusion Detection is a natural extendable feature, as is, automatic re-provisioning in the event of infected relationships that require re-configuring (in according to policy).  This feature effectively neutralizes threats as soon as a breach is discovered.
• Anti-spoofing and Network Authorization – Because AKM is uniquely associated with a specific device, and because security relationships are constantly being automatically updated, stale or substitute devices cannot be re-inserted into an AKM protected network without being explicitly re-provisioned by a trusted device (such as the Backoffice server remotely or the In-Network Management Gateway locally). This also ensures that only authorized devices can ever be inserted into an AKM protected network.
• Other features directly inherited from AKM are: Replay Attack Protection, Perfect Forward Secrecy, Security Credentials are Re-Generated and NOT Derived, Scalability at IoT Scale, Unlimited Virtual Security Relationships (i.e., Security Groups), True Multipoint End-to-End encryption, Quantum Resilience.
• Low-Power and Energy Efficient – Another AKM inherited featured, but also because IM&M uses static integrity codes that are calculated based upon linear hashing functions, AKM-based IM&M requires minimum computational resources.
• Low-overhead – Because AKM-based IM&M runs in the background during runtime, uses only linear hashing functions for the integrity code calculation of the individual components, and simple compares of the integrity codes for validating the components, the overhead of AKM-based IM&M is extremely low, with the frequency of background component integrity code recalculation adjusted in accordance with policy.
• Minimal Digital Footprint – Edge Node AKM Software Applets are typically under 20K bytes and can be compressed down to below 12K bytes.

Summary

While both of these solutions were initially designed for OT centric closed systems, over time, the author has discovered that they are equally applicable to the IT world and many of the problems that IT faces.

AKM can easily be a drop-in replacement in IT applications for the traditional cryptographic Key Management Systems (KMS) of Public Key Infrastructure (PKI) and the secure communication protocol, the Transport Layer Security protocol, with the most current revision being TLS 1.3.  As AKM and AKM-based IM&M addresses all of the problems plaguing both PKI and TLS because that is what it was explicitly designed to do (address problems in IoT centric systems for both solutions).

More recently, it was discovered that the IM&M solution would provide an excellent framework for solving the larger problems of ransomware, malware, and zero-day attacks.

Using AKM & AKM-Based IM&M for Solving the Most Difficult Problems Plaguing IT Communication and Systems

AKM and its IM&M derivative provide the perfect foundation for solving the Ransomware/Malware/Zero-Day Attack, computer problem at the enterprise level (a solution for the individual small business/home office solution has also been addressed but will be presented in a future edition for the purpose of brevity and importance).  Using both AKM and its derivatives, like IM&M, an extension to the concept of whitelisting, which is termed, White boxing within this document, is able to:

1) Identify, verify, authenticate, and monitor all known executables and data, marking them as “safe to use” once authenticated and moved to the “Trusted Component” list (the White box).

2) Calculate an integrity code derived from a hash based, digital signature for each “safe to use” software component. Thus, enabling instant verification of all known, components on the “Trusted Component” box.

3) Identify, verify, authenticate, and monitor each hardware endpoint, ensuring that only trusted hardware devices are on the network.

4) Create a digital signature for each “trusted” hardware device, that is based upon the aggregation of all “Trusted Components” within the device. Thus, enabling instant verification of each “trusted” hardware device.

5) Create logical security groups of hardware devices in accordance with application context and customer preferences, for which all hardware devices within the security group will communicate integrity data using its own, unique set of security credentials that is refreshed on a per session basis, with perfect forward security, and without exchanging any secrets.

6) Ensure the immutability of each trusted device’s integrity code information (distributed ledger based) given that all integrity codes and other related information for each trusted device within a security group is shared with all other trusted devices. Thus, ensuring that the integrity code of an individual device cannot be altered without altering the same integrity code contained within the secured integrity information of the other trusted devices that are part of the same security group (i.e., each device within a security group contains a copy of the integrity codes of all of the other devices within the same group, plus an integrity code representing the security group itself).

7) Create a digital signature for each security group based upon the aggregation of integrity codes of the individual trusted devices within each group. Thus, enabling instant verification of each security group.

8) Group the security groups hierarchically, so that the top-level security group represents the entire network, thus, enabling a quick check of the entire network, with a very simple, fast, linear cross-check of the system integrity code.

9) Periodically update the integrity codes of each component, both hardware and software within the entire system, on an ongoing and continual basis in the background, so as not to interfere with normal processing.

10) Using malware scanning functionality, scan each unknown application (or single executable if not contained within an encapsulating application) for validation of existing threats. If it is not on the existing threats list, add it to the list of applications to be cross verified by a human operator.

Figure 6.1 White boxing

Source: Olympus Sky (See endnote 5)

11) Once authorized personnel have authorized a new/unknown application (set of executables & related files) as safe, the IM&M-based White-boxing solution automatically updates the “Trusted Component” box with the new, trusted, application.

Figure 6.2 Human Operator moves Application V to Trusted Applications

Source: Olympus Sky (See endnote 5)

12) Application White-boxing denies the execution of any application that has not previously been explicitly approved as “known to not be malicious” (i.e., has not been previously placed within the Trusted Component” box). This “default deny” approach offers a much higher degree of security than traditional antivirus blacklisting approaches for a number of reasons, with the single biggest reason that it denies “zero-day” attacks. Whereas, with standard “blacklisting”, typical antivirus blacklist databases will not recognize the malware on “day zero”, because it has never seen it.

The most difficult part of Application White-boxing (AWB) is admittedly managing what is and is not within the White-box.  It is extremely difficult to keep the list of what is and is not allowed within a system where there are hundreds of thousands of files and many of them have a legitimate need to dynamically change at runtime.  This is perhaps the core problem that modern AWB solutions exists to solve and is a very solvable problem.  What makes it solvable is not expecting end users or IT administrators to figure out the details, but to ask them only for high-level approval of an entire action and then using software to track the precise details of exactly what files need to change, which is exactly how the IM&M-based White-box Enterprise solution operates (see steps (10) and (11) above).

Core elements of the IM&M-based White-box Enterprise solution are: AKM and AKM-based IM&M.  The IM&M-based White-box Enterprise application sits on top of AKM-based IM&M, which in turn sits on top of AKM.

AKM-based IM&M first validates and authenticates the hardware device it resides in and then, for each software component within the hardware device that is part of a designated set of release files, executables, database files, configuration files, html files, etc., the AKM-based IM&M derives a unique integrity code for each software component.  AKM-based IM&M then uses a hash of an aggregation of values from the hardware device in combination with the integrity codes from each software component within the designated set of release files, to create an integrity code for the hardware device.

Files that are part of the specified set of release files are all tracked and controlled using the aforementioned, unique integrity code.  The AKM-based IM&M maintains a list of all integrity codes that are part of the system’s release file set.    Executable files that are part of this file list form the initial set of trusted applications.  The AKM-based IM&M then, on a periodic basis, performs a check to ensure that the list of known valid files remain intact.

AKM-based IM&M maintains integrity across all nodes within a system by allowing nodes to be organized into logical groups in accordance with user preferences.  Then, each node within that a logical group will form a security group based upon those user defined preferences.  Using ledger-based technology, each individual node that is part of a security group, maintains a ledger both for itself, as well as each of the other nodes within its same security group.  Therefore, rendering the ledgers of the individual nodes immutable, since identical copies of all ledgers are maintained across all nodes within the same group.

AKM-based IM&M allows as many of these logical group relationships as the customer wishes to create and they may be formed into any combination, and hierarchically as well.  Thus, enabling the integrity code of any logical group to be an instant indicator of whether or not all hardware and software components within that group have been identified and authenticated.  Meaning, the ability to discern the state of any part of the system is instantaneous and because the components are continually being reverified and authenticated in the background, the likelihood of malware being able to spread throughout the system is significantly mitigated.

This is the best of both worlds.  AKM-based IM&M ensures release set files remain valid, while intrusion detection monitors for anomalous digital signatures.

The IM&M-based White-boxing solution takes this a step further, by managing the contents of the White-box.  Only trusted applications will be allowed to execute.  All other executables will be denied the ability to run.  Working with the intrusion detection module, non-release set executables can be added to the list of trusted applications, but first must be checked against the known set of malware digital signatures for verification purposes.

Once a non-release set executable has been added to the set of trusted applications, it too is added to the designated set of release files and is assigned an integrity code, thus being tracked in the same way as if it had been one of the original sets of release files.  In this way, the ability to instantly and continually verify the integrity of each hardware component, its subgroup, and the overall system to which it belongs, is maintained even as the system grows in its components list while simultaneously decreasing the overall threat surface.

The key attributes of this approach are threefold:

1) Using information known at system instantiation, it creates a list of all known good (validated) applications and continually verifies these known good applications throughout the lifetime of the system using a simplistic method for maintaining the integrity of the individual applications and comparing the resultant calculated integrity code with the previous known value of the application’s integrity code.

2) Disallows any unknown application from running and isolates it a logically separate part of the system.

3) Uses human validation to admit new and/or unknown applications into the White box.

Clearly, the potential for exploitation is the human aspect, but a clear audit trail will be created for each interaction ensuring at the very least, the ability to trace actions with resultant consequences.

Conclusions

This chapter has focused on current problems plaguing both secure communication and the overall integrity of systems today.  It has also suggested sets of requirements for what “ideal” solutions for both secure communication and integrity management and monitoring. Looking into the future, it has suggested a solution for some of the biggest remaining issues in IT and OT today, ransomware and malware, including zero-day attacks.

Questions

1. AKM states that it has the concept of Perfect Forward Secrecy. What is this feature and why is it important? Does this give AKM an advantage over PKI?
2. AKM couples a hardware endpoint (i.e., a hardware module) to a particular AKM Hardware Identifier ( which is similar to a MAC address). How does this feature help AKM prevent hardware spoofing or ransomware?
3. Why will quantum computing be detrimental to PKI based security implementations?

REFERENCES

CENSEC, DK. (2019, June 3). Railway Cyber Security Threats and Resilient Measures. Retrieved from https://censec.dk/: https://censec.dk/wp-content/uploads/2019/06/Alex-Bishop-Railway-Cyber-Security-Threats-and-Resilient-Measures.pdf, slide 24

Cryptography Apocalypse Preparing for the Day When Quantum Computing Breaks Today’s Crypto, G. R. (2021). Cryptography Apocalypse Preparing for the Day When Quantum Computing Breaks Today’s Crypto, Grimes, Roger A., Cryptography Apocalypse (p. xxii). Washington: Amazon, Kindle ed. Retrieved from Cryptography Apocalypse Preparing for the Day When Quantum Computing Breaks Today’s Crypto, Grimes, Roger A., Cryptography Apocalypse (p. xxii). Wiley. Kindle Edition.

Department of Sociology, University of Oxford, Manor Road Oxford OX1 3UQ. (2008, February 8). Engineers of Jihad. Retrieved from www. sociology.ox.ac.uk/swp.html: www. sociology.ox.ac.uk/swp.html

European Railway Association. (2020, November 13). webinar_cybersecurity_in_railways_en. Retrieved from www.era.europa.eu: https://www.era.europa.eu/sites/default/files/events-news/docs/questions_answers_webinar_cybersecurity_in_railways_en.pdf

ISA. (2021, January 2). New ISA/IEC 62443 standard specifies security capabilities for control system components- Summary . Retrieved from www.isa.org: https://www.isa.org/intech-home/2018/september-october/departments/new-standard-specifies-security-capabilities-for-c

Michael, M. (n.d.). Retrieved from www.tuvit.de.

Michelle Michael, TÜV Informationstechnik GmbH, TÜV NORD GROUP. (2021, January 2). Whitepaper Industrial Security based on IEC 62443. Retrieved from www.tuvit.de. : www.tuvit.de.

SAE International, USA. (2017, September 17). Autonomous Key Management (AKM) Security Architecture for Vehicle and IoT Applications . Retrieved from sae.org: www.sae.org

SAE International, USA. (2017, March 28). Autonomous Key Management (AKM) Security Architecture for Vehicle and IoT Applications . Retrieved from sae.org: www.sae.org