Discussion paper for the next meeting

STATE OF THE ART ON ESECURITY

Preliminary note : This Document is an attempt to define the different questions connected with eSecurity in the different initial topics presented at ou kick off meeting :

• Protection against unauthorised mobile remote access and wired access on networked vehicles including the full electronic system and its components and data against manipulation and subsequent misuse (e.g. wired & tele- data / software transfer)

• Protection of electronic motor vehicle components against eassaults (e.g. viruses, trojans, spy-ware, spam, etc.) and of digital data

stored in the motor vehicle and road infrastructure against unauthorised access and manipulation

• Protection of motor vehicles, fleets and road infrastructure by securing telematics and cooperative system applications

• Establishment of the legal requirement catalogue on necessities in MS and European legislation, certification, and inspection procedures next to the eSecurity Standards survey

I had some contributions, mainly in relation with legal metrology (LM). LM has been very active in this field and has edited harmonized international documents. It appears that the initial topics did not mentioned the electronic embedded architecture which is the target of unautorised accesses.

As many vehicles and road side equipement integrate LM systems, this field is well known by many road stakeholders.

it is valuable to formalize the different questions connected with eSecurity and consider the response of LM, this is the way this document has been elaborated.

First there is an attempt to define functional requirements on embedded electronic architecture against unauthorised accesses and eassault on hardware, stored data and software.

Second there is an analysis of the different responses of LM to these functional requirements

is obviously a discussion paper, that has to be compared to the practise of eSafety stakeholders. As Welmec guides are in pdf format, I was not able to integrate them in this document.

ELECTRONIC EMBEDDED ARCHITECTURE IN VEHICULES AND IN SYSTEMS COMMUNICATING WITH VEHICULES

Most of the vehicles integrate embedded electronic architecture (EEA) which is in charge of an increasing number of functions. Some of them are connected with eSAfety (EEAS).

The new paradigm is, during the time life of the vehicle, to maintain the level of eSecurity of EEAS.

EEA comprise hardware and software components: calculators with processors, buses, memories, interfaces for sensors and actuators, links (RF, ADSL, IR), connecters and communication systems, and power supply.

There is no more a strict barrier between hard and soft as often hard components integrate mini software, or as mini hardware is introduced to improve treatments or as hardware needs configuration.

Some of these components are settled at the manufacturing, some others have a software that can be upgraded.

In ITS field, the functioning of electronics embedded equipments and the normal interactions between vehicles and infrastructure, vehicles and vehicles and vehicles and environment should not jeopardize security.

In ITS these items have been considered separately by stakeholders, so to get a better efficiency, it appears necessary to harmonize concepts structures and procedures, at an European level.

Vehicles should maintain during their lifetime a high level of security concerning their conformity to the specifications of the manufacturer and the compliance with the regulations.

Vehicles must obtain a type approval before they are admitted to road traffic. EEAS is not namely mentioned in this type approval, but plays an increasing and major role. The question of the implication of public authorities in this matter is raised to avoid accidents due to unauthorised modifications of EEAS at different levels : Conformity verification before the vehicle is put on the market or after being repaired, periodic controls and on the spot verifications could be defined in the regulation as in some MS.

1 CONCEPTUAL AND FUNCTIONNAL PRINCIPLES THAT SHOULD RESPECT EEAS

1. EEAS should be conceived with components and architecture that give a high level of confidence on good functioning and reliability.

2. The qualification procedure of the components and systems should take into account the environment in which the components should work , their lifetime and the time to the next control by authorized persons and means.

3. EEAS components should be manufactured under quality control procedures. Traceability should be ensured: EEAS should store records of the different components and versions, records of the different interventions and controls should be made. Vehicle manufacturers should duplicate and maintain these records under their responsibility, so that in case of defaults on a series of components, concerned vehicles could be called back.

4. EEAS could integrate automated diagnostic (EEAD) and warning for the next control

5. Accessible EEA functions should be conceived so that they could not affect EEAS.

6. EEAS should be conceived so that no desired modification could be made, without evidence of unauthorized intervention (seals control system).

7. The maintenance of EEAS and the delivery of spare components should be made through adapted architecture and procedures to ensure a high level of confidence on the effectiveness of maintenance operations

8. The replacement of components by new series components should not jeopardize EEAS and tests should be performed to give a high level of confidence, records of these possibilities of replacement should be added to the database of EEAS

9. redundancy components should be integrated to maintain EEAS reliability at a sufficient level.

10. Electric supply for the EEAS should have sufficient reliability.

11. The maintenance of EEAS should be made through an adapted architecture and procedures that give a high level of confidence on the effectiveness of maintenance operations.

12. up to date documentation on types of vehicules should be easily accessible to authorized persons and only to them.

13. Legal requirement catalogue on certification, and inspection procedures next to the eSecurity Standards survey

14. Communication with the vehicule EEAS

2 RESPONSES OF LM TO THESE FUNCTIONAL REQUIREMENTS

Points 1, 2 and 3 are respected by LM, in most of the cases there is a pattern approval of the type of the instrument that is managed by public authorities, then the test to be performed for initial, periodic inspection or after maintenance are described

Point 4 is respected for some measuring instruments that have embedded standards, but not by all types of instruments, in some cases the users must have physical standards to control their instruments.

Point 5 is respected by LM and introduce 2 classes of instruments type P for “build in purpose instrument” and type U for “instrument using universal computers”

Point 6 is respected by LM by a sealing map protecting the access to sensitive zones of the instrument and by coding transmission between the instrument and sensors

Point 7 is strictly applied in LM as in most of the cases only OEM components can be used for the maintenance of the instruments.

Point 8 is strictly applied, and when a component is replaced in an instrument, part or totality of the pattern approval tests must be performed

Point 9 is respected, when needed, to fulfil reliability requirements

Point 10 is respected by fixed and mobile instruments, specially when the measuring method cannot be repeated (flow meters)

Point 11 is strictly applied in LM as in most of the cases the only persons that are allowed to maintain and make initial and periodic inspections of the instruments must be agreed by public authorities

Point 12 is strictly applied in LM as in most of the cases the detailed characteristics must be fully accessible to maintenance and inspections and only to them.

Point 13 is strictly applied by LM, but take into account risk classes defined in accordance with the use of the measurements. There is a software guide defining 5 classes B to F (most stringent) according to software protection levels and software examination levels

3 WHICH SPECIFICATIONS OR REGULATIONS FOR EEAS

1 There is a need that eSecurity is ensured for EEAS.

2 Either the stakeholders for transport vehicles and communications with them respect rules (standards) that meet the need of eSecurity, either there is a need of regulation defining the functional requirements. As the vehicle market is at the globe size, and that all the countries do not respect eSecurity with the same rigour, it appears that minimum regulation defining functional requirements for eSecurity should be necessary.

3 LM offer a technological answer to a great majority of these functional requirements for eSecurity.

4 For the P and U instrument types, there is not a defined barrier in vehicles meanwhile some Security functions are assumed by one single system, some by one or more calculators. In vehicles redundancy as assumed through connected systems that could be considered as P or U type wether these computers are making only one function or many.

5 Particular attention should be put on power supply as EEA is no more active without electrical power supply.

6 A transcription for transport of the LM Software guide should be considered

7 Should these functional requirements be part of standards ?

Have MS to adopt these technical specifications for EEAS ?

Are there specifications needed by EEAS that do not exist in LM, namely in degraded conditions of use (after a shock, an element failure, etc.)? Can the contribution from Marcel Vierkötter be transposed to other countries ?

8 concerning communications, we have the contributions of Omniair and Certecs