ease isa/iec 62443 compliance with edgelocktm se050 › docs › en › application-note ›...

AN12660Ease ISA/IEC 62443 compliance with EdgeLockTM SE050Rev. 1.0 — 16 June 2020 Application note582810

Document informationInformation Content

Keywords ISA/IEC 62443, Industrial security, EdgeLock SE050

Abstract This document elaborates on the use of EdgeLock SE050 features to reduceimplementation complexity and to fulfill the security requirements mandatedby the ISA/IEC 62443-4-2 standard.

NXP Semiconductors AN12660Ease ISA/IEC 62443 compliance with EdgeLockTM SE050

AN12660 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2020. All rights reserved.

Application note Rev. 1.0 — 16 June 2020582810 2 / 31

Revision historyRevision historyRevisionnumber

Date Description

1.0 2020-06-16 Initial version




1 Introduction

The potential risk from cyberattacks increases as the number of connected controllers,machines, devices and sensors keeps growing. As such, security proves itself as acritical element in the development of industrial control systems against intentional orunintentional threats. These threats may include personal injury, equipment damage,supply chain downtime, environmental impact, loss of production or violation of regulatoryrequirements, among others.

The industry has responded to cybersecurity threats by creating standards to assist end-users and equipment vendors through the process of securing industrial control systems.In this respect, the ISA/IEC 62443 series of standards addresses the security of IndustrialAutomation and Control Systems (IACS) throughout their lifecycle.

With ISA/IEC 62443 certification, OEMs demonstrate that their systems or products havebeen independently evaluated to ensure that they are free from known vulnerabilities andhave a robust architecture for protection against cyber attacks. In addition, it providesassurance and confidence to end-users that products comply with higher standards foremployee safety.

As part of the ISA/IEC 62443 standard, four security levels (SL1, SL2, SL3 and SL4)are defined, each of which represents an incremental level in terms of cybersecuritymeasures and in the requirements to be met. In this context, the use of a Secure Element(SE) such as EdgeLock SE050 with its pre-integrated security features eases thecompliance with ISA/IEC 62443 component requirements and it allows the OEM tostrengthen even more the IoT device against logical and physical attacks, making thedevice future-proof.

2 How to use this document

This document is addressed to OEMs interested in understanding how EdgeLock SE050can be used to facilitate the implementation of ISA/IEC 62443-4-2 requirements. It isstructured as follows:

• ISA/IEC 62443 standard overview section provides a brief introduction to ISA/IEC62443 standard and its main concepts.

• Leverage EdgeLock SE050 to meet ISA/IEC 62443-4-2 requirements sectionelaborates on a set of security primitives needed in order to achieve ISA/IEC 62443-4-2compliance, and describes how EdgeLock SE050 can be leveraged to meet ISA/IEC62443-4-2 requirements.

• ISA/IEC 62443-4-2 requirements lookup table section maps ISA/IEC 62443-4-2requirements with the associated security primitives helping to meet that particularrequirement.

• The Glossary section lists common acronyms used throughout the document anddefines their meaning.

3 ISA/IEC 62443 standard overview

The ISA/IEC 62443 standard is a series of standards and technical reports helpingorganizations to mitigate the risk of failure and exposure to security vulnerabilities inIndustrial Automation and Control Systems (IACS). The ISA/IEC 62443 is organized intofour categories: General, Policies and Procedures, System, and Component:




• General information: its four parts contain foundational information such as concepts,models and terminology used as a basis for the other categories of the standard.

• Policies and Procedures: its five parts comprise the requirements and different aspectsfor creating and maintaining effective security processes. This part of the standardspecifically targets factory operations.

• System: its three parts describe the technical requirements for system design and theguiding principles for implementing and integrating secure systems. This part of thestandard is targeted to industrial system integrators.

• Component: its two parts contain the technical guidelines for developing secureindustrial components or products. This part of the standard is targeted tomanufacturers of industrial devices.

Figure 1. ISA/IEC 62443 overview

To assess and classify the required protection level, the ISA/IEC 62443 standard definesthe concept of security assurance levels. These security levels are connected to risk andasset value and are organized in tiers, each one requiring more stringent measures to beput in place, as detailed in Table 1:

Table 1. ISA/IEC 62443 security assurance levelsSecurity level (SL) Description from ISO/IEC 62443-1-1 section 10.4.3

SL0 No specific requirements or security protection requirements

SL1 Requires protection against casual or coincidental violations

SL2 Requires protection against intentional violation using simple meanswith low resources, generic skills and low motivation

SL3 Requires protection against intentional violation using sophisticatedmeans with moderate resources, specific skills and moderatemotivation

SL4 Requires protection against intentional violation using sophisticatedmeans with extended resources, specific skills and high motivation




Security Levels 1 and 2 correspond to threats originating from either insiders or intruderswith low skills and motivation. On the other hand, Security Levels 3 and 4 are relatedto threats from “professional” cyber criminals, industrial espionage or state-sponsoredmalicious actors that demonstrate high skills and moderate to high motivation.

The ISA/IEC 62443 standard establishes a practical guide on how to implementprotective measures against cybersecurity incidents based on the defined security levels,grouped into seven foundational requirements:

• FR1: Identification and Authentication Control (IAC)• FR2: Use Control (UC)• FR3: System Integrity (SI)• FR4: Data Confidentiality (DC)• FR5: Restricted Data Flow (RDF)• FR6: Timely Response to Events (TRE)• FR7: Resource Availability (RA)

Each foundational requirement (FR) defines specific security requirements depending oncomponent type, scope and applicability. The requirements that apply indifferently to allcomponent types are denoted as Component Requirements (CR). In case a requirementapplies only to a specific component type, the requirement is denoted as EmbeddedDevice Requirement (EDR), Network Device Requirement (NDR), Software ApplicationRequirement (SAR) or Host Device Requirement (HDR) accordingly.

Table 2 details the component types defined in ISA/IEC 62443 standard.

Table 2. Component typesType Description Example

Embedded Device(ED)

Specialized device designed to directly monitor,control or actuate an industrial process. Anembedded device typically runs embeddedsoftware, has an embedded OS or firmwareand can be programmed only through externalinterfaces. It may have a communicationinterface and an attached control panel.

Programmable LogicController (PLC), SafetyInstrumented System(SIS) controller, DistributedControl System controller(DCS)

Network Device(ND)

Device that facilitates or restricts the data flowbetween devices, but does not directly interactwith a control process.

Firewall, router, gateway,switch

Host Device (HD) General purpose device running a generalpurpose OS (for example Microsoft WindowsOS or Linux). A host device is capableof running one or more general purposeapplications and it typically has a local orremote human-machine interface.Note: Host devices are outside the scope of thisdocument.

Server, PC, data centers

SoftwareApplication (SA)

Software program that is used to interfacewith the process or the control system. It istypically executed in embedded devices andhost devices.

SCADA software, PLCladder-programmingsoftware, data loggers




As a conclusion, the ISA/IEC 62443 standard provides a point of reference for allthe actors participating in the IACS ecosystem to improve cybersecurity in industrialenvironments. On this basis, OEMs and manufacturers can implement the protectivemeasures to comply with the necessary requirements to achieve the target security level.

4 Leverage EdgeLock SE050 to meet ISA/IEC 62443-4-2 requirements

The various ISA/IEC 62443 standards depicted in Figure 1 are intended to be multi-industry in nature and are targeted at different audiences, ranging from suppliers anddevice vendors to end-users. For OEMs of industrial products, including applications,embedded devices, network components and host systems, the security functionsrequired at the component level are listed in ISA/IEC 62443-4-2.

Figure 2 depicts a simplified breakdown of an industrial control system integratinga smart, connected industrial device, also referred to as IoT device, that leveragesEdgeLock SE050. The IoT device is represented by the platform, composed of an MCU /MPU connected to EdgeLock SE050, and the application, which is the software runningin the IoT device hardware. This IoT device is integrated within an industrial controlsystem, which includes its own network resources, backend servers and operationalprocesses. The different parts of the IoT device are typically strictly integrated and theircombined features allow a component to achieve the security requirements imposed byISA/IEC 62443-4-2.

Figure 2. Breakdown of a simplified industrial control system

Note: In the scope of ISA/IEC 62443-4-2 standard, the focus is on the component leveland the security features to be implemented at the IoT device level. Further elements inindustrial control systems are not considered.

EdgeLock SE050 offers a trusted, highly secure environment where critical keys andcredentials can be stored securely and where built-in cryptographic operations usingsecure cryptographic algorithms can be performed.




