While much of the technology and security behind V2V is still being ironed out, we do know that the security for cellular, DSRC, and hybrid commu- nications is based on a public key infrastructure (PKI) model much like the SSL model on websites. By generating public and private key pairs,
PKI systems allow users to create digital signatures for use in encrypting and decrypting documents sent over networks. Public keys can be openly exchanged and are used to encrypt data between destinations. Once encrypted, only private keys can be used to decrypt the data. The data is signed with the sender’s private key in order to verify its origin.
PKI uses public key cryptography and central certificate authorities (CAs) to validate public keys. The CA is a trusted source that can hand out and revoke public keys for a given destination. The V2V PKI system is some- times also referred to as the Security Credentials Management System (SCMS).
For a PKI system to function, it must enforce the following: Accountability Identities should be verifiable using trusted signatures.
Integrity Signed data must be verifiable to make sure that it hasn’t been altered in transit.
Nonrepudiation Transactions must be signed. Privacy Traffic must be encrypted.
Trust The CA must be trusted.
V2V and V2I systems rely on PKI and a CA to secure data transmission, though the identity of the CA has yet to be determined. This is the same system that your browser uses on the Internet. On your browser’s Settings screen, you should find a HTTPS/SSL section listing all authorized root authorities. When you buy a certificate from one of these CAs and use it on a web server, other browsers will verify this certificate against the CA
to ensure it’s trusted. In a normal PKI system, the company that set up the environment controls the CA, but in V2V, government groups or countries will likely control the CA.
Vehicle Certificates
The PKI systems used to secure today’s Internet communication have large certificate files, but due to limited storage space and the need to avoid con- gestion on the DSRC channels, vehicle PKI systems require shorter keys. To accommodate this need, vehicle PKI systems use elliptical curve cryptogra- phy (ECDSA-256) keys, which generate certificates that are one-eighth the size of Internet certificates.
The vehicles participating in V2V communication use two types of certificates:
Long-term certificate (LTC)
This certificate contains vehicle identifiers and can be revoked. It’s used to get short-term certificate refills.
Short-term, pseudonym certificate (PC)
This certificate has a short expiry time and, therefore, doesn’t need to be revoked because it simply expires. It’s used for anonymous trans- fers, which are designed for common messages like braking or road conditions.
Anonymous Certificates
PKI systems are traditionally set up to identify the sender, but with infor- mation being broadcast to unknown vehicles and devices, it’s important to ensure that V2V systems don’t send information that can be traced back, such as packets signed by the source.
For that reason, there’s a provision in the V2V spec that allows you to sign packets anonymously, with only enough information to show that the packet came from a “certified terminal.” Though this is more secure than sending packets signed by the author, it would still be possible for someone to examine the anonymous certificate signature on a given route and deter- mine the route that vehicle is traveling (in the same way that you might use the unique ID transmitted from a tire pressure monitor sensor to track a vehicle’s progress). To compensate for this, the spec states that the device should use short-lived certificates that will last for only five minutes.
Currently, however, the systems being developed are planning to use 20 or more certificates that are all simultaneously valid with a lifetime of a week, which could prove to be a security flaw.
Certificate Provisioning
Certificates are generated through a process called certificate provisioning. V2V systems use a lot of short-term certificates, which need to be provisioned on a regular basis in order to replenish a device’s certificates so that it can use them for anonymous messaging. The full details of how privacy works in V2V certificate systems is actually quite complicated, as the CAMP diagram in Figure 10-3 shows.
Prepare yourself for a lot of larvae references—as in caterpillar, cocoon, and butterfly—as we review how the certificate-provisioning process works:
- First, the device—that is, the vehicle—generates what’s known as a “caterpillar” keypair, which sends the public key and an Advanced Encryption Standard (AES) expansion number to the Registration Authority (RA).
- The RA generates a bunch of what are known as “cocoon” public keys from the caterpillar public key as well as the expansion number. These become new private keys. The number of keys is arbitrary and not cor- related with the device requesting the keys. (As of this writing, the request includes some ID information from the linkage authorities and should shuffle the request with requests from other vehicles. This shuf- fling is designed to help obscure which vehicle made each request in an attempt to improve privacy.
- The Pseudonym Certificate Authority (PCA) randomizes the cocoon keys and generates the “butterfly” keys. These are then returned to the originating device over an encrypted channel so the RA can’t see the contents.
In theory, the originating device can request enough short-term keys to last the vehicle’s lifetime, which is why the certificate revocation list (CRL)is important. If a vehicle has one month’s worth of certificates, it won’t check for new updates until that month is up, so a bad actor can continue to com- municate with this vehicle until there’s an update. If the vehicle has a year’s worth or more of certificates and no CRL functionality, then things can get real bad real fast because it won’t be able to identify bad actors.
