Why CAVP matters?

• Independent verification and standards compliance
• Assurance that cryptography behaves as intended in deployment
• Confidence for long-term security planning in critical systems

Xiphera’s xQlave® PQC portfolio is built for ASIC and FPGA environments with the highest security requirements over long product lifecycles.

ML-KEM provides systems with quantum-resilient key exchange, and ML-DSA delivers Post-Quantum Digital Signatures to authenticate devices and users, ensuring system integrity. Both are implemented as pure RTL logic design with no hidden software, minimizing the attack surface and supporting predictable execution for demanding use cases.

These hardware-based PQC solutions support a wide range of security-critical industries, including defense, energy, telecommunications, industrial automation and space.

Now is the time to adopt hardware-based security that delivers predictable protection for decades and beyond.

Read more about CAVP Validated Post-Quantum Security.

The QDID PUF generates quantum-derived, secure, unclonable identities based on manufacturing variations unique to each semiconductor chip. The PUF, alongside other cryptographic primitives, forms the essential hardware root-of-trust IP required in security implementations.

nQrux® Hardware Trust Engines offer customisable cryptographic security modules with hardware-level trust and security services for the most critical environments and applications. nQrux IP cores enable full isolation of cryptographic operations and application-specific data into secure hardware elements. Xiphera’s extensive portfolio of cryptographic IP cores includes both traditional cryptographic algorithms, as well as Post-Quantum Cryptography (PQC) fighting against the looming quantum threat.

“Many industrial and governmental entities recommend implementing quantum-resilient hardware solutions to prevent quantum attacks on current and future data. Cryptographic root-of-trust forms the security foundation of modern hardware infrastructures”, said Kimmo Järvinen, co-founder and CTO of Xiphera. “Upgrading these critical components to quantum-resilient algorithms and integrating Crypto Quantique’s PUF technology enables our customers to protect the identities and core security of their hardware devices into the foreseeable future.”

Crypto Quantique’s CEO, Shahram Mossayebi, said, “The combination of nQrux Hardware Trust Engines and QDID provides the adaptability and upgradeability required for the security of connected devices. QDID creates random numbers on demand, so there is no need to store cryptographic keys in flash memory. This eliminates the danger of side-channel memory attacks revealing the keys. In addition, because PQC algorithms have large cryptographic keys, the PUF technology reduces the size of flash memory needed, reducing both power consumption and saving silicon area.”

Learn more about Xiphera’s nQrux® Hardware Trust Engines, and Crypto Quantique’s QDID IP cores.

However, integrity is quite often even a prerequisite for confidentiality in a computer system. Therefore, one should also ask: 

How do I know that the messages I send are received unmodified? 

How do I know that my computing device behaves as intended and is not running some malicious piece of software that leaks all my secrets to an attacker?

In a personal computer, you might run an anti-malware tool that checks programs before execution and flags the program with suspicious traits as malware (such as known features from existing malware), preventing it from being executed. Anti-malware tools are well-established technology and work quite well as soon as they are running – however, the problem is that they are started up relatively late in the system boot cycle. Before anti-malfare tools, a lot of firmware and software are loaded into the system such as boot loaders, boot managers, operating system kernels, drivers, operating systems, and many other applications. Additionally, anti-malware tools do not provide cryptographic guarantees about software legitimacy.

If an attacker is able to inject malicious code in the low-level software components loaded during the system boot, then the game is lost before it even really started – after that point, the attacker may have full control over the computing device, or at least some very critical part of the system. 

What does a secure boot do?

Secure boot refers to a piece of technology that ensures integrity of a computing system during its boot-up process, guaranteeing that a system is booted with firmware and/or software that can be trusted to originate from a known source. More specifically, secure boot ensures that a binary image that is loaded into the system is authentic – that is to say, it has been signed by a legitimate party (for example, the OEM). This is performed by verifying a digital signature, which is attached to the actual firmware/software, by using the legitimate party’s public key.