EdgeLock SE050 simplifies the implementation of security features in industrial systemcomponents since it allows to outsource to a single chip many of those security-relatedoperations that would otherwise require a complex software implementation. In thisrespect, EdgeLock SE050 comes with a pre-installed IoT applet offering advancedkey management and cryptographic functions. To ease the integration of the appletfunctionalities in the IoT solution, EdgeLock SE050 even provides a fully-featuredmiddleware package. The middleware is pre-integrated with many micro-controllerplatforms and contains several examples and demo projects that can be used as astarting point for custom software implementations.

Moreover, EdgeLock SE050 is pre-provisioned with keys and credentials in a highlysecure and controlled environment, therefore relieving IoT device manufacturers fromsetting up a complex and expensive PKI infrastructure.

As a result, EdgeLock SE050, in combination with MCUs / MPUs and softwareapplications, acts as an enabler of the security requirements defined in ISA/IEC62443-4-2 and even more, it goes beyond what is strictly required by the standard, andprovides an extra level of security that makes an IoT device future-proof and resistant tothe latest security threats.

In order to present a more organic view of security requirements, we identified a set ofsecurity primitives (SP) with the purpose of defining a common and easier to understandnomenclature across standards to describe security requirements in IoT systems.In respect of ISA/IEC 62443 standard, security primitives help you to map securityfeatures of an IoT device to ISA/IEC 62443-4-2 security requirements. You can find moreinformation about how to use security primitives in the white paper Security Primitives:Common Nomenclature to Describe Security Requirements in IoT Systems.

The security primitives where EdgeLock SE050 can add a valuable contribution arelisted in Table 3. In the next sections, EdgeLock SE050 features will be put in the contextof each security primitive listed in Table 3. Which ISA/IEC 62443-4-2 requirementsEdgeLock SE050 can help to achieve will also be described.

Table 3. Security primitives definitionCode Security primitive

SP1 Anomaly detection and reaction

SP2 Device attestation

SP3 Secure backup and recovery

SP4 Protection of Personal Information

SP5 Secure Provisioning and Decommissioning

SP6 Cryptographic Random Number Generation

SP7 Root of Trust

SP8 Secure Communication Protocols

SP9 Secure Initialization

SP10 System Event Logging

SP11 Secure Encrypted Storage

SP12 Cryptographic Key Generation and Injection

SP13 Cryptographic Key and Certificate Store

SP14 Cryptographic Operation

https://www.nxp.com/docs/en/white-paper/SEC_PRIMITIVES_WP.pdf

https://www.nxp.com/docs/en/white-paper/SEC_PRIMITIVES_WP.pdf




Code Security primitive

SP15 Secure Onboarding and Offboarding

SP16 Secure Updates

4.1 SP1: Anomaly detection and reactionThe security primitive Anomaly Detection and Reaction clusters software and hardwarefeatures that monitor the IoT device for abnormal events and, if required, trigger andexecute an appropriate action. Typically, these actions encompass logging the anomaly,issuing a message to the cloud backend, resetting the device, and/or changing a securelifecycle state. This primitive includes logical and physical tamper detection and tamperprotection of the IoT device.

EdgeLock SE050 provides enhanced run-time integrity protection for IoT devices. Bypairing it with the host MCU of the device, a secure initialization of the device can alsobe enforced (see Binding an MCU to EdgeLock SE050 Application Note). Any anomalyoccurring during that stage would result in a lifecycle state of the Secure Element (SE) inwhich mission critical keys and certificates are not available to the host device. Furtherdetails on how the EdgeLock SE050 ensures that long-lived credentials are kept safeduring the device lifecycle are provided in Cryptographic Key and Certificate Storesecurity primitive. In addition, EdgeLock SE050 provides a tamper-resistant platform,certified up to the Operating System (OS) level at CC EAL 6+. In case a physicaltampering of the SE is detected, EdgeLock SE050, in combination with specific softwareapplication components, can trigger the appropriate countermeasures, such as notifyingthe system backend or resetting the device.

Leveraging both mechanisms of ensuring run-time integrity and triggering actions ondetected anomalies provided by EdgeLock SE050 aids in achieving ISA/IEC 62443 4-2compliance for the requirements listed in Table 4 to the highest security levels.

Table 4. ISA/IEC 62443-4-2 requirements supported by SP1 and benefiting from EdgeLockSE050Code Requirement SL1 SL2 SL3 SL4

CR 1.5.1 Hardware security for authenticators - - X X

CR 1.9.1 Hardware security for public key-basedauthentication

- - X X

CR 1.14.1 Hardware security for symmetric key-basedauthentication

- - X X

CR 3.4.2 Automated notification of integrity violations - - X X

EDR/NDR3.11.0

Physical tamper resistance and detection - X X X

EDR/NDR3.11.1

Notification of a tampering attempt - - X X

EdgeLock SE050 inherently supports the ISA/IEC 62443 requirement EDR/NDR 3.11.0with its integrated tamper protections certified up to the OS level at CC EAL 6+ includingAVA_VAN 5, the highest achievable level in vulnerability analysis and penetration testing.Additionally, application developers can leverage EdgeLock SE050 tamper reactionfeatures to easily fulfil CR 3.4.2 and 3.11.1. Finally, if authenticator keys are stored insidethe EdgeLock SE050 key store, the requirements CR 1.5.1, CR 1.9.1 and CR 1.14.1 areinherently fulfilled (and certified). In this context, EdgeLock SE050 ensures that long-




lived credentials are kept safe during the device lifecycle, even if an attacker has physicalaccess to the device. Cryptographic operations are always performed inside EdgeLockSE050 with the keys remaining in the secure environment.

4.2 SP2: Device attestationThe Device attestation security primitive clusters those features that provide evidence ofthe IoT device genuine identity, its software and firmware version, as well as its integrityand lifecycle state. Genuine identification requires ensuring a unique identification of theIoT device.

EdgeLock SE050 is pre-injected in NXP's secure facilities with a device-unique, read-only 7-byte UID that can be used to identify the whole IoT device. If the use case requiresit, a custom identifier can also be injected in EdgeLock SE050 and protected againstdeletion and overwriting using the appropriate policies. EdgeLock SE050 also supportsstorage of X.509 certificates that can be used to bind the device identity to a public key.Such certificates can be used to attest the device identity as part of challenge-basedprotocols that assess the possession of the corresponding private key. Certificates canbe stored in DER format as binaries and protected against deletion and overwriting usingthe appropriate policies. EdgeLock SE050 is pre-provisioned with a set of keys, andcorresponding certificates, that can be used to attest the device identity in different usecases, including cloud onboarding and device-to-device authentication. More informationcan be found in Secure Onboarding and Offboarding security primitive.

The EdgeLock SE050 Plug&Trust middleware API can be used to simplify the integrationof the abovementioned use cases in the industrial IoT solution. The main EdgeLockSE050 Plug&Trust middleware API functions supporting the core use cases of thissecurity primitive are listed below:

• Read EdgeLock SE050 pre-injected UID: Se05x_API_ReadObject( kSE05x_AppletResID_UNIQUE_ID )

• Read binary identifier / certificate: sss_key_store_get_key (),Se05x_API_ReadObject ()

• Inject a binary identifier / certificate: sss_key_store_set_key (),Se05x_API_WriteBinary ()

The EdgeLock SE050 Plug&Trust middleware also provides a set of demos and codeexamples that might be useful to show how to use the pre-installed applet and ease theimplementation of the use cases supported by the Device attestation security primitive.The relevant examples, along with their location in EdgeLock SE050 Plug&Trustmiddleware folder structure, are shown below:

• EdgeLock SE050 Get Info example: \simw-top\demos\se05x\se05x_Get_Info (seeSection 5.15 of EdgeLock SE050 Plug&Trust middleware documentation)

• Get certificate from the SE example: \simw-top\demos\se05x\se05x_Get_Certificate(see Section 5.18 of EdgeLock SE050 Plug&Trust middleware documentation)

• Building a self-signed certificate demo: \simw-top\demos\se05x\certificate_demo(see Section 5.37 of EdgeLock SE050 Plug&Trust middleware documentation)

Leveraging identifier and certificate management capabilities provided by EdgeLockSE050 aids in achieving ISA/IEC 62443-4-2 compliance for the requirements listed inTable 5 at the highest security levels.




Table 5. Requirements eased by SP2 and benefiting from EdgeLock SE050Code Requirement SL1 SL2 SL3 SL4

CR 1.2.0 Software process and device identification andauthentication

- X X X

CR 1.2.1 Unique identification and authentication - - X X

EdgeLock SE050 supports CR 1.2.0 and CR 1.2.1 by providing a pre-injected 7-byteUID identifier and a set of digital certificates uniquely bound to the device. Identifiers andcertificates can be used to attest the genuine identity of the IoT device.

