Overview and Goals

This document describes hardware, software, and operating system security for systems that run DSRC applications and use cryptographic private keys and certificates in the format specified by IEEE Standard 1609.2-2016 and that are issued by the Security Credentials Management System (SCMS).

The security requirements apply to two logically distinct sets of functional blocks:

• Privileged applications: These applications run autonomously (i.e., do not require human intervention to start running) and either send or receive signed messages. They run on the host processor.
• Cryptographic operations: These operations use secret keys from symmetric cryptographic algorithms, or private keys from asymmetric cryptographic algorithms. They run on the Hardware Security Module (HSM).

The goals of these requirements are:

1. Different privileged applications can have different sets of keys such that:
   1. A privileged application is able to sign with its own keys
   2. A privileged application is not able to sign with keys reserved for use by a different privileged application
   3. Non-privileged applications do not have any access to keys that are reserved for use by privileged applications
2. No application has read access to key material – all key material is execute- or write-only
3. Keys used for verification are protected against unauthorized replacement
4. The system supports software/firmware update in such a way that the above properties continue to hold

This document does not address processes for certifying that systems meet the requirements. Its purpose is simply to state the requirements.

Architecture

The requirements below cover three architectures.

• Integrated architecture: The host processor and the HSM are the same processor
• Connected architecture: The host processor and the HSM are different, but they are physically connected using a connector that connects only those two processors. The only way to read or write data flowing between the two processors is by physically tapping into that connector.
• Networked architecture: The host processor and the HSM are different and connected over a network or bus that has other processors connected to it

The document provides requirements for the host processor and the HSM separately and then provides architecture-specific requirements for the different architectures.

Host Processor

Manufacturing and Operational States

The host processor and its software shall be delivered in an operational state that implements all the protections below.

The host processor may be initialized while in a manufacturing state that does not implement all the protections.

A device may be designed so it can return from the operational state to the manufacturing state. If this functionality is provided, the transition shall wipe all privileged applications from the host processor and all keys from the HSM. The device may allow a user to perform a reset to a manufacturing state without any authentication if the mechanism for a reset guarantees that the user is physically present.

Secure Boot

The host processor shall perform integrity checks on boot to ensure that it is in a known good software state. The integrity checks shall require the use of a hardware-protected value such that the integrity cannot be successfully compromised unless the hardware-protected value is modified. Examples of these integrity checks include signing the software such that the verification key is protected by hardware, or storing hashes via the Platform Configuration Registry (PCR) mechanism of the Trusted Computing Group's (TCG) Trusted Platform Module (TPM).
The host processor integrity check shall verify the software and firmware configuration of the host processor such that:

• The host processor shall not allow any privileged application to sign until the integrity checks have passed
• If the host processor fails the integrity checks, it shall not grant access for any process to private keys
• If the host processor fails the integrity checks, it shall not allow any privileged application to operate

The host processor integrity check shall carry out a check that stored root CA certificates have not been modified since they were last accessed.

• If this integrity check fails, the device shall reject all incoming signed messages that chain back to those root CA certificates as invalid.

Operating System

The host processor operating system shall meet the following requirements (derived from FIPS 140-2 section 4.6.1):

• The operating system shall support roles, which are used as specified below. Each privileged application shall map to a role.
• The discretionary access control mechanisms of the operating system shall be configured to:
  • Specify the set of roles that has execute permissions on each private key stored within the HSM
  • Specify the set of roles that can modify (i.e., write, replace, and delete) programs and plaintext data stored at specific locations within the host processor boundary
  • Specify the set of roles that can read data stored within the host processor boundary and what data can be read by those roles
  • Specify the set of roles that can enter cryptographic keys (It is permissible for the host to require that all keys are generated on the device and that keys cannot be entered directly)
• The OS shall allow the following roles to operate without explicit authentication by a user:
  • Processes that correspond to privileged applications, i.e., applications that are intended to run without user initiation or intervention, and that have execute access to private keys
  • Processes that update private key material to the HSM, i.e., to implement the butterfly key process specified within the SCMS documentation
• The OS may allow the following roles to operate without explicit authentication or may require authentication:
  • Processes that install new software or firmware if that software or firmware is signed
  • Processes that write private key material to the HSM (It is permissible for the host to require that all keys are generated on the device and that keys cannot be entered directly)
• The OS may support the following roles and, if it supports them, shall require explicit authentication:
  • Processes that modify or inspect executing processes