If secure boot is enabled in a system, then software is allowed to be executed in the system only if it has a digital signature that can be successfully verified. The component that verifies digital signatures and contains the public keys used in those verifications form the root-of-trust for the device. All subsequent trust is derived from this root-of-trust by forming a chain of trust: the root-of-trust verifies a (firmware/software) component, which then itself becomes a trusted component after successful verification and can be used for verifying further components.

What is required from secure boot?

The component that performs the secure boot must be trustworthy. It must be impossible for an attacker to modify the verification process or the public keys which are used in the verification process. In other words, the component must be tamper-proof. 

In order to guarantee the immutability, it is often preferred to use a hardware root-of-trust: a tamper-proof hardware component, that can be used in secure boot for performing the verification and one-time programmable memories for public key storage. It is good to understand that sometimes the hardware root-of-trust may support other operations besides those needed in secure boot – hence, it can be used for other cryptographic services as well even during runtime.

One nice feature of secure boot with digital signatures is that the device where the authentication (secure boot) is performed does not need to include any cryptographic secrets, but only public keys. Because of this lack of secrets, the device is a much harder target for attacks. A successful attack would need to manipulate either the functionality of the digital hardware component or replace the public key with a malicious one, both of which are extremely difficult tasks to succeed due to the immutable nature of hardware. Moreover, even if an attacker is able to hack one device as a result of a difficult and laborious physical attack, they have not recovered any information (such as a secret key) that would automatically compromise similar devices. Importantly, the lack of secrets also means that they are not targets for side-channel attacks.

What if also the confidentiality of firmware must be protected?

Every now and then, there may be good reasons to protect both integrity (authenticity) and confidentiality of programs in secure boot; for example, when a firmware/software includes critical intellectual property or hardcoded cryptographic secrets. Good examples are configuration bit files for FPGAs which are typically protected for both confidentiality and authenticity. 

In such cases, the aforementioned protection of integrity is not sufficient and actual encryption is required. It is possible to use symmetric encryption combined with message authentication (for example, AES + HMAC) or an authenticated encryption scheme (for example, AES-GCM).

However, in symmetric encryption, the decryption requires cryptographic secrets to be included in the secure boot component, consequently making the device a target for various implementation attacks including side-channel attacks. It is also seldom economically feasible to use a unique key for all devices of a product family (and thus a different firmware image for all of them), so cracking the secrets out of one device typically breaks a large number of similar devices. For this reason, it may be a good idea to use the secret symmetric key only for encryption/decryption (confidentiality protection), where it cannot be avoided, and still use digital signatures and public keys for the integrity protection – then, integrity protection is preserved even if the secret key is leaked from a device.

For more information about secure boot, visit the page for Xiphera’s quantum-resistant nQrux® Secure Boot.

WEBINAR: Quantum-Resilient Secure Boot – Building Trust from Power-up

The trust in a computing platform’s operation is established during its power-up. If this boot sequence is not secured, the entire computing platform may be compromised.

In the webinar Quantum-Resilient Secure Boot – Building Trust from Power-up, part of the webinar series Cryptography Under the Hood, we review how hardware-based cryptographic mechanisms can be used to secure the boot process of a computing platform. We will discover how to secure the confidentiality, integrity, and authenticity of the boot process with post-quantum secure boot.

Watch recording.

Secure boot provides assurance of functional integrity, a critical step for establishing trust in any computing system in operation. Xiphera’s nQrux® Secure Boot verifies digital signatures attached to the binary image loaded into a computing system, preventing malicious actors from injecting their own code into the system and ensuring trust in the system.

nQrux® Secure Boot uses a hybrid signature scheme consisting of ECDSA, a traditional digital signature scheme based on elliptic curves, and new quantum-secure signature scheme ML-DSA, both standardised by the American National Institute of Standards and Technology (NIST). The hybrid solution ensures system security even if quantum computers break ECDSA in the future, or if a weakness is identified in the new ML-DSA standard. nQrux® Secure Boot is based on pure digital logic and does not include any hidden software components, providing first-class security and easier validation and certification.