4.3 SP3: Secure backup and recoveryThe secure backup and recovery security primitive clusters those functionalitiesthat are used to back up the device (locally or in the cloud), and/or restore it at alater point in time. The backup may include user data, device software, device state,device configuration, or a combination thereof. The backup data shall be integrity andauthenticity protected.

EdgeLock SE050 provides support for cryptographic signature algorithms that canbe used to sign and then verify the digest of a backup in order to ensure the backupintegrity and authenticity before restoring it. EdgeLock SE050 supports both RSA andECC (ECDSA, EdDSA) signature algorithms for this purpose. The backup digestscan be generated by EdgeLock SE050 using supported hash functions (SHA-224to SHA-512). For additional protection of the backup data, EdgeLock SE050 can beleveraged to encrypt the backup before saving it locally or uploading it to the cloud.EdgeLock SE050 provides both asymmetric encryption algorithms (RSA, ECC) andsymmetric encryption algorithms (AES, DES) for this purpose. The EdgeLock SE050tamper-resistant hardware ensures that signing keys and encryption keys are protected.

The EdgeLock SE050 Plug&Trust middleware API can be used to simplify the integrationof the abovementioned use cases in the IoT solution. The main EdgeLock SE050Plug&Trust middleware API functions supporting the core use cases of this securityprimitive are listed below:

• Sign / verify a digest of a backup: sss_se05x_asymmetric_sign_digest(), sss_se05x_asymmetric_verify_digest (), sss_se05x_asymmetric_sign (),sss_se05x_asymmetric_verify ()

• Generate a digest of a backup: sss_se05x_digest_one_go ()• Encrypt / decrypt a digest of a backup: sss_se05x_asymmetric_encrypt(),

sss_se05x_asymmetric_decrypt(), sss_se05x_cipher_one_go()

The EdgeLock SE050 Plug&Trust middleware also provides a set of demos and codeexamples that might be useful to implement the use cases supported by the SecureBackup and Recovery security primitive. The relevant examples, along with their locationin EdgeLock SE050 Plug&Trust middleware folder structure, are shown below:

• Message Digest Example: \simw-top\sss\ex\md (see Section 5.2.6 of EdgeLockSE050 Plug&Trust middleware documentation)

• ECC Signing Example: \simw-top\sss\ex\ecc (see Section 5.2.1 of EdgeLock SE050Plug&Trust middleware documentation)

• RSA Signing Example: \simw-top\sss\ex\rsa (see Section 5.2.2 of EdgeLock SE050Plug&Trust middleware documentation)

• Symmetric AES Encryption Example: \simw-top\sss\ex\symmetric (see Section 5.2.3of EdgeLock SE050 Plug&Trust middleware documentation)




Leveraging encryption and signature functions provided by EdgeLock SE050 aids inachieving ISA/IEC 62443 4-2 compliance for the requirements listed in Table 6 at thehighest security levels.


CR 7.3.1 Backup integrity verification - X X X

EdgeLock SE050 supports CR 7.3.1 by providing cryptographic functions to generate adigest of the backup, signing it and verifying the signature before the backup is restored.Additionally, EdgeLock SE050 supports encryption and decryption of the backup contentin order to ensure the confidentiality of sensitive backup data. Cryptographic keys arealways securely stored in EdgeLock SE050 secure tamper-resistant hardware and neverleave the boundaries of the SE.

4.4 SP4: Protection of personal informationThe security primitive Protection of Personal Information clusters those features that helppreserve the confidentiality of personally identifiable information of end users that mightbe stored or managed by the IoT device.

EdgeLock SE050 provides support for cryptographic algorithms that can be used toencrypt sensitive information and protect it from unauthorized access and disclosure.EdgeLock SE050 supports both symmetric (DES, AES) and asymmetric encryption(RSA, ECC) for this purpose. EdgeLock SE050 implements strong hardware security forprotecting encryption keys. In combination with proper user authorization implementedat the application level, EdgeLock SE050 can be used to grant access to sensitiveinformation only to authorized users.


• Encrypt sensitive personal information: sss_se05x_asymmetric_encrypt (),sss_se05x_cipher_one_go ()

• Decrypt sensitive personal information: sss_se05x_asymmetric_decrypt (),sss_se05x_cipher_one_go ()

The EdgeLock SE050 Plug&Trust middleware also provides a set of demos and codeexamples that might be useful to implement the use cases supported by the Protection ofPersonal information security primitive. The relevant examples, along with their locationin EdgeLock SE050 Plug&Trust middleware folder structure, are shown below:


EdgeLock SE050 aids in achieving ISA/IEC 62443 4-2 compliance for the requirementslisted in Table 7 at the highest security levels:






Code Requirement SL1 SL2 SL3 SL4

CR 4.1.0 Information confidentiality X X X X

EdgeLock SE050 supports CR 4.1.0 by providing encryption cryptographic servicesto the IoT device. Such services can be used to protect sensitive personal informationat rest. If encryption keys are stored inside the EdgeLock SE050 key store, CR 1.5.1is fulfilled and certified. In fact, EdgeLock SE050 ensures that long-lived credentialsare kept safe during the device lifecycle, even if an attacker has physical access to thedevice. Cryptographic operations are always performed inside EdgeLock SE050 with thekeys remaining in the secure environment.

4.5 SP5: Secure Provisioning and DecommissioningThe security primitive Secure provisioning and decommissioning is related with theprocess of generating and injecting key material that can be trusted by the OEM in theIoT device. This key material might include public keys or hashes to identify and validatefuture updates, keys and certificates to validate the cloud backend identity, secrets forencrypted connections, or device identifiers. Similarly, decommissioning describes thereverse process, where sensitive data is securely removed from the IoT device once end-of-life of the device is reached.

EdgeLock SE050 is pre-provisioned for ease of use in NXP's secure facilities with a setof device-unique keys, certificates and identifiers. Customers are therefore not requiredto inject additional credentials. Pre-provisioned credentials can be used to support themain use cases, including device-to-device authentication and cloud onboarding. In casethe OEM needs to provision additional or different credentials than the ones securelyprovisioned by NXP, those can be manually created and injected in EdgeLock SE050.The provisioning of custom credentials in EdgeLock SE050 can be performed in thesecure facilities of the device manufacturer or directly in the field using well-established,secure processes and protocols. You can refer to the Cryptographic Key Generationand Injection security primitive for more information on how EdgeLock SE050 supportsgeneration and injection of custom credentials.

EdgeLock SE050 allows you to securely decommision your IoT device. Thanks to itsstrong tamper-resistance capabilities, EdgeLock SE050 protects keys from extractioneven after the device has been decommissioned. Moreover, policies can be set torestrict or disable the usage of stored credentials. For additional security, EdgeLockSE050 supports explicit delete of created credentials (excluding some pre-provisionedcredentials).

The EdgeLock SE050 Plug&Trust middleware API supports the generation and handlingof key material and objects. The main EdgeLock SE050 Plug&Trust middleware APIfunctions supporting these functionalities are listed below:

• Get handle of (pre)provisioned keys or objects: sss_se05x_key_object_get_handle(), sss_key_store_get_key ()

• Generate / inject keys or objects: sss_se05x_key_store_generate_key(),sss_se05x_key_store_set_key ()

• Update keys or objects (including associated policies):sss_se05x_key_store_set_key ()

• Delete provisioned objects: sss_key_store_erase_key (),Se05x_API_DeleteCryptoObject(), Se05x_API_DeleteSecureObject(),Se05x_API_DeleteAll()




The EdgeLock SE050 Plug&Trust middleware also provides a set of demos and codeexamples that can be useful for the implementation of provisioning and decommissioningprocesses. The relevant examples, along with their location in EdgeLock SE050Plug&Trust middleware folder structure, are shown below:

• Symmetric AES Encryption Example (key generation):: \simw-top\sss\ex\symmetric(see Section 5.2.3 of EdgeLock SE050 Plug&Trust middleware documentation)

• ECC Signing Example (key generation): \simw-top\sss\ex\ecc (see Section 5.2.1 ofEdgeLock SE050 Plug&Trust middleware documentation)

• RSA Signing Example (key generation): \simw-top\sss\ex\rsa (see Section 5.2.2 ofEdgeLock SE050 Plug&Trust middleware documentation)

• Using policies for secure objects demo: \simw-top\demos\se05x\se05x_policy (seeSection 5.17 of EdgeLock SE050 Plug&Trust middleware documentation)

Leveraging pre-provisioned and injected keys of EdgeLock SE050 and functions tosecurely delete provisioned credentials aids in achieving ISA/IEC 62443 4-2 compliancefor the requirements listed in Section 4.5 at the highest security levels:


EDR/NDR3.12

Provisioning product supplier roots of trust - X X X

EDR/NDR3.13

Provisioning asset owner roots of trust - X X X

CR 4.2.0 Information persistence - X X X

