Welcome to the Acumen Security Blog

Car Hacking

As computers have went from luxuries to necessities in our daily lives they have solved many problems for a lot of people and made life easier. The problem is that it also applies to people who wish to harm others in various ways.

First, let us take into consideration the car hacking that has surfaced over the past couple of years. Research has shown that it is possible, it is dangerous and we need to be prepared to protect ourselves or be protected by the manufacturers. We definitely do not need to wait until serious damage is done before we fix a problem that will cause serious issues. Vehicle manufacturers are already making improvements to the development process to include more robust security measures to be in place for these interconnected automobiles.

Second, I imagine it will not stop with just our personal vehicles. What about construction vehicles that are also working to implement telematics systems that give companies the ability to monitor vehicles through GPS, cellular or Wi-Fi? A hacked dozer could do some serious damage. I do not know what those companies have in place for securing the systems they are developing. I have made some calls but I have not received any responses yet.

This is a completely new topic to me and I will continue to follow it closely. As time goes on, I hope to see more awareness, not just in vehicle computer security, but in security as a whole whenever a computer is involved. We can make things easy but if it’s not safe we may lose just as much as we thought we gained or more.

The certification community already have a set of best practices around protection of data (e.g., cryptography) and secure management.  Now, the certification industry is presented with an opportunity to be involved in the growing industry of connected vehicles before some of the same mistakes are made in the industries before them.

The SSH Extended Package

Several weeks ago a new EP that adds SSH capabilities to the Application Software, General Purpose OS and Mobile Device Management PPs was released. Most of the SFRs and assurance activities in this EP should be familiar to anyone who has worked with previous PPs that had SSH requirements. What’s significant about this new EP is that it is a step toward making PPs more modular. In the future capabilities such as SSH will be presented in separate EPs rather than as optional components of baseline PPs. This should streamline future changes for protocols like SSH since a single EP update can cover a wide variety of product types.

As with all new PPs and STs the SSH EP splits SSH SFRs into client or server SFRs depending on the TOE’s functionality. The client and server SFRs are quite similar and the testing methodologies for their Assurance Activities are usually the same, but this change does allow ST authors to write documents that more accurately reflect their products.

One significant change in the SSH EP’s requirements compared to those in older PPs is the requirement that the TOE support AES-CTR. In the past most PPs required the use of AES-CBC with AES-GCM being selectable as well. In this new EP AES-CBC and GCM are both selectable as additional ciphers. This change was partially the result of a conflict between Common Criteria, FIPS and the Department of Defense’s Unified Command Approved Product List (UC APL). This conflict was documented in greater detail in the previously referenced blog post, and changing CC’s requirements to AES-CTR makes it easier to get a product certified under all three of the above referenced standards.

Another addition to the SSH EP is the option of using x509 public key algorithms. This is not the first time these optional selections have been made available to ST authors (they are a choice in the NDcPP’s SSH requirements) but they are a departure from the requirements in the NDPP that are so familiar to many CC customers and evaluators. As in the NDcPP if any x509 algorithm is selected then the ST must include a list of trusted certification authorities.

The SSH EP’s requirement to periodically rekey SSH connection will also be new to those who are familiar with the NDPP. The NDcPP has also included an SSH rekey requirement but it simply requires that the connection be rekeyed after no more than 2^28 packets have been transmitted. The SSH EP gives the option of basing rekey requirements on the number of packets transmitted, the amount of data transmitted  or the age of the connection.

Most the SSH EP’s assurance activities will be familiar to those who have tested SSH as part of NDPP evaluations, but there are some new requirements. When testing for support for encryption algorithms evaluators must now also ensure that an attempt to connect using 3DES-CBC will be rejected. The testing of public key algorithms requires the rejection of SSH-DSA public key algorithms and when data integrity algorithms are tested the TOE must be shown to reject connections without a MAC algorithm or those attempting to use HMAC-MD5. These tests are all present in the NDcPP but they are a change from the days of the NDPP.

The SSH EP creates a standardized set of SSH requirements for a large variety of TOE types. As we’ve shown above most of the testing requirements are not new, but they are more rigorous than many people are used to from the NDPP. The switch to AES-CTR may be a burden on vendors in the short term, but it should make certifications across FIPS, CC and UC APL easier in the future.