“Secure boot is a fundamental requirement in creating trust in computing systems,” says Kimmo Järvinen, co-founder and CTO of Xiphera. “nQrux® Secure Boot is a valuable addition to our product family for hardware trust engines. It combines standardised cutting-edge Post-Quantum Cryptography with Xiphera’s pure hardware-based digital design”.

nQrux® Secure Boot is delivered as a device and process node agnostic IP core, easily integrated across FPGA and ASIC architectures. The IP core will be available for customer evaluations in Q4/2024.

For more information on the technical features, send us a message. 

Post-quantum cryptography (PQC) answers to the imminent quantum threat. PQC algorithms are implemented on traditional computational platforms, but they withstand both traditional and quantum attacks. Implementing PQC already today is crucial for everyone, but its importance is emphasised especially in long lifecycle applications e.g. in industrial and automotive industries.

Xiphera’s xQlave® family of Post-Quantum Cryptography consists of fully hardware-based PQC IP cores, designed to withstand quantum attacks and implemented without any software components. The xQlave® family includes IP cores for ML-KEM (previously CRYSTALS-Kyber) Key Encapsulation Mechanism and ML-DSA (previously CRYSTALS-Dilithium) Digital Signature algorithms.  The IP cores comply with the standardisation of PQC algorithms by the American National Institute of Standards and Technology (NIST).

To learn more about Post-Quantum Cryptography, visit Xiphera’s xQlave® PQC family page.

The nQrux™ CCE solution is customised to include various types of computing resources including CPU cores and specific accelerators, for example, for AI. Data and code are remotely uploaded over a protected communication channel to be processed securely in the CCE. Additionally, the CCE solution includes a feature where client nodes can be categorised into groups with different access rights to the resources of the CCE – for instance, one client can provide AI models for an embedded AI accelerator inside the CCE, the other clients (such as sensors) can upload data to be processed in the AI computation, while a third client may have the right to access the result of the AI computation.

Communication of data and code to the nQrux™ CCE is protected with hardware-based implementation of TLS 1.3. Access policies are enforced with hardware isolation of resources and with client-authentication of TLS 1.3, so that only clients with appropriate certificates are allowed to access (write and/or read) specific resources.

“The new CCE core provides uniquely tailored solutions, to protect for example AI or other code in remote environments such as Edge, cloud, and satellites”, says Petri Jehkonen, Xiphera’s Director of Strategic Programs. “The computing elements, such as RISC-V or AI accelerators, are physically and cryptographically isolated from the rest of the system, mitigating CPU or cache vulnerabilities, while offering flexibility to use general purpose programming languages with security related processing tasks.”

For more information, visit the product page of Confidential Computing Engine (CCE) and the family page of nQrux™ Hardware Trust Engines. With any additional questions and inquires, contact us directly.

WEBINAR – Fortifying Digital Resilience: Security Foundations for IoT, AI, and Cloud Systems

Ensuring digital resilience requires certain security elements from the underlying foundations of hardware infrastructures, software platforms, and digital identities. The specific needs and requirements for these elements vary across different industries and customer environments, making the customisability of cryptographic solutions essential.

This webinar reviews the challenges and practical building blocks for strengthening digital resilience within modern IoT, Cloud, and AI environments.

Watch the recording.

Securing data and communications, within and between microcontrollers, System on Chip implementations, and other systems, requires a range of cryptographic operations. These services include hash functions for ensuring data integrity, symmetric encryption for encrypting bulk data in transit or at rest, asymmetric encryption for key exchange, signing data and messages, as well as authenticating components, users, and accounts, and finally a source of quality randomness for cryptographic key generation.

Implementing all of these securely and in an optimised manner for a hardware platform requires in-depth skills and understanding of both cryptography and digital design for microcircuits. The various cryptographic services can be implemented, and are typically offered, as distinct IP cores dedicated to a single specified cryptographic algorithm. Additional logic and integration will need to be implemented around these IP cores to facilitate the necessary cryptographic operations and processes required by the surrounding total solution. Complexity of the system increases attack surface and the risk of design flaws and security vulnerabilities. 

