Holistic Security for the Software-Defined Car

Bill Boldt
Sr. Business Development Manager, Security
Blackberry Certicom

Due to high profile hacks on cars, it is hard to argue that without security you can have safety.   So, security is emerging as perhaps the most important factor in the evolution of the connected autonomous car.
 
Cars are the most software intensive systems in the universe with far more lines of code than even a state of the art jet fighter. By being such complex digital systems they have become prime targets for attack, and that is where cryptographic countermeasures come in.

Connecting the dots – in the emerging software-defined world safety increasingly
comes from security and security comes from cryptography. Robust cryptographic security implementation is how you increase trust, and when it comes to a car every system must be
trusted: inside the car, in the smart infrastructure, in emerging applications-based ecosystems, and in the manufacturing supply chain. When considering automotive security,
many factors come into play. Some are noted here:
                       

• Automotive security fundamentally depends on the security of the operating system. For example, a microkernel architecture that separates critical OS components into their own protected memory partitions, provides temporal separation, and provides network security, among other things can greatly reduce the attack surface.

• Security assets (crypto keys, serial numbers, etc.) must be securely installed into electronic devices such as Electronic Control Units (ECUs), domain/area controllers, and other processors. This process is called "personalization".

• Electronic devices will often get personalized and installed into vehicles in globally located factories, which should utilize secure equipment and processes to ensure security of the devices.

•  Devices must be updateable at dealers and repair shops. 

• Aftermarket suppliers must be able to sell and update secure devices, and

• OEMs must be able to authorize or not authorize specific electronic devices at
  manufacturing time and after the car is in use (for example to enforce warrantee policies).
  

And, there are many more.


Personalizing a device such as a networked ECU means that it will become one of a kind. However, by definition that device cannot be used anywhere else. It becomes a unique stock keeping unit (SKU), which is averse to the purpose of flexible, just in time manufacturing flows. Security versus manufacturing flexibility is a serious trade off that will play a part of any automotive security design decision.

Security robustness versus cost is another critical trade off, and applies to the manufacturing infrastructure and the design of the secure systems inside and outside the vehicle. Because security must be injected in the factory and in the field, a secure manufacturing system must have global reach, be manageable on a distributed basis, be updatable by various entities, and remain secure for years. In addition, security updates will increasingly be made over the air, and the systems that do that must by highly secure while being easy to manage. To maintain the maximum amount of flexibility, personalization and updating should be moved as close as possible to the very last minute, which is becoming a critical objective of the global manufacturing blue print. 

Blackberry Brings It All Together

In the car, outside the car, and in the manufacturing supply chain, security must be designed with best practices in mind right from the start, and BlackBerry Professional Services can help with that. BlackBerry QNX provides mission-critical automotive software proven in the automotive market.  QNX software is well known for safety and new products are setting the new standard for security.

BlackBerry's Certicom subsidiary provides certified cryptographic code and design consulting, as well as secure equipment and managed services that harden the automotive supply chain. Completing the picture, BlackBerry's secure OTA managed services make it easy to update software and security assets over the air. When it comes to automotive security, BlackBerry brings it all together.

Read More

The Automotive Shift to Software-Defined, Consolidated Controller Architectures

Thomas Bloor

Automotive Business Development Manager
BlackBerry

Electronics in the car have come a long way from the first in-car radio in 1930, and 1978 when Mercedes-Benz introduced the first production car with an optional electronic four-wheel multi-channel anti-lock braking system (ABS) from Bosch.

Today, according to Manfred Broy, a professor at the Technical University of Munich, the cost of electronics and software has increased to 30% of a car's bill of materials. He estimates that 90% of new innovations now come from electronic systems in the car, and projections indicate the cost of electronics will surpass 50% in ten years as we move towards more advanced driver assist and fully autonomous functions in the car. These costs are driven by the electronic architecture of the modern car. 

If we were to examine a modern luxury vehicle we would find a very complex interconnected network of between 60 to 100 electronic control units (ECUs) in aggregate running between 6 to 8 different operating systems with around 100 million lines of code. The distributed automotive computing architecture has evolved over many product generations as new features and innovations have been added though new hardware modules. This approach has served the industry well, but being faced with rising costs from more complex infotainment and new driver assist systems the existing model is becoming inefficient and a drag on bringing new features and innovations into the car. Complexity presents serious challenges, not the least of which are safety and security.

