The first talk in the Automotive domain session was by Tobias Hoppe from Otto-von-Guericke-University of Magdeburg. It was about IT security in the automobile. As automobiles become more instrumented, and they contain personal data like navigation routes, phone lists, communications data, driving style and other personal or biometric data, the problem of hacking the car becomes a reality!
Attackers in the automotive domain usually have physical access and unlimited time (home garage, etc.)
Attackers will have access to data sheets, instruction manuals and network architectures, like CAN LIN MOST or FlexRay. They will have a wide range of equipment from selfmade and free to professional development devices.
There are five basic attack principles: read, modify, interrupt, spoof, steal.
There are SEVERE safety implications in the hacking of automotive IT. For example, a masked airbag theft.
There are two kinds of implications of an attack on an automobile: functional and structural. Functional are the desired results, while structural are the unintended results like side effects.
An example would be mileage manipulation.
There is a TV in motion hack by spoofing hand brake signals. This removes TV restrictions and potential safety risks include unexpected steering lock activation.
Here he presented a practical attack on recent automotive IT-- an information leakage attack illustrating the black box perspective and strategies and to exemplify the increasing relevance of privacy threats. The attack was made on a real car made by an international manufacturer on the central ECU gateway of the car's electronic network. The attacker attacked through the diagnostics port (OBD II). The attack was entirely successful. The attack demonstrated information _leakage_ but the demonstrated flaw also bears basic potential to indirectly write arbitrary messages to the ECUs inside the car. Another flaw was revealed that permitted an attack to be initialised from any subsystem, not just the OBD II gateway.
Clearly the automotive industry is not thinking about security, just like the process and utility industries.
The next talk was about "Safety Requirements and Validation of a Cooperative Traffic Management System: The Human Interface Perspective." Thomas Gruber presented the talk. He is from the Austrian Research Center.
COOPERS is the cooperfative system for intelligent road safety. Vehicles are connected via continuous wireless communication with the road infrastructure on motorways, exchange data and information relevant for the specific road segment to increase overall road safety and enable co-perative traffic management. It provides a variety of warnings and services from danger to traffic and weather conditions.
The team conducted a RAMSS analysis for the COOPERS system. RAMSS analysis discovers Reliability, Availability, Maintainability, Safety and Security of the system. One of the recommendations was to avoid directly controlling the car.
There is a four-stage model of human information processing
Sensory processing--->perception/working memory---->decision--->response
HFACS (Human Factors Analysis and Classification System) was developed by the US Military as a general human error framework originally for aviation accidents. It can be easily used in traffic modeling of human errors. It divides unsafe acts into errors and violations. Errors are divided into decision, skill-based and perceptual, while violations are divided into routine and exceptional violations.
Stress plays an important role. Higher stress means a higher error rate.
Gruber went on to discuss the types of human error and the probability of their occurrence.
He discussed risks related to the HMI and how to cope with them. Possible problems include information delayed, confustion trhough information overload, visibility issues, misunderstanding displayed information, and others.
The team set up an HMI working group to attempt to make recommendations for in-car HMI. This included driver training and making better manuals.
He discussed the essential properties of visual displays. The ideal size of a display is from 5" upwards. Larger displays with good usability, however, may hamper free sight when mounted on top of the dashboard. A minimum pixel size of 320 x 240 is recommended. Color can be recognized much more easily than text can. A graphic color display is recommended. It takes more time for accomodation to look down than to look aside. A location on top of the dashboard is to be preferred to a lower position.
Color is clearly preferred, and eight bit color is considered adequate. Visibility/contrast is a very important issue. Special screens for in-car use, not standard VGA, should be used. Screens should have adaptive abilities for varying light situations, such as automatic dimming and anti-reflex coating.
Symbols are better than text. Static symbols minimuze driver distraction, with animated symbols only for urgent messages. If moving symbols, the movement must be meaningful. The symbols should be in conformance with the Vienna Convention on Traffic Signs of 1968.
Different presentation of critical and non-critical messages is desirable. Audio and animation are recommended only for critical messages. Driver disctraction is an issue, as is information overflow.
Editor's note: this sounds very much like the EEMUA and ASM findings for control panels.
Muting the car radio is recommended. Headsets are nto very practical. For critical messages an audible message is highly recommended.
Haptic displays, like trembling steering wheel may distract the driver's attention and not recommended. Remote control is not very practical.
Input devices: hard buttons are ag good as touch screens for yes/no decisions. More complex decisions need more and different input devices.
These requirements are not final, but they must be validated by more simualtion and demonstrations.
The number of symbols on the display in teh car shall never exceed 5...Gruber presented this and other HMI properties.
The COOPERS experimentation is ongoing.