For these reasons, critical security services are often segregated into a single cryptographic module, behind a unified and well-defined interface for access by the rest of the system. This introduces a cryptographic boundary, which isolates security critical operations from the rest of the system. 

Implementing cryptographic modules securely (today and tomorrow)

In designing a cryptographic module, it is critical to ensure that the module architecture is efficient, to limit access behind a unified, well-defined, and secure interface, and to minimise total attack surface. Module composition (selection of the provided security services, algorithms, and key lengths), as well as the optimisation of the implementation (area vs. performance), can be done according to system and industry requirements (e.g. for IoT, industrial, data centre, hyperscaler, telecommunications, space, or automotive use). 

The most secure and efficient way to implement a cryptographic module for hardware is to ensure it is directly designed in hardware as digital logic. This method removes dependency on a multi-layered software technology stack with increased attack surface and potential for design flaws and vulnerabilities. Avoiding embedded CPU and its software components has benefits for performance and power consumption – and most critically, for security. Streamlining the architecture, defining a clear cryptographic boundary, and removing software and CPU components from the design also enable more straightforward and cost-effective validation and certification processes.

Hardware solution security needs to be ensured throughout the whole solution life-cycle, from implementation until the decommissioning. This life-cycle can in some cases last for several decades. The rapid development of quantum computers has raised future threat for the eventual shattering of the security of the infrastructures that our daily digital lives, businesses, and democratic societies rely on. That is why hardware solutions designed and implemented today already need to, at the very minimum, have the capability to be upgraded to Post-Quantum Cryptography (PQC), or to already complement traditional asymmetric algorithms with PQC into a hybrid cryptographic system. Cryptographic modules should be designed to offer quantum-safe key exchange and digital signature operations, that ensure the security of our critical and personal information well into the foreseeable future. Read more about the quantum threat and Post-Quantum Cryptography.

Where are cryptographic modules used?

A hardware-based cryptographic module has multiple use cases, as it can be easily integrated to various systems for the purpose of offloading and accelerating cryptographic operations, and to act as a cryptographic coprocessor for System on Chips or to power secure communication between a microcontroller and other components. 

Cryptographic modules can be used, for example, in a modern automotive system to authenticate and secure communications between various components, such as LIDAR and the Electronic Control Unit. They can also be implemented as the security core in an Authenticated or Secure Boot solution, to ensure the authenticity, integrity, and optionally confidentiality of the system boot image loaded during boot process. Adding secure key generation, storage, and management enables the implementation of a Hardware Root of Trust or a Hardware Security Module – the foundation of trust and security – in a hardware system. 

Cryptographic modules are the beating heart of a hardware security system, and it is crucial to ensure they are implemented in the most secure and clean design possible. They offer a cost-effective and proven way to implement system security, enabling a design team to focus on the value-add functionality of the end product, without getting bogged down in the intricacies of cryptographic algorithms. 

Learn more about cryptographic modules and Xiphera’s nQrux™ Crypto Module. The nQrux™ Crypto Module is tailored to meet specific customer security, performance, and area requirements for an optimal solution to implementing cryptographic operations in a hardware device. 

nQrux™ Hardware Trust Engines introduce novel security architectures, delivering hardware-level trust for the most critical environments and applications. The solutions in the nQrux™ portfolio ensure the complete isolation of cryptographic operations and application-specific data within inherently secure hardware elements. This enables the freedom from embedded CPUs or software elements, enabling paramount security and performance levels.

“We are thrilled to launch nQrux™, a family that collects Xiphera’s solutions for building larger system-level security”, Kimmo Järvinen, Xiphera’s co-founder and CTO, comments.

The nQrux™ family consists of cryptographic security solutions built on Xiphera’s cryptographic IP cores that are fully standard compliant (IEEE, IETF, NIST), and CAVP validated by NIST. The solutions in the nQrux™ portfolio have optimised configurations based on customer footprint, performance, and security requirements. Xiphera’s Crypto Module provides an integrated security platform with customer-tailored set of highly optimised cryptographic services for microcontrollers and SoC implementations. The versatile configurations of Xiphera Crypto Module enable fully optimised feature set to fit customer requirements for functionality, performance, and resources.

With the launch of the nQrux™ family, Xiphera announces Confidential Computing Engines (CCE) as part of the nQrux™ family of Hardware Trust Engines. The CCE offer a secure code execution environment protecting data, code, and AI models in cloud, edge, and AI environments. “CCE is our first opening in the domain of trusted computing where hardware-based cryptography and isolation are used for building trust in remote computation”, Kimmo Järvinen concludes. Xiphera’s CCE will be ready for customer evaluation in 2024.

Read more about the nQrux™ family of Hardware Trust Engines.

About Xiphera 

Xiphera, Ltd, designs and implements proven cryptographic security for embedded systems. Our strong cryptographic expertise and extensive experience in digital system design enable us to help our customers to protect their most valuable assets.

We offer secure and highly optimised cryptographic Intellectual Property (IP) cores, designed directly for Field Programmable Gate Arrays (FPGAs) and Application Specific Integrated Circuits (ASICs) without software components. Our broad, fully in-house designed, and up-to-date portfolio, including implementations of Post-Quantum Cryptography, enables cost-effective development projects with fast time-to-market – providing peace of mind in a dangerous world.

Media contacts

Mimmi Kuusisaari
Marketing and Communications Coordinator
marketing(at)xiphera.com

IPsec protocol is widely used in various operating systems and network devices. It is most commonly used to secure communications in Virtual Private Networks (VPNs) over the Internet. Today’s hybrid and remote work environments are an excellent example of the importance of secure communications – IPsec secures network-to-network communications e.g. between sites, data centers, and businesses.

Xiphera’s extreme-speed IPsec IP core implements the ESP (Encapsulating Security Payload) frame processing of the IPsec protocol, using Xiphera’s own AES256-GCM IP core as its crypto engine to protect data confidentiality and integrity as well as data origin authentication. The IPsec core achieves a throughput exceeding 200 Gigabits per second (Gbps) in modern high-end FPGAs and ASICs, making it an excellent solution to secure traffic on links from 10 to 200 Gbps.

“Our IPsec offers scalable solution to meet the needed performance requirements by achieving full throughput with wanted linerate despite packet sizes. Latency of the IP is fixed, which is vital for timing critical applications”, says Tuomo Tarvainen, Xiphera’s System Architect.

For more information, visit the IPsec product page, or open the full product brief.

To learn more about how to secure your device communications with Xiphera’s Security Protocols – MACsec, IPsec, and TLS 1.3 – watch our webinar Cryptography at Work: Securing Device Communications.

OSI model – what and why?

Open System Interconnection (OSI) model introduces the seven layers for device communications. It was developed in the 1980s for a standardised process of communications between different manufacturer’s computers (for example, between Windows and MacBook computers). Today, the OSI model can be implemented on two-way data flow between any devices. In the seven layers of the OSI model, the transmitted data goes from layer 7 to layer 1, gets transmitted via physical network (for example, through LAN, WLAN, Bluetooth, 5G, optical cable, etc.), and then at the receiving end, flows from layer 1 to 7 and finally to the receiving device/user. 

In the real world, the data does not always follow precisely the seven layers of the OSI model. Today, many network communications use TCP/IP protocol (Transmission Control Protocol / Internet Protocol), where the protocol’s fewer layers compared to the OSI model are not as formally defined.

Seven layers of OSI model

OSI model introduces the following layers for the transmitted data flow: 

1. Physical layer, covering physical hardware elements such as cables, connectors, or network interface cards.
2. Data Link layer, offering point-to-point communication between devices over network and managing access to the Physical layer; the most common example is Ethernet.
3. Network layer, determining the best path for data to be transmitted between devices across multiple networks, typically using IP addresses.
4. Transport layer, ensuring data integrity through end-to-end communication by segmenting data into smaller units.
5. Session layer, creating and managing connections, or sessions, between applications.
6. Presentation layer, ensuring data flow between the Session and Application layers to make the data usable for the topmost layer.
7. Application layer, utilised by the end user, serving as the interface between network and user software (such as email, remote login, file transfer, web browser, etc.).

