OnBoard Security, the embedded security division of Security Innovation, recently commented on the US Department of Transportation’s Notice of Proposed Rulemaking (NPRM) on V2V communications. OnBoard Security strongly supports the establishment of the proposed regulation since the number of lives saved increases dramatically as the number of cars with V2V increases. Widespread penetration of the technology, and the corresponding prevention of deaths, can only be reached in a reasonable time with a mandate.
However, in the comments, authored by OnBoard Security’s CTO Dr. William Whyte, there are a few modifications we recommend to make the NPRM more effective. The complete document can be found here, but I will summarize our comments below.
Interoperability and adherence to standards
The National Highway Traffic Safety Administration (NHTSA) recommended a performance or test-based approach to interoperability. We agree that interoperability is essential for the system to work, but the performance-based approach leaves open the possibility for messages to agree in semantics but differ in syntax. For example, if the order of the message fields is different, a test may still pass but the meaning of the message is not correctly understood.
The better solution is for the existing SAE J2945/1-2016 standard to be referenced and followed. This standard, which was developed with the support of the automotive industry, has been widely implemented and tested and eliminates the potential ambiguity of test-based approaches.
NHTSA sought comment on three alternative approaches to message authentication:
- Public Key Infrastructure (PKI)
- Performance-based only
- No message authentication.
OnBoard Security strongly prefers PKI. As discussed earlier, the performance-based approach doesn’t guarantee interoperability. No message authentication leaves the system open to a flood of fake messages. Only a PKI gives the security and interoperability guarantees that a successful system requires.
Misbehavior detection and reporting
NHTSA also sought comment on two alternatives for misbehavior detection and reporting:
- Mandate requirements that would establish procedures for communicating with a Security Credential Management System to report misbehavior
- Impose no requirement to report misbehavior but require implementers to ensure the device has not been altered or tampered with from intended behavior.
OnBoard Security recommends a combination of the two alternatives. We believe that misbehavior reporting is critical, but since there is no misbehavior reporting standard that can currently be referenced, the mandate should move forward without it. We recommend that the mandate requires alternative #2 and misbehavior reporting support once a standardized specification is available. Our comments document also gives a number of recommendations on what should and should not be mandated around misbehavior detection.
Formal generation and verification of code
OnBoard Security considers formal generation of code a valuable approach but notes that the proposed regulation only proposes generating a small percentage of the code formally. As such, it is not clear that there is a significant security gain from requiring this.
Require user consent to certificate update
We see no reason to require user consent for certificate update. If the user is asked for consent, it should be to continue operating the system or not. If they are using V2V communications, the certificate updates should be automatic.
NHTSA proposes that V2V equipment “is hardened against intrusion (FIPS 140 Level 3) by entities attempting to steal its security credentials.” OnBoard Security is concerned that the requirement does not take into account the current expense and limitations of FIPS 140 level 3 hardware and prohibits alternative approaches that may be just as effective in limiting compromise.
Is the requirement too strict?
The purpose of requiring FIPS 140 level 3 hardware is to reduce the number of devices that are compromised and have their keys extracted, allowing the attacker with physical access to the device to create a large number of false messages. However, if the requirement was instead for FIPS 140 level 2, the attacker would also need physical access to the device. FIPS 140 level 3 requirements include a large number of design requirements that are not necessary for the protection of sensitive information in this context, creating unnecessary expense. We believe that the requirement can be relaxed without significantly impacting security.
Is the requirement too loose?
The requirement addresses hardware security for storage of keys and other critical information. However, other aspects of the system are equally critical for security: for example, if the software that checks the CRL is compromised, it can indicate that an incoming certificate has not been revoked even though that revocation has in fact occurred. It is inconsistent to require different levels of physical security for information and for the code that uses that information. A better approach is to require secure boot and secure update processes that protect the integrity of both the information and the code.
OnBoard Security recommends that the regulation provides specific security requirements and makes it clear that formal FIPS certification is not necessary. It isn’t clear that some of the cryptographic constructs in the current SCMS design, such as implicit certificates, are FIPS-approved and so it is possible that an HSM that implements this design cannot in fact be formally certified.
“Stored in FIPS 140 Level 3 storage”
The NPRM states that certificates, system config files and other info should be stored in FIPS- 140 Level 3 storage. We are concerned about the phrase “stored in”. We recommend instead the phrase “protected by” and further recommend that the regulation distinguishes between information with a requirement for confidentiality and information with a requirement only for integrity, to reduce storage and security costs. The statement is also incomplete, as it addresses storage but does not address how the sensitive information is protected when in use. Our comments document recommends alternative text.
FIPS 140 proposal
Finally, OnBoard Security proposed a table of specific FIPS 140 profiles to be used as the basis for the HSM. This table can be viewed in the comments document.
OnBoard Security has been involved with Vehicle-to-Vehicle Communications security for more than a decade. Our CTO, William Whyte, is the editor of the IEEE 1609.2 standard and our Aerolink security libraries have been used in nearly every proof of concept, pilot program, or production deployment. We strongly believe that the V2V mandate will prevent accidents and save thousands of lives and should be enacted as quickly as possible. With our recommended changes, we believe that there will be less ambiguity and lower costs by eliminating unnecessary requirements.