EdgeLock SE050 supports the ISA/IEC 62443 requirements EDR/NDR 3.12 and EDR/NDR 3.13 by providing pre-provisioned credentials injected in NXP's secure facilities.Such credentials can be used as the root of trust to support a wide variety of usecases. EdgeLock SE050 also allows the customer to provision a custom root of trust.Additionally, EdgeLock SE050 helps achieving CR 4.2.0 since it prevents by designthe extraction of private data, such as private keys, stored inside the SE. It also allowsthe user to erase the data that has been created or to set policies to restrict or disableaccess to stored data.

4.6 SP6: Cryptographic random number generationThe Cryptographic random number generation security primitive clusters those featuresthat are related with the secure generation of random numbers. Random numbers aretypically used in the context of secure protocols and related cryptographic functionalities.This primitive also includes features for the generation of true random numbers.

EdgeLock SE050 supports the generation of variable-length random numbers throughthe built-in AIS20 compliant Pseudo Random Number Generator (PRNG) with DRG.3generation capabilities. The PRNG works on top of EdgeLock SE050 True RandomNumber Generator (TRNG) compliant to AIS31 class PTG.2. More information onEdgeLock SE050 PRNG and TRNG can be found in EdgeLock SE050 Data Sheet.Random numbers generated by EdgeLock SE050 are cryptographically secure and canbe used in the context of security protocols, typically as part of broader cryptographicfunctionalities requiring random initialization data or IDs. For example, most securecommunication protocols require the generation of a random seed or nonce, for instance,

https://www.nxp.com/docs/en/data-sheet/SE050-DATASHEET.pdf




for proof of possession of the private key by the communication partner. You can refer tothe Secure Communication Protocols security primitive for more information.

The EdgeLock SE050 Plug&Trust middleware API can be used to integrate this primitivein the IoT solution. The main EdgeLock SE050 Plug&Trust middleware API functionssupporting the core use cases of this security primitive are listed below:

• Generate a random number: sss_se05x_rng_get_random ()• Generate random data for TLS handshake: Se05x_API_TLSGenerateRandom ()

Leveraging the random number generation capabilities provided by EdgeLock SE050aids in achieving ISA/IEC 62443 4-2 compliance for the requirements listed in Table 9 atthe highest security levels.


CR 2.12.0 Non-repudiation X X X X

CR 3.1.0 Communication integrity X X X X

CR 3.1.1 Communication authentication - X X X

CR 4.3.0 Use of cryptography X X X X

EdgeLock SE050 supports CR 4.3.0 since it provides an implementation of all commoncryptographic algorithms (symmetric and asymmetric) and cryptographic functions,including functions to generate random numbers suitable for use in cryptographicallysecure protocols, e.g. for the generation of random session IDs or nonces. In thiscontext, EdgeLock SE050 helps achieving CR 3.1.0 and CR 3.1.1 as described in theSecure Communication Protocols security primitive. EdgeLock SE050 helps achievingCR 2.12.0 by supporting digital signature algorithms and secure storage of certificatesthat are the base of all secure non-repudiation strategies.

4.7 SP7: Root of TrustThe security primitive Root of Trust clusters those features related with the secureestablishment of the initial Root of Trust (RoT) on the security component when thedevice is manufactured. This might be achieved, for instance, by manufacturing theIoT device inside trusted manufacturing facilities, or by using pre-provisioned SecureElements.

EdgeLock SE050 is pre-provisioned for ease of use in NXP's secure facilities with aset of device-unique key-pairs, certificates and identifiers that can be used to establishthe initial RoT of the IoT device. Pre-provisioned credentials can be used to supportthe main use cases, including device-to-device authentication and onboarding to cloudbackend services. In case the OEM needs to provision different credentials than the onessecurely provisioned by NXP, those can be manually created and injected in EdgeLockSE050. The provisioning of custom credentials in EdgeLock SE050 can be performedin the secure facilities of the device manufacturer or directly in the field using well-established, secure processes and protocols. You can refer to Secure Provisioning andDecommissioning security primitive for more information.

Leveraging pre-provisioned or injected keys of EdgeLock SE050 aids in achieving ISA/IEC 62443 4-2 compliance for the requirements listed in Table 10 at the highest securitylevels:





EDR 3.12 Provisioning product supplier roots of trust - X X X

EDR 3.13 Provisioning asset owner roots of trust - X X X

EdgeLock SE050 supports the ISA/IEC 62443 requirements EDR 3.12 and EDR 3.13by providing pre-provisioned credentials injected in NXP's secure facilities. Additionally,EdgeLock SE050 supports EDR 3.13 by allowing customers to easily provision their owncustom root of trust in case they have their own secure programming facilities.

4.8 SP8: Secure Communication ProtocolsThe security primitive Secure Communication Protocols clusters those features that allowIoT devices to communicate securely with each other and/or the cloud backend. Thisprimitive groups support for secure communication as well as related communicationprotocol support. Examples for such communication could be high-level protocols suchas OPC Unified Architecture (OPC-UA) or Hypertext transfer protocol (HTTP) securedwith Transport Layer Security (TLS).

EdgeLock SE050 can be leveraged to offload communication protocols cryptographicoperations while keeping the cryptographic keys secure inside the SE. EdgeLockSE050 has built-in support for the widely used TLS protocol to secure upper layercommunication protocols such as OPC-UA, HTTP and MQTT. EdgeLock SE050supports the TLS protocol by protecting key-pairs and certificates that are used toauthenticate the IoT device to other parties. Moreover, the EdgeLock SE050 Plug&Trustmiddleware provides functions to simplify the implementation of the TLS handshake byusing EdgeLock SE050 cryptographic functions. More information regarding EdgeLockSE050 TLS support can be found in EdgeLock SE050 for secure connection to OEMcloud.

EdgeLock SE050 also natively supports Secure Channel Protocol (SCP), includingGlobalPlatform SCP03 and FastSCP. The SCP protocol allows you to protect theintegrity of local (Platform SCP) and end-to-end (Applet level SCP) communication withEdgeLock SE050. Other secure communication protocols can be supported by usingEdgeLock SE050 cryptographic functions. Those include asymmetric cryptography (RSA,ECC), symmetric cryptography (AES, DES) , MAC and digest functions (HMAC, CMAC,SHA) and key agreement and derivation functions.


• Perform TLS handshake: Se05x_API_TLSCalculatePreMasterSecret (),Se05x_API_TLSGenerateRandom (), Se05x_API_TLSPerformPRF ()

• Establish a secure SCP channel: Se05x_API_CreateSession (),Se05x_API_SetPlatformSCPRequest ()

The EdgeLock SE050 Plug&Trust middleware also provides a set of demos and codeexamples that might be useful to implement the use cases supported by the SecureCommunication Protocols security primitive. The relevant examples, along with theirlocation in EdgeLock SE050 Plug&Trust middleware folder structure, are shown below:

https://www.nxp.com/docs/en/application-note/AN12400-SE050_secure_connection_OEM_cloud.pdf

https://www.nxp.com/docs/en/application-note/AN12400-SE050_secure_connection_OEM_cloud.pdf




• OPC UA Demo:: \simw-top\demos\opc_ua (see Section 5.13 of EdgeLock SE050Plug&Trust middleware documentation)

• TLS Client example: \simw-top\demos\linux\tls_client (see Section 5.12 of EdgeLockSE050 Plug&Trust middleware documentation)

Leveraging the built-in support for common secure communication protocols and thecryptographic capabilities of EdgeLock SE050 aids in achieving the ISA/IEC 62443-4-2requirements listed in Table 11 to the highest security level.


CR 1.8.0 Public key infrastructure certificates - X X X



CR 3.8.0 Session integrity - X X X


EdgeLock SE050 supports CR 4.3.0 since it provides an out-of-the-box implementationof all common cryptographic functions and cryptographic algorithms, including symmetricand asymmetric cryptography. Such functions can be used as building blocks for theimplementation of secure communication protocols. EdgeLock SE050 helps achievingCR 3.1.0, CR 3.1.1 and CR 3.8.0 since it allows the user to offload the cryptographicoperations that are necessary to establish the secure communication channel. Finally,EdgeLock SE050 supports CR 1.8.0 by providing a secure hardware that can securelystore PKI certificates. Certificates can be stored in EdgeLock SE050 and used as part ofsecure communication protocols.

4.9 SP9: Secure InitializationThe Secure Initialization security primitive clusters features that help ensuring theauthenticity and integrity of the device boot loader, firmware, and other software duringthe boot process. If required, the implementation may handle encrypted boot code.Depending on the use case, secure initialization might encompass one or several bootstages that are each cryptographically secured. Secure initialization may also include thevalidation of an application before running it on top of the platform.