It is important to notice that the commonly implemented TCP/IP model introduces typically only 4 to 5 layers. These layers, however, follow a very similar pattern to the layers presented in the OSI model – the Transport, Internet, and Link or Network layers of the TCP/IP are in principle equivalent to the OSI model’s Transport (4), Network (3), and Data Link + Physical (1-2) layers, respectively, and the Application layer of the TCP/IP model covers the layers 5-7 (Session, Presentation, Application) layers of the OSI model.

How to secure data in the OSI model?

How can we be sure that the data transmitted to the receiving end has not been tampered with during its long and multi-phased journey from OSI layers 7 to 1 and back to 7? This is obviously a critical question in our contemporary world of cyber threats. During the first phase of both OSI and TCP/IP work data security and privacy were not taken into consideration, and the required security protocols were developed afterwards.

Naturally, like every communication, the data in the OSI model needs to be secured throughout its journey. Some layers are more prone to external threats than others. For example, the Application layer (7) of the OSI model is handled directly with end-user applications and services, making it a usual target for various cyber threats.

Layers 2 to 4 (Data Link, Network, Transport), being close to the network interface, are also critical to secure. The Data Link layer (layer 2) plays a pivotal role in defining secure communication between directly connected network devices. By securing the Data Link layer, we can affect the overall security of the network, by ensuring data integrity, preventing unauthorised access, and enhancing network performance. Data Link layer can be secured for example with MACsec (Media Access Control security), a point-to-point Ethernet security protocol, protecting both confidentiality and integrity of transmitted data.

The Network layer (3), being responsible for forwarding data between networks, is essential to secure for ensuring proper routing and IP address management, preventing unauthorised access or network attacks. A well-established security solution for the Network layer is IPsec (Internet Protocol security), securing IP (Internet Protocol) traffic by authenticating and encrypting IP packets within a communication session. IPsec is a widely used security protocol, and its importance in today’s hybrid work environment has increased with growing demand to secure the communications from e.g. our home offices.

The Transport layer (4) covers end-to-end communication, and maintaining the layer’s confidentiality, integrity, and authenticity is critical for ensuring secure communication. Securing the Transport layer guarantees that the transmitted data has not been corrupted or modified by unauthorised or unwanted parties. TLS (Transport Layer Security)protocol provides protection against these threats. The most recent version, TLS 1.3, establishes a secure connection between a client and a server over the Internet, thus securing both endpoints of the session.

Like the OSI model, these security protocols are constantly reviewed and standardised. Various international bodies, first and foremost IEEE (Institute of Electrical and Electronics Engineers) and the Internet community with their RFCs (Request for Comments) ensure that the security protocols used for protecting communications in the OSI model are up-to-date.

Securing OSI model with hardware-based security

To conclude, securing data flow in the OSI model is critical. The decision of which layers to secure depends on the context and specific security goals of the network. Nevertheless, it is important to always secure at least one layer of the OSI model.

Typically, enabling security for the layers 2, 3, and/or 4 of the OSI model ensures a high-security level of the communications. These layers, being close to the network interface, can be effectively secured with hardware-based security solution, such as MACsec, IPsec, and TLS 1.3 security protocols introduced above.

Hardware-based security, using cryptographic IP (Intellectual Property) cores, has several advantages compared to the software-based security approach. These include for example, higher security level, better performance and higher throughput for the applications, and lower power consumption than what would be achieved with a software-based security implementation. 

Xiphera offers hardware-based security with cryptographic IP cores. Our extensive security portfolio covers security designs based on modern and standardised implementations of cryptographic algorithms directly into FPGAs and ASICs. Our Security Protocols family includes security solutions – MACsec, IPsec, and TLS 1.3 – for the most critical layers of the OSI model. These security protocols are typically implemented in conjunction with the commonly used TCP/IP protocol.

To learn more about how to secure your device communications with MACsec, IPsec, and TLS 1.3 – the three musketeers of Security Protocols protecting OSI model layers 2-4 – watch our webinar Cryptography at Work: Securing Device Communications.