Standard Services: Confidentiality, Integrity, Authenticity
The standard cryptographic services are confidentiality, integrity, and authenticity. They are provided by the cryptographic mechanisms of encryption and authentication. Two fictional people, Alice and Bob, are used in the following descriptions to help simplify the explanations.
Confidentiality means that when Alice sends a message to Bob, she knows that no one can learn anything (except its length) about the message in transit. Confidentiality is provided by encryption.
Integrity means that when Alice sends a message to Bob, she knows that if the message is altered in transit, Bob will be able to detect that the message has been modified; this provides a deterrent to an attacker who may want to modify the message.
Authenticity means that when Alice sends a message to Bob, she knows that Bob can be certain that the message actually came from her.
Authenticity and integrity are typically provided together (authenticity is of little use without integrity) by authentication.
Cryptographic mechanisms allow Alice and Bob to leverage a small amount of secure information into a large amount of secure data. This small amount of information is a key. For confidentiality, Alice uses a key to encrypt the data and Bob uses a related key to decrypt the data. For authentication, Alice uses a key to apply an authentication code to the data, and Bob uses a related key to check that the code is valid. Although a great deal of attention is paid to particular encryption algorithms (such as the algorithm by Rivest, Shamir, and Adleman (RSA), the advanced encryption standard (AES), and so on), real-life key management is a much more difficult problem than choosing a cryptographic algorithm, and many more weaknesses are caused in systems by poor key management than by a poor choice of cryptographic algorithm.
Privacy
A main goal of the SCMS is to protect the privacy of drivers. This means that it should provide the following services:
- Anonymity: A message should contain no information that explicitly identifies the driver, the passengers, or the vehicle.
- Unlinkability: It should be difficult for an eavesdropper to track a driver or vehicle by recording its BSM transmissions.
Unlinkability is not a binary property of the system. For example, an eavesdropper who is able to record all messages sent by a vehicle will be able to track that vehicle by constructing the path indicated by that vehicle’s BSMs. However, it is a design goal that the V2V communications system does not increase the risk that an individual may be tracked.
For purposes of this report, the requirement is that if a vehicle’s messages contain data that is unique to the vehicle, the data should change frequently such that it is extremely difficult for an eavesdropper to track that vehicle. This in turn means that:
- Any application identifiers should change frequently. This is supported in the TemporaryID field in the BSM.
- Any network identifiers, such as source Media Access Control (MAC) addresses, should change frequently. This is permitted by IEEE Standard 802.11 and actively supported by service primitives in IEEE Standard 1609.4.
- Any cryptographic information unique to the vehicle should change frequently. As discussed below, messages in the system are authenticated by signing them with digital certificates, which are issued by a certificate authority (CA). To meet the requirement, a device must either have multiple digital certificates, or share its certificate with other vehicles. Previous research has concluded that shared certificates are not viable (cf. e.g., Jason J. Haas, Yih-Chun Hu, and Kenneth P. Laberteaux. The Impact of Key Assignment on VANET Privacy. Security and Communication Networks. 3(2):233-249, John Wiley & Sons, Ltd., March 2010). Only the case where each device has multiple certificates is considered in this system.
- All identifier changes should be synchronized: if one identifier does not change between observations, the attacker can link even if all other identifiers change.
- The vehicle’s privacy should be preserved even if the attacker has inside information from one of the SCMS components.
However, in addition to supporting privacy, the system design has to support identification of misbehaving devices in order to remove them from the system. These two goals are fundamentally in contradiction. This SCMS design allows identification of devices for misbehavior detection purposes only through a series of defined interactions between SCMS components. No individual SCMS component can identify a device, and the information revealed to any SCMS component can be controlled.
The Vehicle Infrastructure Integration Consortium (VIIC) provides a full discussion of the policy requirements arising from this high-level requirement for privacy-by-design.