EdgeLock SE050 supports the storage of public keys (RSA, ECC) that can be used toverify a signed digest of a software component before it is loaded and executed. In thisway only applications that have been signed by the OEM with the corresponding privatekey will be accepted as valid by the system. This feature can be used to check theauthenticity and integrity of boot loaders, firmware and OS applications before they areexecuted. For more information on how EdgeLock SE050 can be leveraged to support asecure boot, you can refer to Secure Binding for EdgeLock SE050 Application Note.

For additional protection, boot loaders and applications containing sensitive data canalso be encrypted beforehand and private keys used for decryption can be stored inEdgeLock SE050. EdgeLock SE050 provides both asymmetric encryption algorithms(RSA, ECC) and symmetric encryption algorithms (AES, DES) for this purpose.EdgeLock SE050 also supports Platform Configuration Registers (PCRs): 32-byte arraysthat hold the value of a SHA-256 hash. Once the value of a PCR register is updated,the new value depends on the old value and the new measure. This can be used, for




instance, to enforce an integrity check and an order of execution on a chain of bootloaders.

The EdgeLock SE050 Plug&Trust middleware API can be used to simplify the integrationof the abovementioned use cases in the customers IoT solution. The main EdgeLockSE050 Plug&Trust middleware API functions supporting the core use cases of thissecurity primitive are listed below:

• Verify the signature of an application digest: sss_se05x_asymmetric_verify_digest(), sss_se05x_asymmetric_verify ()

• Encrypt / decrypt application data: sss_se05x_asymmetric_encrypt(),sss_se05x_asymmetric_decrypt(), sss_se05x_cipher_one_go()

• Generate a digest of an application: sss_se05x_digest_one_go ()• Write to a PCR register: Se05x_API_WritePCR ()

The EdgeLock SE050 Plug&Trust middleware also provides a set of demos and codeexamples that might be useful to implement the use cases supported by the SecureInitialization security primitive. The relevant examples, along with their location inEdgeLock SE050 Plug&Trust middleware folder structure, are shown below:





Leveraging cryptographic signature capabilities provided by EdgeLock SE050 aids inachieving ISA/IEC 62443 4-2 compliance for the requirements listed in Table 12 at thehighest security levels.


CR 3.4.0 Software and information integrity X X X X

EDR/NDR3.10.1

Update authenticity and integrity - X X X

EDR/NDR3.14.0

Integrity of boot process X X X X

EDR/NDR3.14.1

Authenticity of the boot process - X X X

EdgeLock SE050 supports EDR/NDR 3.14.1 and EDR/NDR 3.10.1 since it providesa secure environment to store public keys that can be used to verify the signature ofapplications, boot loaders and update packages before they are loaded and executed.EdgeLock SE050 supports CR 3.4.0 and EDR/NDR 3.14.0 by providing cryptographichash functions that can be used to compute the digests of software applications that aregoing to be executed and compare them with pre-computed, signed digests to checkintegrity.




4.10 SP10: System Event LoggingThe System event logging security primitive clusters those functionalities related tosecurely logging system events in an integrity protected way, with related data stored in asecure encrypted storage. This primitive also includes functionalities that can be used toimplement non-repudiation strategies.

EdgeLock SE050 supports asymmetric cryptographic functions (RSA, ECC) that can beused to sign the hash of the logs before storage. If the IoT device application implementsuser management and authorization, user authenticators (private-public key pairs) canbe securely stored in the SE and used to sign the logs generated by a specific user. Thismight help in the implementation of non-repudiation strategies. EdgeLock SE050 alsosupports hash functions (SHA-224, SHA-256, SHA-384, SHA-512) that can be used togenerate and store the hash of the system logs at regular intervals.

The EdgeLock SE050 Plug&Trust middleware API can be used to integrate this primitivein the industrial IoT solution. The main EdgeLock SE050 Plug&Trust middleware APIfunctions supporting the core use cases of this security primitive are listed below:

• Sign / verify logs: sss_se05x_asymmetric_sign_digest (),sss_se05x_asymmetric_verify_digest (), sss_se05x_asymmetric_sign (),sss_se05x_asymmetric_verify ()

• Generate hash for logs: sss_se05x_digest_one_go ()

The EdgeLock SE050 Plug&Trust middleware also provides a set of demos and codeexamples that might be useful to implement the use cases supported by the SystemEvent Logging security primitive. The relevant examples, along with their location inEdgeLock SE050 Plug&Trust middleware folder structure, are shown below:

• Message hash example: \simw-top\sss\ex\md (see Section 5.2.6 of EdgeLock SE050Plug&Trust middleware documentation)

• ECC signing example: \simw-top\sss\ex\ecc (see Section 5.2.1 of EdgeLock SE050Plug&Trust middleware documentation)

• RSA signing example: \simw-top\sss\ex\rsa (see Section 5.2.2 of EdgeLock SE050Plug&Trust middleware documentation)

Leveraging hashing and signing capabilities provided by EdgeLock SE050 aids inachieving ISA/IEC 62443 4-2 compliance for the requirements listed in Table 13 at thehighest security levels.


CR 2.12.0 Non-repudiation X X X X

CR 2.12.1 Non-repudiation for all users - - - X

CR 3.9.0 Protection of audit information - X X X

EdgeLock SE050 helps achieving CR 3.9.0 and CR 2.12.0 by providing cryptographichash and signature functions that can be used to verify the integrity and authenticity ofthe audit information generated by the IoT system, including system logs. In addition,if proper user authorization is enforced at the application level, EdgeLock SE050 canhelp to achieve CR 2.12.1 by signing logs generated by users with the user credentialssecurely stored in the SE.




4.11 SP11: Secure Encrypted StorageThe security primitive Secure Encrypted Storage clusters those features that allow theuser to securely store data and maintain its integrity. It also includes features to protectthe data confidentiality.

EdgeLock SE050 provides a secure, tamper-resistant hardware secure memory forthe secure storage of device credentials such as keys, identifiers and certificates.EdgeLock SE050 also supports both asymmetric (RSA, ECC) and symmetric (DES,AES) cryptographic algorithms that can be used to encrypt data at rest in the IoT device.EdgeLock SE050 stores encryption keys inside its tamper-resistant secure enclave. Evenif the IoT device is decommissioned, private credentials cannot be extracted from theSE. You can refer to the Secure Provisioning and Decommissioning security primitive formore information.

The EdgeLock SE050 Plug&Trust middleware API can be used to simplify the integrationof the abovementioned use cases in your IoT solution. The main EdgeLock SE050Plug&Trust middleware API functions supporting the core use cases of this securityprimitive are listed below:

• Encrypt/decrypt data at rest: sss_se05x_asymmetric_encrypt (),sss_se05x_asymmetric_decrypt (), sss_se05x_cipher_one_go ()

The EdgeLock SE050 Plug&Trust middleware also provides a set of demos and codeexamples that might be useful to implement the use cases supported by the Secure(Encrypted) Storage security primitive. The relevant examples, along with their location inEdgeLock SE050 Plug&Trust middleware folder structure, are shown below:


Leveraging the encryption and tamper resistance capabilities of EdgeLock SE050 aids inachieving the ISA/IEC 62443-4-2 requirements listed in Table 14 to the highest securitylevel.

Table 14. Requirements supported by SP11 and benefiting from EdgeLock SE050Code Requirement SL1 SL2 SL3 SL4


CR 4.2.0 Information persistence - X X X


EdgeLock SE050 supports CR 4.1.0 by providing a secure, tamper-resistant hardwaresecure memory for storing sensitive credentials such as keys and identifiers. Moreover,symmetric and asymmetric key credentials can be used to encrypt data at rest in theIoT device using any of the supported encryption algorithms. CR 4.3.0 is therefore alsoaccomplished. EdgeLock SE050 also helps achieving CR 4.2.0 since stored data andcredentials can be deleted or disabled before disposing of the IoT device as described inSecure Provisioning and Decommissioning security primitive.

4.12 SP12: Cryptographic Key Generation and InjectionThe cryptographic key generation and injection security primitive clusters those featuresthat allow the user to securely generate cryptographic keys and, optionally, to securelyinject or import them into the IoT device. The implementation may include key exchangeand key agreement support, as well as key derivation schemes.




EdgeLock SE050 natively supports the generation of symmetric (AES, DES) andasymmetric keys (ECC, RSA) directly inside the tamper-resistant, secure environmentprovided by the SE. Private keys will never leave the boundaries of the SE. Optionally,pre-existing keys can also be injected in EdgeLock SE050. EdgeLock SE050 alsosupports key exchange and key agreement algorithms (ECDH, ECDHE) and keyderivation functions (HKDF, PBKDF, Wi-Fi KDF, OPC_UA KDF, PRF) that can be used,for instance, to generate session keys.