Additionally, the vision of urban mobility that will utilize fully electric autonomous cars has brought new competitors to the industry. These new entrants are rooted in hi-tech and are entering the automotive industry with the opportunity to architect the car from a clean sheet. Unencumbered by the burdensome legacy of traditional automotive manufacturers face,  the newcomers are architecting vehicle systems by leveraging advances in silicon technology to make designs with a smaller number of consolidated controllers with larger processing capabilities.

The evolution to these new consolidated controllers will provide a number of cost benefits. According to a study by Roland Berger associates, consolidated controllers will provide $110 of direct cost savings from hardware consolidation alone. An additional $65 of secondary savings will come from a reduction in software licensing and tools. The study did not quantify savings from software reuse, but positioned reuse as the unseen bulk of the iceberg under the water. As software development costs are often the largest single item in terms of time and manpower, a development savings in the software domain can dwarf the $175 of savings quantified by the researchers.

So, both the new entrants and established companies within the industry are moving towards a domain or area controller architecture – consolidating functions into a smaller number of more flexible processing nodes within the vehicles architecture. This consolidation opens the possibility of reducing the number of operating systems in the car to three or four and the total number of controllers to between six to ten.

This enables a more flexible architecture with a high degree of reuse of the software code base between the different domain/area controllers. In turn this allows the complete vehicle architecture to be built in a flexible manner, enabling the same code base to be reused across generations and differing variants within a model range. 

This more efficient vehicle architecture provides benefits such as reducing the number and duplication in development tools and the associated costs. Developers benefit as deeper experience in a smaller number of operating systems will reduce training requirements and improve developer skills and efficiency.  Reducing overall complexity also improves security and safety, because fewer attack surfaces are presented to a hacker with malicious intent, and  it focuses resources to find and fix security vulnerabilities in a smaller number of operating systems.

So, you can probably see that the auto industry is entering a revolutionary period in vehicle architecture.  Vehicle electronics will consolidate, and with that automakers and Tier 1s have the opportunity to build consolidated, adaptable software environments to speed time to market and enable multiple model variants to be derived from a common code base.  To realize the benefits of these changes a software architecture that is applicable across the majority of vehicle functions is desired. 

The choice of an operating system that enables increased reuse and has proven quality and reliability provides a valuable foundation upon which this architecture is built.  Wide applicability guides the choice to an operating system that is capable of providing mission-critical reliability and security for advanced driver assist (ADAS)and autonomous drive functions, while also being capable of underpinning consumer facing infotainment solutions.

BlackBerry's QNX subsidiary has a long history of underpinning the majority of autmotive infotainment systems in production today.  That is in no small part because QNX's common code base supports both safety OS and infotainment requirements, which provides an advantage in developing, reusing, and productizing code across safety and non-safety certified domains.   QNX recognizes that automakers may want to build mixed ASIL environments in their consolidated controllers as well as consumer infotainment offerings such as those from Google or other sources, so we built QNX’s hypervisor solution.

Availability of safety certification on the hypervisor with no changes adds flexibility and reduces development costs as ASIL certification can be completed after the code is partitioned between controllers, knowing that the underlying software complies with ISO26262. This enables a cockpit controller running a cluster application to have mixed ASIL A and B partitions in its software, and combine these in different informational zones in the same display. The obvious example being cluster gauges and navigational maps being displayed side by side with both partitions being run on a single processor.

Running this type of mixed environment requires full separation and isolation between domains and a safety certified hypervisor solution.  With QNX’s safe, secure, and reliable software solutions you can build an adaptable and dependable vehicle architecture. With safety certification available without the need for code base changes you can develop flexibly with the knowledge of being able to achieve ASIL certification where required.

The changes in vehicle architectures towards more consolidated domain/areas controllers enables am evolution in the software development methodology for the car, namely a shift to a continuous platform development methodology that will enable automakers to compete with new entrants from the high-tech world.  The new architectures will also allow the increased complexity of vehicle systems evolve safety and securely as we move towards the fully autonomous car. 
 

