Security
Any communications system needs to provide a mechanism to allow communicating partners to trust each other. In large systems, this is typically accomplished by cryptographic protection for individual communications, along with cryptographically secured credentials and a centralized credential management system with responsibility for ensuring that credentials are issued only to parties that are entitled to them. Each credential management system typically has a small number of nodes that serve as trust anchors, which can make statements themselves about the trustworthiness of end entity nodes or delegate the ability to make trust statements to other management nodes.
One typical way of instantiating a credential management system is via public key infrastructure (PKI). For the C-ITS world, the operational scope of a PKI system (referred to in the CVRIA and C-ITS as a Cooperative ITS Credential Management System, or CCMS) can be considered over three axes:
- The geo-spatial area over which CCMS-granted credentials are relevant. This might be a political boundary, but will always be a geographic boundary (though unbound, e.g., all of earth, is possible if unlikely).
- The time domain over which the CCMS operates and CCMS-granted credentials are relevant. While credentials of all types have a valid period from time X1 to time X2, a CCMS operating period, the time during which its functionality and interfaces are active, will be from time Y1 to Y2. While X1 cannot by definition be earlier than Y1, it is possible that X2 would be later than Y2 (in the case of a disaster event for example).
- The application space in which CCMS-granted credentials are used. A given CCMS might supply credentials for only a limited subset of the applications functional at a particular time in a particular geo-political area.
A typical CCMS will consider users of its credentials, aka 'End Entities', according to the state of their credentials. An end entity will move through life cycle stages as processes are performed on the device, and as credentials are granted to it. See the CCMS Physical Object page for a simplified diagram focusing only on the end entity.
If more than one CCMS exist, they are likely to have to interact. In fact, the more CCMS that do exist, the more they will have to interact, as they likely share geographic, political or application-space borders. The HTG6-4 Functional Decomposition Analysis goes into detail about the issues surrounding deployment of multiple CCMS.
Security is about more than credentials however. Devices can be compromised in many ways, and the impacts of those compromises can vary from the annoying to the catastrophic. Various security standardization efforts provide guidelines for managing these concerns. FIPS-199 provides a guiding structure, while NIST 800-53 and ISO/IEC 27001 provide controls and requirements realizing various security levels.
Currently, USDOT efforts around cybersecurity include the establishment of device security classes for Connected Vehicle / Cooperative ITS applications. A device security class is a statement of the security requirements for a device in terms of its requirements for Confidentiality, Integrity, and Availability, expressed as LOW, MODERATE or HIGH ratings for each of the three.
Device security classes are intended to be of use to suppliers of devices and systems for use in C-ITS deployments. A device can only be used to play a role in a particular application if it meets the security requirements of that role; however, higher security requirements will in general translate to more expensive devices. The concept behind the device security class is to develop collections of security requirements which suppliers can develop to, allowing them to provide the most cost-effective solutions that meet the security requirements.
There are currently five physical object device security classes defined:
| Class | Confidentiality | Integrity | Availability |
|---|---|---|---|
| Class 1 | LOW | MODERATE | MODERATE |
| Class 2 | MODERATE | MODERATE | MODERATE |
| Class 3 | MODERATE | HIGH | MODERATE |
| Class 4 | HIGH | HIGH | MODERATE |
| Class 5 | HIGH | HIGH | HIGH |
These device security classes were derived by analyzing the requirements associated with application-constrained information flows, and then combining those flows at device boundaries to determine matching device requirements. While this resulted in roughly one dozen device classes, a more moderate number is desirable to realize economies of scale. While additional classes may be added in the future, these five provide a baseline.
Requirements/controls associated with these device security classes will be linked from here as soon as they are available.
Security analysis has been completed for the following applications: