Business Development Manager, Security
Electronic Control Units (ECUs) started out in the 1970s as discrete modules with each one doing one particular thing, at that time mainly for emissions controls and mileage. Then they became connected via in-car networks with the invention of the CAN bus in 1985. In-car networking represented a big improvement in capability. However, being networked means that ECUs became vulnerable to mischief and thus they, and what the connect to (such as domain and area controllers) need to be secured cryptographically to ensure that the signals being sent have not been tampered with or corrupted, and perhaps most importantly, that they are authentic. There is also the emerging need for confidentiality (i.e. encryption/decryption).
The picture below shows the top attack points. This range or targets indicates just how vulnerable cars have become:
Trust is paramount in digital systems, and increasingly so in automotive. Trust comes from cryptographic solutions that:
- Securely store secret keys
- Securely issue, manage, renew and revoke security certificates
- Include a mix of software and security hardened hardware devices, and
- Are manufactured in highly secure facilities
What Creates Trust?
A major tenet of security is that each system and sub-system will have different types of threats and a range of options to provide countermeasures to those. This means that the automotive security equation has many variables and thus is difficult to solve.
However, two things are always common to trustable cryptographic security, and they form the basic foundation of modern security:
- A proven algorithm (e.g. Elliptic Curve Cryptography (ECC)), and
- A secret cryptographic key (to provide the required level of security for the selected algorithm).
On a CAN bus, which was designed without security in mind, ECUs are exposed. So, connected cars should employ best practices for security, but cost, complexity (especially of the supply chain) and time get in the way. Having said that, best practices will eventually prevail and that will likely include a hardware trust anchor system to establish, maintain, and update cryptographic processes.
From the diagram you can see the four basic things that create a PKI-based hardware trust anchor:
- A trusted hardware anchor that stores the key
- That key, which becomes the root of trust
- The certificate chain anchored by the root of trust, and
- A signing mechanism that creates the anchored certificate chain
Because there are so many systems in the increasingly software-defined car, security has to be multi-layered and fit the specific application. In other words — it must be tailored. You have to figure out what you are securing, what threats that system will face, and what countermeasures should be employed. You have to pick what pillars of security to apply; namely, confidentiality, data integrity, authentication, and non-revocation. Making sure you are doing the right security things on each system is what Blackberry is positioned to help you with, from consulting, to design, testing, certificate management, securing the supply chain, making updates, and applying cryptography to the in-car and around-the-car networks.
To learn more about cryptography for automotive please contact Blackberry's Certicom
subsidiary, and for more information and/or help regarding reliable, secure, and trusted software for safety- and mission-critical applications such as automotive please contact QNX.
The bottom line is that BlackBerry, Certicom, and QNX can help your system become not just secure, but BlackBerry secure.