• Key creation: sss_se05x_key_store_generate_key ()• Key import / injection: sss_key_store_set_key(), Se05x_API_WriteECKey (),

Se05x_API_WriteRSAKey (), Se05x_API_WriteSymmKey ()• Key agreement: sss_derive_key_dh ()• Key derivation: , sss_derive_key_one_go ()

The EdgeLock SE050 Plug&Trust middleware also provides a set of demos andcode examples that might be useful to implement the use cases supported by theCryptographic Key Generation and Injection security primitive. The relevant examples,along with their location in EdgeLock SE050 Plug&Trust middleware folder structure, areshown below:

• Symmetric AES Encryption Example (key generation):: \simw-top\sss\ex\symmetric(see Section 5.2.3 of EdgeLock SE050 Plug&Trust middleware documentation)

• ECC Signing Example (key generation): \simw-top\sss\ex\ecc (see Section 5.2.1 ofEdgeLock SE050 Plug&Trust middleware documentation)

• RSA Signing Example (key generation): \simw-top\sss\ex\rsa (see Section 5.2.2 ofEdgeLock SE050 Plug&Trust middleware documentation)

• ECDH Key Derivation Example: \simw-top\sss\ex\ecdh (see Section 5.2.7 ofEdgeLock SE050 Plug&Trust middleware documentation)

Leveraging key generation and key derivation capabilities provided by EdgeLock SE050aids in achieving ISA/IEC 62443 4-2 compliance for the requirements listed in Table 15 atthe highest security levels.

Table 15. Requirements supported by SP12 and benefiting from EdgeLock SE050Code Requirement SL1 SL2 SL3 SL4

CR 1.5.0 Authenticator management X X X X




EdgeLock SE050 supports CR 1.5.0 and CR 1.5.1 by providing a secure, tamper-resistant hardware in which keys can be securely generated or injected. EdgeLockSE050 also helps achieving CR 1.8.0 by providing a secure storage for publickeys and certificates. Finally, EdgeLock SE050 supports CR 4.3.0 since it providescryptographically secure key generation capabilities and cryptographic algorithms for keyagreement and key derivation.




4.13 SP13: Cryptographic Key and Certificate StoreThe security primitive Cryptographic Key and Certificate Store clusters those featuresthat allow the user to store key material such as keys and certificates and enforcepolicies on them. The key and certificate store shall provide management functionality forthe key material such as policy management or key material deletion.

EdgeLock SE050 allows you to securely generate and store credentials as secureobjects inside its secure tamper-resistant hardware. Cryptographic operations involvingsecure objects are always performed inside the SE protected environment using thebuilt-in cryptographic functions and algorithms provided by EdgeLock SE050 applet.Key generation capabilities are covered in Cryptographic Key Generation and Injectionsecurity primitive. EdgeLock SE050 also supports access management to credentialsin the form of policies that can be used to specify the operations allowed on a givencredential. EdgeLock SE050 policies can be used, for example, to define if a key can beused for encryption, for signing or both and if a key is read-only or if it can be exported ordeleted.


• Set policy upon object creation / injection: sss_se05x_key_store_generate_key (),sss_se05x_key_store_set_key ()

• Update policy upon object update: sss_se05x_key_store_set_key ()

The EdgeLock SE050 Plug&Trust middleware also provides a set of demos andcode examples that might be useful to implement the use cases supported by theCryptographic Key and Certificate Store security primitive. The relevant examples, alongwith their location in EdgeLock SE050 Plug&Trust middleware folder structure, are shownbelow:

• Using policies for secure objects demo: \simw-top\demos\se05x\se05x_policy (seeSection 5.17 of EdgeLock SE050 Plug&Trust middleware documentation)

Leveraging tamper resistance capabilities and key management functions provided byEdgeLock SE050 aids in achieving ISA/IEC 62443 4-2 compliance for the requirementslisted in Table 16 at the highest security levels.



CR 1.9.1 Hardware security for public key-basedauthentication

- - X X

CR 1.14.1 Hardware security for symmetric key-basedauthentication

- - X X

EdgeLock SE050 inherently supports CR 1.5.1, CR 1.9.1 and CR 1.14.1 since it providesa certified hardware with strong tamper-resistant protection for keys stored in the SE.EdgeLock SE050 supports both symmetric and asymmetric keys. EdgeLock SE050 alsocomes with advanced key management functionalities that allow the user to set policieson key objects to restrict the set of permitted operations on them.




4.14 SP14: Cryptographic OperationThe Cryptographic Operation security primitive clusters those features related withcryptographic functionality such as encryption, decryption, hashing, or signing.Cryptographic operation may include higher-level functionality such as certificateverification, certificate signing, and Certificate Signing Request (CSR) handling.

EdgeLock SE050 is the ideal component to support this primitive since it allows theuser to securely generate and store keys in a protected tamper-resistant environmentand perform cryptographic operations with stored keys using the latest, most securecryptographic algorithms. EdgeLock SE050 supports symmetric encryption algorithms(DES, AES), public-key encryption algorithms using either RSA or ECC with support forNIST, Brainpool, Edwards and Montgomery curves, public-key signing algorithms (RSA,ECDSA, ECDAA, EdDSA), key agreement algorithms (ECDH, ECDHE) and hashing andMAC algorithms (SHA, HMAC, CMAC). For a detailed list of supported algorithms youcan refer to EdgeLock SE050 Data Sheet.


• Encryption and decryption operations: sss_asymmetric_encrypt(),sss_asymmetric_decrypt(), sss_cipher_one_go()

• Hashing operations: sss_se05x_digest_one_go (), Se05x_API_DigestOneShot()• MAC operations: sss_se05x_mac_one_go ()• Sign and verify operations: sss_se05x_asymmetric_sign_digest (),

sss_se05x_asymmetric_verify_digest (), sss_se05x_asymmetric_sign (),sss_se05x_asymmetric_verify (), Se05x_API_RSASign(), Se05x_API_ECDSASign(),Se05x_API_EdDSASign()

• Derive key operations: sss_se05x_derive_key_go ()• Key agreement operations: sss_se05x_derive_key_dh ()

The EdgeLock SE050 Plug&Trust middleware also provides a set of demos andcode examples that might be useful to implement the use cases supported by theCryptographic Operation security primitive. The relevant examples, along with theirlocation in EdgeLock SE050 Plug&Trust middleware folder structure, are shown below:



• HMAC Example: \simw-top\sss\ex\hmac (see Section 5.2.6 of EdgeLock SE050Plug&Trust middleware documentation)



• ECDH Key Derivation Example: \simw-top\sss\ex\ecdh (see Section 5.2.7 ofEdgeLock SE050 Plug&Trust middleware documentation)

EdgeLock SE050 aids in achieving ISA/IEC 62443 4-2 compliance for the requirementslisted in Table 17 at the highest security levels.

https://www.nxp.com/docs/en/data-sheet/SE050-DATASHEET.pdf




Table 17. ISA/IEC 62443-4-2 requirements supported by SP14 and benefitting fromEdgeLock SE050Code Requirement SL1 SL2 SL3 SL4


CR 1.9.0 Strength of public key-based authentication - X X X

CR 1.14.0 Strength of symmetric key-based authentication - X X X




CR 3.4.1 Authenticity of software and information - X X X

CR 3.8.0 Session integrity - X X X

CR 3.9.0 Protection of audit information - X X X

CR 3.14.0 Integrity of boot process X X X X

CR 3.14.1 Authenticity of boot process - X X X



CR 7.3.1 Backup integrity verification - X X X

EdgeLock SE050 supports CR 4.3.0 by implementing all the common cryptographicalgorithms for encryption, signing, hashing, key agreement and key derivation.Cryptographic functions can be applied on keys securely stored in the tamper-resistanthardware of EdgeLock SE050. This allows the user to easily achieve CR 1.9.0 andCR 1.14.0. EdgeLock SE050 cryptographic capabilities help achieving many ISA/IEC62443-4-2 requirements: CR 3.1.0, CR 3.1.1 and CR 3.8.0 for communication security(see Secure Communication Protocols security primitive), CR 3.4.0, CR 3.4.1, CR3.14.0 and 3.14.1 for secure boot and initialization (see Secure Initialization securityprimitive), CR 3.9.0 for protection of audit information (see System Event Loggingsecurity primitive), CR 4.1.0 for protection of personal information (see Protection ofPersonal Information security primitive), CR 7.3.1 for secure backups (see SecureBackup and Recovery security primitive) and CR 1.8.0 for secure storage of public-keycertificates.

4.15 SP15: Secure Onboarding and OffboardingThe security primitive Secure Onboarding and Offboarding clusters those features thatallow IoT devices to authenticate and connect to a local network or to a cloud backend.The IoT device identity should be unique, verifiable and trustworthy so that deviceregistration attempts and any data uploaded to a cloud service can be trusted by theOEM. Usually the cloud backend verifies the device identity using PKI cryptography.Offboarding is the reverse process where the device is released from the network. Thismay be triggered prior to a secure decommissioning.