• The OS shall not allow the following roles to exist:
  • Processes that read private cryptographic key material from the HSM (NOTE: The HSM as well must not provide this functionality)

Secure Updates

The host processor shall use the following mechanisms to ensure that its software and firmware can be securely updated:

• The host processor requires that all software installed be signed. When requested to install software, the host processor OS ensures that the software is signed by an authority with appropriate permissions before proceeding with the installation and rejects the installation if the signature or any of the validity checks on the software or its signing certificate fail.
  • If this approach is taken, the integrity of the verification key shall be protected by local hardware, either by directly storing the key in local hardware, or by creating a chain of trust from the key to a hardware-protected key. The hardware protection shall be equivalent to FIPS 140-2 at the level appropriate to the device as a whole.
• In addition, the host processor may require that only an authenticated user can install software.

The update mechanism shall include mechanisms to prevent updates being rolled back.

HSM

The HSM shall meet the requirements for an operating system given in FIPS 140-2 Level 2 except for the audit requirements and certain additional exceptions. The baseline requirements are the following:

• All cryptographic software and firmware shall be developed and installed in a form that protects the software and firmware source and executable code from unauthorized disclosure and modification
• A cryptographic mechanism using an approved integrity technique (e.g., an approved message authentication code or digital signature algorithm) shall be applied to all cryptographic software and firmware components within the HSM
  
  • The message authentication code may be used in the following circumstances only:
    • If the HSM itself calculates the MAC when the software is installed using a secret key known only to the HSM and uses this secret key to verify the software on boot
    • If the software or firmware provider has a unique shared key with each distinct device and uses this to authenticate the software

A Message Authentication Code (MAC) may not be used to protect the software unless the MAC key is unique to the HSM.

• All cryptographic software and firmware, cryptographic keys, and control and status information shall be under the control of an operating system that meets the functional requirements specified in the protection profiles listed in FIPS 140-2 Annex B and is capable of evaluation at the CC evaluation assurance level EAL2, or an equivalent trusted operating system
• To protect plaintext data, cryptographic software and firmware, cryptographic keys, and authentication data, the discretionary access control mechanisms of the operating system shall be configured to:
  • Specify the set of roles that can execute stored cryptographic software and firmware
  • Specify the set of roles that can modify (i.e., write, replace, and delete) the following cryptographic module software or firmware components stored within the cryptographic boundary: cryptographic programs, cryptographic data (e.g., cryptographic keys and audit data), and plaintext data
  • Specify the set of roles that can read the following cryptographic software components stored within the cryptographic boundary: cryptographic data (e.g., cryptographic keys and audit data), and plaintext data
  • Specify the set of roles that can enter cryptographic keys

• The discretionary access control mechanisms may allow a role without explicit authorization to create a new cryptographic key by combining an existing key with new input if the device follows the Integrated or Connected Architectures. The discretionary access control mechanisms shall require explicit authorization to create a new cryptographic key by combining an existing key with new input if the device follows the Networked Architecture.

• The discretionary access control mechanisms may allow a role without explicit authorization to execute stored cryptographic software and firmware if the device follows the Integrated or Connected Architectures. The discretionary access control mechanisms shall require explicit authorization to execute stored cryptographic software and firmware if the device follows the Networked Architecture.

• The discretionary access control mechanisms of the OS may allow automated software and firmware update if that update is carried out by a process that includes cryptographic checks to ensure the validity of the update prior to installation.

• The operating system shall prevent all operators and executing processes from modifying executing cryptographic processes (i.e., loaded and executing cryptographic program images). In this case, executing processes refer to all non-operating system processes (i.e., operator-initiated), cryptographic or not.

• The operating system shall prevent operators and executing processes from reading cryptographic software stored within the cryptographic boundary.

Hardware Protection

A HSM that requires low confidentiality and medium integrity shall store keys in tamper-evident hardware equivalent to FIPS 140-2 level 2.

A HSM that requires medium confidentiality and medium integrity shall store keys in tamper-evident hardware equivalent to FIPS 140-2 level 3.

Random Number Generator

An HSM shall use a random number generator from the list of approved random number generators in FIPS 140-2 Annex C.

Architecture-specific Requirements

Integrated Architecture

An integrated processor has no additional requirements beyond the ones identified above.

Connected Architecture

A connected processor has no additional requirements beyond the ones identified above.

Networked Architecture

In addition to the requirements identified above, the host processor must authenticate itself to the HSM with an authentication mechanism based in hardware with the same physical security level as the HSM itself.