There are two different types of keyed cryptographic algorithms, which use very different types of key management. This section discusses those keyed algorithms and also two other important cryptographic primitives, hash functions and random number.
Symmetric Algorithms
In a symmetric algorithm, the sender and receiver use the same key (or keys that are related to each other in some trivial-to-derive way). Alice uses k1 to encrypt; Bob uses k1 to decrypt. Alice uses k2 to authenticate; Bob uses k2 to validate. Symmetric algorithms have two significant properties:
- They are fast (which translates into implementations being low cost). For example, AES, a symmetric encryption algorithm, can encrypt 81 MB per second on a 2 GHz processor, or generate authentication codes on 1,000,000 messages per second with a size of 100 bytes per message.
- They require secure, private key exchange. Before Alice and Bob can use a key k to communicate, they must securely agree on k in such a way that no other party (except perhaps a trusted center) knows k. This means that Alice and Bob must have some kind of pre-existing relationship to use symmetric cryptography.
- NOTE: In a vehicular setting, vehicles are often encountering each other for the first time and do not have a pre-existing relationship. This is one of the main reasons why symmetric key cryptography is not being considered for use in authenticating V2V safety messages.
Public Key Algorithms
In an asymmetric or public key algorithm, the encryption and decryption, or authentication and validation, keys come as a pair, Pub and Priv, with the property that they are related but that it is very expensive (in terms of computer time) for someone who only knows Pub to work out Priv. Pub is called the public key. Priv is called the private key. The private key is not widely shared and usually known only to the key owner; the public key can be distributed widely. They are used this way:
- For confidentiality: Alice uses Bob’s (note, not Alice’s) public key to encrypt the message. Only Bob knows his own private key, so only Bob can decrypt the message.
- For authentication: Alice uses her own private key to generate the authentication code – for a public key algorithm, this is called signing. Bob uses Alice’s (note, not Bob’s) public key to validate the authentication code – for a public key algorithm, the authentication code is called a signature and the validation is called verification. If the signature verifies with Alice’s public key, then the signature was generated with Alice’s private key and the message was not modified. Because only Alice knows her own private key, that means that Alice generated the signature and so that the message came from Alice. For performance reasons, an actual implementation would perform the signature operation on a checksum of the message only.
Public-key algorithms have two significant properties:
- They are relatively slow compared to symmetric algorithms (which translates into implementations being more expensive in terms of processing compared to symmetric algorithms). For example, ECDSA-256, the public key algorithm that is used in the CAMP VSC3 design, can generate about 1500 signatures per second on a 2 GHz processor and can verify only about 300 signatures per second.
- They require authenticated key exchange, but the key exchange can be public. If Alice has some assurance that a public key belongs to Bob, she can use that key to verify Bob’s signed messages or encrypt messages to him even if many other people know the public key as well. Alice knows that a public key belongs to Bob usually because the CA attests to it by signing Bob’s public key. Bob’s public key is signed by the CA and is referred to as Bob’s certificate. So long as Alice and Bob trust the CA and have access to the CA’s public key, they can trust that keys signed by the CA are genuine. This makes public key cryptography ideal for settings where two parties encounter each other briefly and need to trust each other’s communications, even if they do not have access to an online key service. This is the relevant setting for V2V communications, which is why CAMP VSC3 and IEEE 1609.2 use public key cryptography.
Hash Functions
There is a third useful type of cryptographic algorithm, known as the hash function. A hash function produces a cryptographically strong, fixed-length checksum of a message. The output from the hash function, often called a hash or a digest, is cryptographically strong in the following senses:
- The output looks random: small changes to the input message result in significant changes to the hash
- It is computationally infeasible to find a message that hashes to a particular hash value. (Hash functions are non-invertible, or have pre-image resistance.)
- It is computationally infeasible to find two messages that hash to the same value. (Hash functions have collision resistance.)
- Hashes are fast, comparable to or faster than symmetric algorithms. In the CAMP VSC3 SCMS, hashes are used for a number of purposes:
- A truncated hash of a certificate can be used as an identifier in messages signed by that certificate, so that the sender does not have to send the full certificate with every message
- Messages are hashed before signing them: the (private-key) signature operation is actually applied to the hash of the message but not to the message itself. This has both security and efficiency benefits and is standard practice in cryptographic systems outside the CAMP VSC3 system.
- Hashes are used to generate linkage values as described in SCP2: Linkage Values
Random Number Generators
Random number generators are used to generate keys and other random data within a system that uses cryptography. Since the security of a system depends on private and secret keys being unobtainable through unauthorized exposure, it is important that the random number generators used to generate them are good. In this context, “good” means a number of things:
- An attacker must not be able to determine the next output from the random number generator, no matter how much previous output the attacker has seen. This means that the output must be statistically random and contain no bias. If the random number generator is used to generate an integer modulo some modulus n, all numbers between 0 and n-1 must be equally probable with no bias towards particular values.
- If the random number generator uses an internal state, an attacker must not be able to guess the internal state of the random number generator and use this to predict output. This means that:
- The internal state must be large enough to be infeasible to guess by brute force
- The initialization process that initialized the internal state must be infeasible to reproduce
- If the random number generator uses some hardware-produced randomness source, the output from this source must be infeasible to reproduce
As well as secret and private keys, random number generators are used for other purposes within the SCMS:
- When signing with Elliptic Curve Digital Signature Algorithm (ECDSA), a fresh entirely random number must be generated for each signature with the same key. Repeated random numbers, random numbers with a bias, or random numbers with a known relationship to each other will reveal the private key.
- Random numbers are used by the PCA when creating implicit certificates or when expanding a butterfly signing key (see SCP1: Butterfly Keys). If these random numbers are not good, it can result in the Registration Authority (RA) being able to track a device, or even the PCA’s private key being revealed.
- Random numbers are used to generate Linkage Seeds (LSs) for linkage chains (see CB3: Public Key Infrastructure, SCP2: Linkage Values). If these random numbers are not good, it can result in a device being trackable by a Linkage Authority (LA) or the PCA.
All SCMS components, as well as EEs, must be equipped with industrial quality random number generators, e.g., one of the Approved Random Number Generators.