EdgeLock SE050 is pre-provisioned with device-unique key-pairs and certificatesthat can be used for certificate-based device authentication in the cloud onboardingprocess. Pre-provisioned credentials can then be used to securely establish a mutuallyauthenticated, encrypted connection to the cloud using the TLS protocol as discussed inSecure Communication Protocols security primitive.




The EdgeLock SE050 Plug&Trust middleware provides a set of demos and codeexamples that help in implementing cloud onboarding in all the major cloud serviceplatforms, including AWS, Google, Microsoft and IBM. More information on cloud serviceexamples and how to run them is provided in Section 5.1.3 of the EdgeLock SE050Plug&Trust middleware documentation and in the corresponding application notes (AWSIoT Core, Google Cloud Platform, Microsoft Azure IoT Hub and IBM Watson IoT).

Leveraging pre-provisioned keys and certificates in EdgeLock SE050 aids in achievingthe ISA/IEC 62443-4-2 requirements listed in Table 18 to the highest security level.


EDR/NDR3.12


EDR/NDR3.13


EdgeLock SE050 supports the ISA/IEC 62443 requirements EDR/NDR 3.12 and EDR/NDR 3.13 by providing pre-provisioned keys and certificates that can be used for cloudonboarding in all major cloud platforms.

4.16 SP16: Secure UpdatesThe Secure Updates security primitive clusters functionalities to securely update an IoTdevice in the field. This might encompass updates and patches of firmware, software,applications, and/or the operating system. Secure updates require cryptographicfunctionality to verify their integrity and authenticity. If updates are downloaded from thecloud, a secure communication shall be established beforehand.

EdgeLock SE050 can be used to safely store public keys and certificates that can beused to verify the authenticity of an update before it is executed. This can be achievedusing signature algorithms supported by EdgeLock SE050 to verify the signed hashof an update package. The integrity of the update can then be verified by comparingthe signed hash of the update with the actual hash of the update package. EdgeLockSE050 supports all the common hash algorithms, including SHA, for this purpose.EdgeLock SE050 can also be leveraged to establish a secure TLS channel with the cloudbackend to securely download updates. More information on EdgeLock SE050 securecommunication protocols features can be found in the Secure Communication Protocolssecurity primitive.


• Verify signature of an update: sss_se05x_asymmetric_verify_digest (),sss_se05x_asymmetric_verify ()

• Generate digest of an update: sss_se05x_digest_one_go ()

The EdgeLock SE050 Plug&Trust middleware also provides a set of demos and codeexamples that might be useful to implement the use cases supported by the SecureUpdates security primitive. The relevant examples, along with their location in EdgeLockSE050 Plug&Trust middleware folder structure, are shown below:

https://www.nxp.com/docs/en/application-note/AN12404.pdf


https://www.nxp.com/docs/en/application-note/AN12401-SE050_secure_connection_google_cloud_iot_core.pdf

https://www.nxp.com/docs/en/application-note/AN12402-SE050_secure_connectiom_azure_iot_hub.pdf








Leveraging hashing and signing capabilities of EdgeLock SE050 aids in achieving ISA/IEC 62443 4-2 compliance for the requirements listed in Table 19 at the highest securitylevels.


EDR/NDR2.4.1

Mobile code authenticity check - X X X


CR 3.4.1 Authenticity of software and information - X X X

CR 3.4.2 Automated notification of integrity violations - - X X

EDR/NDR3.10.1

Update authenticity and integrity - X X X

EDR/NDR3.12.0


EDR/NDR3.13.0


EdgeLock SE050 supports EDR/NDR 3.12.0 and EDR/NDR 3.13.0 since it allows theuser to securely provision key-pairs and certificates that can be used to provide a root oftrust for different entities involved in the management and production of the IoT device.EdgeLock SE050 also helps achieving EDR/NDR 2.4.1, CR 3.4.0, CR 3.4.1 and EDR/NDR 3.10.1 since the established root of trust can be used to verify the authenticityof software and updates before they are executed. Pre-computed, signed hashes canbe used to verify the integrity of the executed software. Finally, thanks to its tamper-detection capabilities, EdgeLock SE050 can be used in combination with IoT applicationsto send alerts in case of tampering attempts and in this way fulfil CR 3.4.2 as describedin Anomaly Detection and Reaction security primitive.

5 ISA/IEC 62443-4-2 requirements lookup table

Table 20 maps all the ISA/IEC 62443-4-2 requirements mentioned in Section 4 to therespective security primitives.

Table 20. ISA/IEC 62443-4-2 requirements and security primitives lookup tableFR Req. Description Security primitives

CR 1.2.0 Software process and deviceidentification

SP2: Device attestation

CR 1.2.1 Unique identification and authentication SP2: Device attestation

FR1

CR 1.5.0 Authenticator management SP12: Cryptographic Key Generation and Injection




FR Req. Description Security primitives

CR 1.5.1 Hardware security for authenticators SP1: Anomaly detection and reactionSP4: Protection of personal informationSP12: Cryptographic Key Generation and InjectionSP13: Cryptographic Key and Certificate Store

CR 1.8.0 Public key infrastructure certificates SP8: Secure Communication ProtocolsSP12: Cryptographic Key Generation and InjectionSP14: Cryptographic Operation

CR 1.9.0 Strength of public key-basedauthentication

SP14: Cryptographic Operation

CR 1.9.1 Hardware security for public key basedauthentication

SP1: Anomaly detection and reactionSP13: Cryptographic Key and Certificate Store

CR 1.14.0 Strength of symmetric key basedauthentication

SP14: Cryptographic Operation

CR 1.14.1 Hardware security for symmetric keybased authentication

SP1: Anomaly detection and reactionSP13: Cryptographic Key and Certificate Store

NDR/SAR2.4.1

Mobile code authenticity check SP16: Secure Updates

CR 2.12.0 Non-repudiation SP6: Cryptographic random number generationSP10: System Event Logging

FR2

CR 2.12.1 Non-repudiation for all users SP10: System Event Logging

CR 3.1.0 Communication integrity SP6: Cryptographic random number generationSP8: Secure Communication ProtocolsSP14: Cryptographic Operation

CR 3.1.1 Communication authentication SP6: Cryptographic random number generationSP8: Secure Communication ProtocolsSP14: Cryptographic Operation

CR 3.4.0 Software and information integrity SP9: Secure InitializationSP14: Cryptographic OperationSP16: Secure Updates

CR 3.4.1 Authenticity of software and information SP14: Cryptographic OperationSP16: Secure Updates

CR 3.4.2 Automated notification of integrityviolations

SP1: Anomaly detection and reactionSP16: Secure Updates

CR 3.8.0 Session integrity SP8: Secure Communication ProtocolsSP14: Cryptographic Operation

CR 3.9.0 Protection of audit information SP10: System Event LoggingSP14: Cryptographic Operation

EDR/NDR3.10.1

Update authenticity and integrity SP9: Secure InitializationSP16: Secure Updates

EDR/NDR3.11.0

Physical tamper resistance anddetection

SP1: Anomaly detection and reaction

FR3

EDR/NDR3.11.1

Notification of a tampering attempt SP1: Anomaly detection and reaction




FR Req. Description Security primitives

EDR/NDR3.12.0

Provisioning product supplier roots oftrust

SP5: Secure Provisioning and DecommissioningSP7: Root of TrustSP15: Secure Onboarding and OffboardingSP16: Secure Updates

EDR/NDR3.13.0

Provisioning asset owner roots of trust SP5: Secure Provisioning and DecommissioningSP7: Root of TrustSP15: Secure Onboarding and OffboardingSP16: Secure Updates

EDR/NDR3.14.0

Integrity of the boot process SP9: Secure InitializationSP14: Cryptographic Operation

EDR/NDR3.14.1

Authenticity of the boot process SP9: Secure InitializationSP14: Cryptographic Operation

CR 4.1.0 Information confidentiality SP4: Protection of personal informationSP11: Secure Encrypted StorageSP14: Cryptographic Operation

CR 4.2.0 Information persistence SP5: Secure Provisioning and DecommissioningSP11: Secure Encrypted Storage

FR4

CR 4.3.0 Use of cryptography SP6: Cryptographic random number generationSP8: Secure Communication ProtocolsSP11: Secure Encrypted StorageSP12: Cryptographic Key Generation and InjectionSP14: Cryptographic Operation

FR7 CR 7.3.1 Backup integrity verification SP3: Secure backup and recoverySP14: Cryptographic Operation

6 Glossary

Term Definition