The ability to drive a flexible architecture and derive multiple vehicle platforms from a common code base and set of hardware controllers will be a competitive advantage to automakers and Tier 1s who embrace this approach.  They seem to already know that. Additional benefits of this approach include cost reduction and time to market acceleration stemming from reuse and improved security through the elimination of attack surfaces and the ability to embed cryptographic countermeasures security into the more capable controllers and ECUs.

This may be quite a challenge but we see many automakers and Tier 1s today accepting the challenge and adopting these practices.

Read More

Autonomous Cars – Part 2: The ABCs ADAS

Kaivan Karimi
SVP of Strategy and Business Development
BlackBerry Technology Solutions (BTS)

Advanced driver assistance systems (ADAS) is one of the most important of the many different technologies going into the connected autonomous car of the future. 

ADAS is evolving from discrete single function systems, such as blind spot monitoring and lane departure warning to integrated active safety systems and automated driving.  With ADAS high performance computing is intersecting with the need for functional safety, changing the very nature of the hardware and software in these next generation systems. So, a flexible, safe and stable software environment that leverages the performance advances in silicon while maintaining ISO 26262 functional safety certification is critical.  In an ADAS based car, software is the nervous system that works with the brains of the operations, which are  Microprocessors/Microcontrollers.  Together they work seamlessly with a range of other hardware components, some of which are noted below.

Radar Systems

Radar technology collects information around the vehicle and feeds it to the ADAS’s domain controller managing sensor fusion.  Several subsystems are part of the package such as a 77 GHz radar system that enables high precision and scalability from short to mid to long range detection; 24 GHz radar for high-demand features, such as rear cross traffic alert or blind spot detection; and Light Detection and Range (LIDAR) for adaptive cruise control, accident avoidance and mitigation and object detection. LIDAR is like a light-based radar that sends out short pulses of invisible scanning laser light, and based on how long it takes to see the reflection, calculates how far away it is.  It then creates a 3-D image of the surroundings of the car with high accuracy. 

Vision Processing

 A range of cameras and sensors combine to see the world.  External cameras assist with lane departure warnings, forward collision warnings, traffic sign recognition, and pedestrian recognition. Internal cameras provide information related to the driver’s focal point and behavior so that the ADAS system can react accordingly. These can be augmented with 3D capabilities that enable new HMI user experiences, such as gesture recognition and control of cabin button functions, or infotainment systems.  Ultrasound is also used for close-end object detection and will be used in park-assist applications, where a typical car would have between 10 to twelve sensors.

GPS

Global Positioning Systems are satellite-based navigation systems using a network of 24 satellites that were put in orbit by the U.S. Department of Defense (DoD) for military applications. In the 1980s the US government made the system available for civilian use. Galileo (EU), GLONAS (Russia), BeiDou (China), and IRNSS (India) are examples of other satellite-based navigation systems being developed around the world.  They have accuracy of within 10 to 50 feet for 95% of the time, with most providing a worst case pseudo-accuracy of 7.8 meters at a 95% confidence level. The actual accuracy depends on factors such as atmospheric effects, line of site clearance to the satellites, and receiver quality. To improve GPS location accuracy to centimeter-level accuracy, systems make use of ground-based reference points in combination to the satellite signal. These types of systems are called “differential GPS,” and a great example is that which comes from rental car companies.

For a self-driving car you need to know which lane a car is in and where within that lane is in reference to other cars and structures surrounding it, and all of this must be updated at high rates in real-time. This requires computational intensity as well as augmented GPS functionality with accelerometers, altimeters, gyroscopes, and a tachometer/odometer to achieve finer measurements of the position of the car under various conditions.

V2X

V2X communication refers to the exchange of information from a vehicle to anything that may affect the vehicle, and vice versa.  V2X stands for Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I), Vehicle-to-Pedestrian (V2P), Vehicle-to-device (V2D), Vehicle-to-grid (V2G) and for all practical purposes, Vehicle-to-Everything.  (You can see that the “X” is the catch-all variable.) 