AES Advanced Encryption Standard

CR Component Requirement

DES Data Encryption Standard

ECC Elliptic-curve Cryptography

ECDH Elliptic-curve Diffie-Hellman

ECDHE Elliptic-curve Diffie-Hellman Ephemeral

EDR Embedded Device Requirement

FR Foundational Requirement

HDR Host Device Requirement

HTTP Hypertext Transfer Protocol

IoT Internet of Things

KDF Key Derivation Function

MAC Message Authentication Code




Term Definition

MQTT Message Queuing Telemetry Transport

NDR Network Device Requirement

OEM Original Equipment Manufacturer

OS Operating System

PCR Platform Configuration Register

PKI Public Key Infrastructure

PRNG Pseudo Random Number Generator

SAR Software Application Requirement

SCP Secure Channel Protocol

SE Secure Element

SHA Secure Hash Algorithm

SL Security Level

SP Security Primitive

TLS Transport Layer Security

TRNG True Random Number Generator




7 Legal information

7.1 DefinitionsDraft — The document is a draft version only. The content is still underinternal review and subject to formal approval, which may result inmodifications or additions. NXP Semiconductors does not give anyrepresentations or warranties as to the accuracy or completeness ofinformation included herein and shall have no liability for the consequencesof use of such information.

7.2 DisclaimersLimited warranty and liability — Information in this document is believedto be accurate and reliable. However, NXP Semiconductors does notgive any representations or warranties, expressed or implied, as to theaccuracy or completeness of such information and shall have no liabilityfor the consequences of use of such information. NXP Semiconductorstakes no responsibility for the content in this document if provided by aninformation source outside of NXP Semiconductors. In no event shall NXPSemiconductors be liable for any indirect, incidental, punitive, special orconsequential damages (including - without limitation - lost profits, lostsavings, business interruption, costs related to the removal or replacementof any products or rework charges) whether or not such damages are basedon tort (including negligence), warranty, breach of contract or any otherlegal theory. Notwithstanding any damages that customer might incur forany reason whatsoever, NXP Semiconductors’ aggregate and cumulativeliability towards customer for the products described herein shall be limitedin accordance with the Terms and conditions of commercial sale of NXPSemiconductors.

Right to make changes — NXP Semiconductors reserves the right tomake changes to information published in this document, including withoutlimitation specifications and product descriptions, at any time and withoutnotice. This document supersedes and replaces all information supplied priorto the publication hereof.

Suitability for use — NXP Semiconductors products are not designed,authorized or warranted to be suitable for use in life support, life-critical orsafety-critical systems or equipment, nor in applications where failure ormalfunction of an NXP Semiconductors product can reasonably be expectedto result in personal injury, death or severe property or environmentaldamage. NXP Semiconductors and its suppliers accept no liability forinclusion and/or use of NXP Semiconductors products in such equipment orapplications and therefore such inclusion and/or use is at the customer’s ownrisk.

Applications — Applications that are described herein for any of theseproducts are for illustrative purposes only. NXP Semiconductors makesno representation or warranty that such applications will be suitablefor the specified use without further testing or modification. Customersare responsible for the design and operation of their applications andproducts using NXP Semiconductors products, and NXP Semiconductorsaccepts no liability for any assistance with applications or customer productdesign. It is customer’s sole responsibility to determine whether the NXPSemiconductors product is suitable and fit for the customer’s applicationsand products planned, as well as for the planned application and use of

customer’s third party customer(s). Customers should provide appropriatedesign and operating safeguards to minimize the risks associated withtheir applications and products. NXP Semiconductors does not accept anyliability related to any default, damage, costs or problem which is basedon any weakness or default in the customer’s applications or products, orthe application or use by customer’s third party customer(s). Customer isresponsible for doing all necessary testing for the customer’s applicationsand products using NXP Semiconductors products in order to avoid adefault of the applications and the products or of the application or use bycustomer’s third party customer(s). NXP does not accept any liability in thisrespect.

Export control — This document as well as the item(s) described hereinmay be subject to export control regulations. Export might require a priorauthorization from competent authorities.

Evaluation products — This product is provided on an “as is” and “with allfaults” basis for evaluation purposes only. NXP Semiconductors, its affiliatesand their suppliers expressly disclaim all warranties, whether express,implied or statutory, including but not limited to the implied warranties ofnon-infringement, merchantability and fitness for a particular purpose. Theentire risk as to the quality, or arising out of the use or performance, of thisproduct remains with customer. In no event shall NXP Semiconductors, itsaffiliates or their suppliers be liable to customer for any special, indirect,consequential, punitive or incidental damages (including without limitationdamages for loss of business, business interruption, loss of use, loss ofdata or information, and the like) arising out the use of or inability to usethe product, whether or not based on tort (including negligence), strictliability, breach of contract, breach of warranty or any other theory, even ifadvised of the possibility of such damages. Notwithstanding any damagesthat customer might incur for any reason whatsoever (including withoutlimitation, all damages referenced above and all direct or general damages),the entire liability of NXP Semiconductors, its affiliates and their suppliersand customer’s exclusive remedy for all of the foregoing shall be limited toactual damages incurred by customer based on reasonable reliance up tothe greater of the amount actually paid by customer for the product or fivedollars (US$5.00). The foregoing limitations, exclusions and disclaimersshall apply to the maximum extent permitted by applicable law, even if anyremedy fails of its essential purpose.

Translations — A non-English (translated) version of a document is forreference only. The English version shall prevail in case of any discrepancybetween the translated and English versions.

Security — While NXP Semiconductors has implemented advancedsecurity features, all products may be subject to unidentified vulnerabilities.Customers are responsible for the design and operation of their applicationsand products to reduce the effect of these vulnerabilities on customer’sapplications and products, and NXP Semiconductors accepts no liability forany vulnerability that is discovered. Customers should implement appropriatedesign and operating safeguards to minimize the risks associated with theirapplications and products.

7.3 TrademarksNotice: All referenced brands, product names, service names andtrademarks are the property of their respective owners.




TablesTab. 1. ISA/IEC 62443 security assurance levels ..........4Tab. 2. Component types .............................................. 5Tab. 3. Security primitives definition ..............................7Tab. 4. ISA/IEC 62443-4-2 requirements supported

by SP1 and benefiting from EdgeLockSE050 ................................................................8

Tab. 5. Requirements eased by SP2 and benefitingfrom EdgeLock SE050 .................................... 10

Tab. 6. ISA/IEC 62443-4-2 requirements supportedby SP3 and benefiting from EdgeLockSE050 ..............................................................11








Tab. 14. Requirements supported by SP11 andbenefiting from EdgeLock SE050 ....................19

Tab. 15. Requirements supported by SP12 andbenefiting from EdgeLock SE050 ....................20


Tab. 17. ISA/IEC 62443-4-2 requirements supportedby SP14 and benefitting from EdgeLockSE050 ..............................................................23



Tab. 20. ISA/IEC 62443-4-2 requirements andsecurity primitives lookup table ....................... 25

FiguresFig. 1. ISA/IEC 62443 overview ................................... 4 Fig. 2. Breakdown of a simplified industrial control

system ............................................................... 6


Please be aware that important notices concerning this document and the product(s)described herein, have been included in section 'Legal information'.

© NXP B.V. 2020. All rights reserved.For more information, please visit: http://www.nxp.comFor sales office addresses, please send an email to: [email protected]

Date of release: 16 June 2020Document number: 582810

Contents1 Introduction ......................................................... 32 How to use this document .................................33 ISA/IEC 62443 standard overview ......................34 Leverage EdgeLock SE050 to meet ISA/IEC

62443-4-2 requirements ...................................... 64.1 SP1: Anomaly detection and reaction ................84.2 SP2: Device attestation ..................................... 94.3 SP3: Secure backup and recovery .................. 104.4 SP4: Protection of personal information .......... 114.5 SP5: Secure Provisioning and

Decommissioning .............................................124.6 SP6: Cryptographic random number

generation ........................................................134.7 SP7: Root of Trust ...........................................144.8 SP8: Secure Communication Protocols ...........154.9 SP9: Secure Initialization .................................164.10 SP10: System Event Logging ..........................184.11 SP11: Secure Encrypted Storage ....................194.12 SP12: Cryptographic Key Generation and

Injection ............................................................194.13 SP13: Cryptographic Key and Certificate

Store ................................................................ 214.14 SP14: Cryptographic Operation .......................224.15 SP15: Secure Onboarding and Offboarding .... 234.16 SP16: Secure Updates .................................... 245 ISA/IEC 62443-4-2 requirements lookup

table ....................................................................256 Glossary ............................................................. 277 Legal information ..............................................29

ease isa/iec 62443 compliance with edgelocktm se050 › docs › en › application-note ›...

Documents