V2X is considered a cooperative approach between cars and their environment to make a more effective means to avoiding accidents and traffic congestion. For V2X to really work it needs to be rolled out with adoption rates of greater than 95%, and from that perspective it may be a few years before the infrastructure is put in place. The communication technology most often talked about for V2X is based on Dedicated Short Range Communication (DSRC) operating at the 5.9 GHz frequency based on 802.11p 

Wireless Access for Vehicular Environments (WAVE). The architecture, message protocols, and security standards are based on IEEE 1609.x in the US and various of ETSI layer standards.  Note that cryptographic security must be built in so that the signal sent and received can be trusted.  False or corrupted signals can produce dire results.

V2X will establish a hybrid access network and enable the flow of information regarding traffic delays and hazard warnings (e.g. road flooding, electrical poles down, or even cars driving in the wrong direction, and others) in a real time manner.

Telematics

A telematics system mixes the functionalities of telecommunications and informatics for a car, and a good way to explain the range of functionalities in a telematics system is to take a closer look those supported by OnStar from General Motors. OnStar includes a cellular modem, GPS, connections to a variety of sensors (some of which are dedicated to reporting significant crashes), a backup battery, and a roof mounted antenna with a range that is better than a typical cellphone. 

The box itself gets a “black-box” treatment, and is mounted in the back of the car to shield it from most crashes. The system is connected to a call center, which in turn can report accidents to a public safety answering point such as a 911 operator, and contact garages if only simple towing services or mechanical help is needed. After any incident, the call center operator contacts the passengers of the car, getting more information and assuring them that help is on the way. Emergency and roadside assistance along with basic vehicle diagnostics are the most popular services for most Telematic systems. 

Over time, a host of other services have been added from weather reports and sports scores, to traffic information, geo-fencing, and stolen vehicle tracking. The list of automakers who already offer telematics services include GM, Chrysler, Ford, Lincoln, Audi, BMW, Mercedes-Benz, Volkswagen, Porsche, Jaguar, Rolls-Royce, Volvo, Mini, Toyota, Infiniti, Lexus, Mazda, Nissan, and Subaru. 

Domain Controllers and Micro Processor/ Micro Controller Units (MPUs/MCUs)

MCUs and MPUs are the physical hardware brains of the whole vehicle operation, and combined with powerful sensor fusion algorithms are what turn a car into a robot. With the number of sensors feeding situational awareness data in real-time, one can see that high-speed and high-bandwidth data processing are at the heart of automated driving.  High performance Electronic Control Units (ECUs) accept the sensor inputs that monitor the automobile’s constantly changing environment, and fuse those data at speeds of greater that 1Gb/sec to make safe decisions.  As the table shows, this will ultimately shift the burden of “situational awareness and response” from the driver to the car. High-speed decision making at real-time speed, dealing with the amount of data discussed above, requires secure, reliable, and very fast processing computers. 

  

The growth of electronics in cars has resulted in double-digit growth of the number of ECUs being used in all car segments. Today’s embedded vehicle functions are shared between up to 100 ECUs and are connected over several buses, and typically uses 6-8 operating systems. This decentralized system has drawbacks in increased complexity, weight, and overall cost of the vehicle. The trend now is to move from 80-100 decentralized ECUs scattered across the vehicle, to 8 to 12 domains with their respective mega-ECUs, or Domain Controllers, which among many other things reduces the complexity of the system.

The next blog will address the software architectural issues to be considered when creating connected autonomous car of the future.   For more see the QNX web site.

 

_______________________________________________________________________________

Kaivan Karimi is the SVP of Strategy and Business Development at BlackBerry Technology Solutions (BTS). His responsibilities include operationalizing growth strategies, product marketing and business development, eco-system enablement, and execution of business priorities. He has been an IoT evangelist since 2010, bringing more than two decades of experience working in cellular, connectivity, networking, sensors, and microcontroller semiconductor markets. Kaivan holds graduate degrees in engineering (MSEE) and business (MBA). Prior to joining BlackBerry, he was the VP and General Manager of Atmel wireless MCUs and IOT business unit.

Read More