185 Färdskrivarkorten skall fungera korrekt under alla klimatförhållanden som vanligtvis förekommer inom gemenskapens territorium och vid temperaturer mellan − 25 °C till + 70 °C, med tillfälliga toppar på upp till + 85 °C, varvid ’tillfälliga’ innebär högst fyra timmar per gång och högst 100 gånger under kortets livstid.

156 Kalibreringsfunktionen skall kunna mata in nödvändiga data genom kalibrerings-/överföringsanslutningen i enlighet med det kalibreringsprotokoll som anges i tillägg 8. Kalibreringsfunktionen får också mata in nödvändiga data genom andra anslutningar.

När fordonets tändning är på (ON) skall dessa data sändas kontinuerligt. När fordonets tändning är av (OFF) skall minst en ändring av förar- eller medföraraktivitet och/eller en isättning eller urtagning av ett färdskrivarkort ge motsvarande utgående data. Om utgående data har tillbakahållits medan fordonets tändning är av (OFF) skall dessa data göras tillgängliga när fordonets tändning har slagits på (ON) igen.

136 Det papper som används i färdskrivaren skall vara försett med giltigt typgodkännandemärke och angivelse av typ(er) av färdskrivare som det får användas med. Utskrifterna skall vara klart läsbara och identifierbara under minst ett år under normala lagringsvillkor, med avseende på ljusintensitet, luftfuktighet och temperatur.

124a När omständigheten ’omfattas ej’ (OUT OF SCOPE) påbörjas måste displayen med hjälp av relevant piktogram visa att omständigheten har påbörjats (förarens innevarande aktivitet behöver inte visas samtidigt).

108 Färdskrivaren skall ställa in data om kortanvändning på förarkortet eller verkstadskortet omedelbart efter det att kortet satts in.

105b Det skall gå att lagra data om särskilda omständigheter i dataminnet i minst 365 dygn (under förutsättning att det i genomsnitt påbörjas och avslutas en omständighet per dygn). När lagringskapaciteten har utnyttjats till fullo skall nya data ersätta de data som är äldst.

088 Det skall gå att lagra data om påbörjande och/eller avslutande av dagens arbetspass i minst 365 dagar i dataminnet (under förutsättning att en förare gör två registreringar per dygn).

Obs: Isatt (INSERTED) innebär att ett giltigt förarkort eller verkstadskort har satts in i kortplatsen. Ej insatt (NOT INSERTED) innebär motsatsen, dvs. att något giltigt förarkort eller verkstadskort inte har satts in i kortplatsen (exempelvis har ett företagskort eller inget kort alls satts in).

En inledd omständighet av typen ’omfattas ej’ (OUT OF SCOPE) måste automatiskt avslutas av färdskrivaren om ett förarkort sätts i eller tas ut.

Transport med färja/tåg (FERRY/TRAIN CROSSING) får inte äga rum om omständigheten ’omfattas ej’ (OUT OF SCOPE) inletts.

omfattas ej (OUT OF SCOPE) (start, slut).

Under hela detta förfarande skall färdskrivaren inte längre invänta angivelser under följande omständigheter:

050 Det skall vara möjligt att mata in de platser där dagens arbetsperioder påbörjas och/eller avslutas utan kort, eller vid andra tidpunkter än när kortet sätts in eller tas ut.

007 Färdskrivaren skall ställa in följande driftlägen enligt det giltiga färdskrivarkort som sätts in i kortläsaren:

aa) Omfattas ej (out of scope) : När användning av färdskrivare inte krävs enligt bestämmelserna i rådets förordning (EEG) nr 3820/85.

u) Däckens effektiva omkrets : Genomsnittsvärdet för de sträckor som tillryggalagts av de hjul som förflyttar fordonet (drivhjul) under loppet av ett fullt varv. Uppmätning av dessa avstånd skall ske under normala provningsförhållanden (se kapitel VI.5) och uttrycks i formen: 1 = … mm. Fordonstillverkare får ersätta uppmätningen av dessa avstånd med en teoretisk beräkning där axeltrycket i fordon utan last i körklart skick beaktas (3) . Metoderna för denna teoretiska beräkning skall godkännas av en behörig myndighet i en medlemsstat.

k) Fordonets karakteristiska koefficient : Det numeriska tal som anger värdet för den utgående signal som skickas av den del av fordonet som förenar fordonet med färdskrivaren (växellådans utgående axel eller fordonets hjul) medan fordonet tillryggalägger en sträcka av en kilometer under normala provningsförhållanden (se kapitel VI punkt 5 i denna bilaga). Den karakteristiska koefficienten uttrycks i impulser per kilometer (w = … imp/km).

speedsPerSecond är den kronologiska sekvensen av uppmätta hastigheter varje sekund under den minut som börjar vid speedBlockBeginDate (fr.o.m.).

Information som finns lagrad i en fordonsenhet om fordonets hastighet i detalj under en minut under vilken fordonet har varit i rörelse (krav 093).

RFU (reserved for future use - reserverat för framtida användning).

Rest of the world

RFU (reserved for future use - reserverat för framtida användning).

related time = card withdrawal time or time of entry

related time = card insertion time or time of entry

Information technology - ASN.1 encoding rules: Specification of Packed Encoding Rules (PER). Utgåva 2: 1998.

Code for the representation of names of languages. Första utgåvan: 1988.

3.6.1.2 Selection of an Elementary File using its File Identifier (val av datafil med hjälp av dess filidentifierare)

3.6.1.1 Selection by name (val med hjälp av namn) (AID)

′XXh′ (at least ′F0h′)

Reset (of the card)

Reserved for Future Use

Node Address used in T=1 protocol

Instruction byte of an APDU command

Information Field Size for the card

Class byte of an APDU command

’Handskriven information’, mata in ett tillräckligt antal tomma rader ovanför det som skall vara handskrivet, så att man verkligen kan skriva erforderlig information eller skriva under

Calculate Hash of File and store Hash value temporarily

DDP_031 Datafältet i meddelandet ’Positive Response Transfer Data Events and Faults’ skall tillhandahålla följande data i följande ordning under SID 76 Hex, TREP 03 Hex och passande delning och räkning av undermeddelanden:

DDP_020 Om IDE upptäcker ett fel under Start Communication-fasen, antingen genom tidsavpassning eller genom bitflöde, kommer den att vänta under en period P3min innan den utfärdar begäran igen.

Request out of range

conditions not correct or request sequence error

sub function not supported

Data not available

Request out of range

Conditions not correct or Request sequence error

Sub function not supported

first byte of a message header

Sub Function = responseRequired = [yes

Road vehicles - Electrical disturbance by conduction and coupling - Part 3: Vehicles with 12 V or 24 V supply voltage - Electrical transient transmission by capacitive and inductive coupling via lines other than supply lines. First Edition: 1995 + Cor 1: 1995.

Märk: Vid den första starten betyder innan koden exekveras (och inte nödvändigtvis under förfarandet Answer To Reset).

Smartcard Integrated Circuit With Embedded Software Protection Profile - version 2.0 - utgåva juni 99. Registrerad hos franskt certifieringsorgan under nummer PP/9911

To be defined

Tillverkare av fordonsenheter skall se till att ansvarsfördelningen under tillverkning görs på ett sätt varvid IT-säkerheten upprätthålls, och att fordonsenheten under tillverkning skyddas mot fysisk åverkan som kan äventyra IT-säkerheten.

To Be Defined

Tillverkare av rörelsesensorer skall se till att ansvarsfördelningen under tillverkning görs på ett sådant sätt att IT-säkerheten upprätthålls, och att rörelsesensorn under tillverkning skyddas mot fysiska angrepp som kan äventyra IT-säkerheten

To Be Defined

Tillägg 11

GEMENSAMMA SÄKERHETSMEKANISMER

INNEHÅLL

1. Allmänt 238

1.1 Referenser 238

1.2 Beteckningar och förkortningar 239

2. Kryptosystem och algoritmer 240

2.1 Kryptosystem 240

2.2 Kryptografiska algoritmer 240

2.2.1 RSA-algoritm 240

2.2.2 Hashalgoritm 240

2.2.3 Datakrypteringsalgoritm 240

3. Nycklar och certifikat 240

3.1 Genering och distribuering av nycklar 240

3.1.1 Genering och distribuering av RSA-nycklar 240

3.1.2 RSA-nycklar för provning 242

3.1.3 Nycklar för rörelsesensorer 242

3.1.4 Genering och distribuering av sessionsnycklar för T-DES 242

3.2 Nycklar 242

3.3 Certifikat 242

3.3.1 Certifikatens innehåll 243

3.3.2 Utfärdade certifikat 244

3.3.3 Verifiering och uppackning av certifikat 245

4. Ömsesidig autentiseringsmekanism 245

5. Mekanismer för sekretess, integritet och autentisering vid överföring av data från fordonsenhetskort 248

5.1 Säker meddelandehantering 248

5.2 Behandling av feld vid säker meddelandehantering 249

5.3 Algoritm för beräkning av kryptografiska kontrollsummor 250

5.4 Algoritm för att beräkna kryptogram för sekretessdataobjekt 250

6. Mekanismer för digital signatur vid dataöverföring 251

6.1 Signaturgenerering 251

6.2 Verifiering av signatur 251

1. Allmänt

I detta tillägg specificeras de säkerhetsmekanismer som skall säkerställa följande:

— Ömsesidig autentisering mellan fordonsenhet och färdskrivarkort, inbegripet överenskommelse om sessionsnycklar.

— Sekretess i, integritet hos, och autentisering av data som överförs mellan fordonsenhet och färdskrivarkort.

— Integritet och autenticitet hos data som överförs från fordonsenhet till externa lagringsmedia.

— Integritet och autenticitet hos data som överförs från färdskrivarkort till externa lagringsmedia.

1.1 Referenser

Följande referenser används i detta tillägg:

SHA-1 National Institute of Standards and Technology (NIST). FIPS Publication 180-1: Secure Hash Standard. april 1995 PKCS1 RSA Laboratories. PKCS # 1: RSA Encryption Standard Version 2.0. Oktober 1998 TDES National Institute of Standards and Technology (NIST). FIPS Publication 46-3: Data Encryption Standard. Draft 1999 TDES-OP ANSI X9.52, Triple Data Encryption Algorithm Modes of Operation. 1998 ISO/IEC 7816-4 Transaktionskort - Aktivt kort - Part 4: Gemensamma kommandon för datautbyte. Första utgåvan: 1995 + Ändring 1: 1997. ISO/IEC 7816-6 Identifikationskort - Aktivt Gemensamma dataelement. Första utgåvan: 1996 + Cor 1: 1998 ISO/IEC 7816-8 Information Technology - Identification cards - Integrated circuit(s) cards with contacts - Part 8: Security related interindustry commands. First edition 1999 ISO/IEC 9796-2 Information Technology - Security techniques - Digital signature schemes giving message recovery - Part 2: Mechanisms using a hash function. First edition: 1997 ISO/IEC 9798-3 Dataskydd - Teknik för äkthetsbestyrkande Användning av algoritm för öppen nyckel. Andra utgåvan 1998 ISO 16844-3 Road vehicles - Tachograph systems - Part 3: Motion Sensor Interface

1.2 Beteckningar och förkortningar

Följande beteckningar och förkortningar används i detta tillägg:

(Ka, Kb, Kc) En nyckelknippa som skall användas av Triple Data krypteringsalgoritm CA Certification Authority - Certifieringsinstans CAR Certification Authority reference - Certifieringsinstansens referens CC Cryptographic Checksum - Kryptografisk kontrollsumma CG Cryptogram - Kryptogram CH Command Header - Kommandohuvud CHA Certificate Holder Authorisation - Auktorisering av certifikatinnehavaren CHR Certificate Holder Reference - Certifikatinnehavarens referens D() Decryption with DES - Dekryptering med DES DE Data element - Dataelement DO Data object - Dataobjekt d RSA private key, private exponent - Privat RSA-nyckel, privat exponent e Öppen RSA-nyckel, öppen exponent E() Encryption with DES - DES-kryptering EQT Equipment - Utrustning Hash() Hashvärde, ett resultat av Hash Hash Hashfunktion KID Key Identifier - Nyckelidentifierare Km TDES-nyckel. Huvudnyckel enligt definitionen i ISO 16844-3 Kmvu TDES-nyckel i fordonsenheterna Kmwc TDES-nyckel i verkstadskorten m Message representative, integer mellan 0 och n-1 n RSA-keys, modulus - RSA-nycklar, modulus PB Padding Bytes - Utfyllnads-bytes PI Padding Indicator byte (for use in Cryptogram for confidentiality DO - Utfyllnadsindikator-byte (för användning i kryptogram för sekretessdataobjekt) PV Plain Value - Klarvärde s Signature representative, integer mellan 0 och n-1 SSC Send Sequence Counter SM Secure Messaging - Säker meddelandehantering TCBC TDEA Cipher Block Chaining Mode of Operation TDEA Triple Data Encryption Algorithm - Triple data krypteringsalgoritm TLV Tag Length Value - Tagglängd VU Vehicle Unit - Fordonsenhet X.C Användare X certifikat som utfärdats av en certifieringsinstans X.CA Användare X certifieringsinstans X.CA.PKoX.C Uppackning av ett certifikat för att extrahera en öppen nyckel. Det är en infix-operatör, vars vänstra operand är en certifieringsinstans öppna nyckel och vars högra operand är det certifikat som utfärdats av denna certifieringsinstans. Resultatet är den öppna nyckeln hos användare X, vars certifikat är den högra operanden X.PK Användare X öppna RSA-nyckel X.PK[I] RSA-kryptering av viss information I, med användning av användare X öppna nyckel X.SK Användare X privata RSA-nyckel X.SK[I] RSA-kryptering av viss information I, med användning av användare X öppna nyckel ′xx′ Ett hexadecimalt värde || Concatenation operator - Sammansättningsoperatör

2. KRYPTOSYSTEM OCH ALGORITMER

2.1 Kryptosystem

CSM_001

Fordonsenheter och färdskrivarkort skall använda ett klassiskt RSA-kryptosystem med öppna nycklar för att tillhandahålla följande säkerhetsmekanismer:

— Autentisering mellan fordonsenheter och kort.

— Transport av Triple DES-sessionsnycklar mellan fordonsenheter och färdskrivarkort.

— Digital signatur för data som överförs från fordonsenheter eller färdskrivarkort till externa media.

CSM_002

Fordonsenheter och färdskrivarkort skall använda ett symmetriskt Triple DES-kryptosystem för att tillhandahålla en mekanism för dataintegritet vid datautbyte mellan fordonsenheter och färdskrivarkort, och för att i förekommande fall tillhandahålla sekretessbelagt datautbyte mellan fordonsenheter och färdskrivarkort.

2.2 Kryptografiska algoritmer

2.2.1 RSA-algoritm

CSM_003

RSA-algoritmen definieras fullständigt genom följande förhållanden:

En utförligare beskrivning av RSA-funktionen finns i referens [PKCS1].

Den öppna exponenten, e, för RSA-beräkningar kommer att ha ett annat värde än 2 i alla genererade RSA-nycklar.

2.2.2 Hashalgoritm

CSM_004

Mekanismerna för digital signatur skall använda hashalgoritmen SHA-1, som definieras i referens [SHA-1].

2.2.3 Datakrypteringsalgoritm

CSM_005

DES-baserade algoritmer skall användas vid Cipher Block Chaining mode of operation.

3. NYCKLAR OCH CERTIFIKAT

3.1 Generering och distribuering av nycklar

3.1.1 Generering och distribuering av RSA-nycklar

CSM_006

RSA-nycklar skall genereras med hjälp av följande tre hierarkiska funktionsnivåer:

— Europeisk nivå.

— Medlemsstatsnivå.

— Utrustningsnivå.

CSM_007

På europeisk nivå skall ett enda europeiskt nyckelpar (EUR.SK och EUR.PK) genereras. Den europeiska privata nyckeln skall användas för att certifiera medlemsstaternas öppna nycklar. Ett register skall föras över alla certifierade nycklar. Dessa uppgifter skall utföras av en europeisk certifieringsinstans, under Europeiska kommissionens överinseende och ansvar.

CSM_008

På medlemsstatsnivå skall ett nyckelpar för medlemsstaten (MS.SK och MS.PK) genereras. Medlemsstaternas öppna nycklar skall certifieras av den europeiska certifieringsinstansen. En medlemsstats privata nyckel skall användas för att certifiera de öppna nycklar som skall sättas i utrustningen (fordonsenhet eller färdskrivarkort). Alla certifierade öppna nycklar skall registreras med identifiering av den utrustning som de är avsedda för. Dessa uppgifter skall utföras av en certifieringsinstans i medlemsstaten. En medlemsstat får regelbundet byta sitt nyckelpar.

CSM_009

På utrustningsnivå skall ett enda nyckelpar (EQT.SK och EQT.PK) genereras och sättas in i varje utrustning. Öppna utrustningsnycklar skall certifieras av en medlemsstats certifieringsinstans. Dessa uppgifter får utföras av tillverkare av utrustningar, dem som anpassar utrustningar, eller medlemsstaternas myndigheter. Detta nyckelpar används för autentisering, digital signering och kryptering.

CSM_010

Sekretessen för privata nycklar skall bibehållas vid generering, eventuell transport och lagring.

I följande figur sammanfattas dataflödet i denna process:

3.1.2 RSA-nycklar för provning

CSM_011

För att prova utrustning (även med avseende på driftskompatibilitet) skall den europeiska certifieringsinstansen generera ett annat enda europeiskt nyckelpar för provning och minst två medlemsstatsnyckelpar för provning, vars öppna nycklar skall certifieras med den europeiska privata provningsnyckeln. I utrustning som provas för typgodkännande skall tillverkarna sätta i provningsnycklar som certifierats av en av dessa medlemsstatsnycklar för provning.

3.1.3 Nycklar för rörelsesensorer

Sekretessen för de tre nedannämnda TDES-nycklarna skall bibehållas på lämpligt sätt vid generering, eventuell transport och lagring.

Som stöd för färdskrivare som uppfyller bestämmelserna i ISO 16844 skall den europeiska certifieringsinstansen och medlemsstatens certifieringsinstanser dessutom garantera följande:

CSM_036

Den europeiska certifieringsinstansen skall generera KmVU och KmWC två oberoende och unika nycklar för Triple DES, och generera Km som:

Den europeiska certifieringsinstansen skall överlämna dessa nycklar på ett säkert sätt till medlemsstaternas certifieringsinstanser på de senares begäran.

CSM_037

Medlemsstaternas certifieringsinstanser skall:

— använda Km för att kryptera de rörelsesensordata som efterfrågas av rörelsesensortillverkarna (de data som skall krypteras med Km definieras i ISO 16844-3),

— överlämna KmVU till fordonsenhetstillverkarna på ett säkert sätt för installation i fordonsenheterna, och

— se till att KmWC kommer att installeras i alla verkstadskort (SensorInstallationSecData i datafilen Sensor_Installation_Data) då kortet anpassas till användaren.

3.1.4 Generering och distribuering av sessionsnycklar för T-DES

CSM_012

Fordonsenheter och färdskrivarkort skall som en del av den ömsesidiga autentiseringen generera och utbyta nödvändiga data för att utveckla en gemensam sessionsnyckel för Triple DES. Detta utbyte av data skall sekretesskyddas genom en mekanism för RSA-kryptering.

CSM_013

Denna nyckel skall användas för all efterföljande kryptografisk verksamhet där säker meddelandehantering (secure messaging) används. Dess giltighet skall gå ut när sessionen avslutas (urtagning eller nollställning av kortet) och/eller efter 240 användningar (en användning av nyckeln = ett kommando som med säker meddelandehantering sänds till kortet och åtföljande svar).

3.2 Nycklar

CSM_014

RSA-nycklar skall (oavsett nivå) ha följande längd: modulus n 1024 bits, öppen exponent e maximalt 64 bits, privat exponent d 1024 bits.

CSM_015

Triple DES-nycklar skall ha formen (Ka, Kb, Ka), där Ka och Kb är oberoende 64 bits långa nycklar. Inga bits för påvisande av paritetsfel skall ställas.

3.3 Certifikat

CSM_016

Certifikat för öppna RSA-nycklar skall vara icke-självbeskrivande (non self-descriptive) kortverifierbara (Card Verifiable) certifikat (Ref.: ISO/IEC 7816-8)

3.3.1 Certifikatens innehåll

CSM_017

Certifikat för öppna RSA-nycklar byggs med följande data i följande ordning:

Data Format Bytes Anmärkningar CPI INTEGER 1 Identifierare av certifikatprofil (Certificate Profile Identifier - CPI) (′01′ för denna version) CAR OCTET STRING 8 Certifieringsinstansens referens (CAR) CHA OCTET STRING 7 Certifikatinnehavarens auktorisering EOV TimeReal 4 Sista giltighetsdag för certifikatet. Valbar, ′FF′ utfylld om ej använd CHR OCTET STRING 8 Certifikatinnehavarens referens (CHR) n OCTET STRING 128 Öppen nyckel (modulus) e OCTET STRING 8 Öppen nyckel (öppen exponent) 164

Anmärkningar:

1. Identifieraren av certifikatprofil (certificate Profile Identifier - CPI) beskriver autentiseringscertifikatets exakta struktur. Den kan användas som en intern identifierare för utrustningen av en relevant headerlist som beskriver sammansättningen av dataelement inom certifikatet. Den headerlist som associeras med detta certifikatinnehåll ser ut på följande sätt:

2. Certifieringsinstansens referens (CAR) har som syfte att identifiera den certifieringsinstans (CA) som utfärdar certifikat på så sätt att dataelementet kan användas samtidigt som en identifierare av instansnyckel (Authority Key Identifier) för att förse certifieringsinstansens öppna nyckel med hänvisningar (för kodning, se nyckelidentifierare (Authority Key Identifier) nedan).

3. Certifikatinnehavarens auktorisering (Certificate Holder Authorisation - CHA) används för att identifiera certifikatinnehavarens rättigheter. Det består av färdskrivarens tillämpningsidentifiering (Application ID) och av den typ av utrustning för vilken certifikatet är avsett (enligt dataelementet EquipmentType ′00′ för en medlemsstat).

4. Certifieringsinnehavarens referens (CHR) har som syfte att unikt identifiera certifieringsinnehavaren (CH) på så sätt att dataelementet kan användas samtidigt som en identifierare av subjektnyckel (Subject Key Identifier) för att förse certifikatinnehavarens öppna nyckel med hänvisningar.

5. Med nyckelidentifierare identifieras certifikatinnehavaren eller certifieringsinstanserna unikt. De är kodade på följande sätt: 5.1. Utrustning (fordonsenhet (VU) eller kort): Data Utrustningens serienummer Datum Typ Tillverkare Längd 4 Bytes 2 Bytes 1 Byte 1 Byte Värde INTEGER mm åå BCD-kodning Tillverkarspecifik Tillverkarens kod När det gäller en fordonsenhet (VU) får tillverkaren vid förfrågan om certifikat ha eller inte ha kunskap om identifieringen av den utrustning i vilken nycklarna sätts i. I det förra fallet kommer tillverkaren att sända utrustningens identifiering med den öppna nyckeln till sin medlemsstats certifieringsinstans. Certifikatet kommer då att innehålla utrustningens identifiering, och tillverkaren måste se till att nycklar och certifikat isätts i avsedd utrustning. Nyckelidentifieraren har den form som visas ovan. I det senare fallet måste tillverkaren unikt identifiera varje certifikatförfrågan och sända denna identifiering med den öppna nyckeln till sin medlemsstats certifieringsinstans. Certifikatet kommer att innehålla identifiering av förfrågan. Tillverkaren måste meddela sin medlemsstats instans med tilldelning av nyckel till utrustning (dvs. identifiering av certifikatförfrågan, utrustningens identfiering) efter installation av nyckeln i utrustningen. Nyckelidentifieraren har följande form: Data Serienummer för förfrågan om certifikat Datum Typ Tillverkare Längd 4 Bytes 2 Bytes 1 Byte 1 Byte Värde BCD-kodning mm åå BCD-kodning ′FF′ Tillverkarens kod

5.2. Certifieringsinstans ( certification Authority ) Data Instans-ID Nyckelns serienummer Övrig information Identifierare Längd 4 Bytes 1 Byte 2 Bytes 1 Byte Värde 1 Byte numerisk landskod Integer Övrig kodning (CA-specific) ′01′ 3 Bytes alfanumerisk landskod ′FF FF′ om den inte används Nyckelns serienummer används för att man skall kunna skilja en medlemsstats olika nycklar åt om nyckeln ändras.

6. Certifikatverifierare skall indirekt känna till att den certifierade öppna nyckeln är en RSA-nyckel som är relevant för autentisering, verifiering av digital signatur och kryptering för sekretesstjänster (certifikatet innehåller ingen objektidentifierare som specificerar den).

3.3.2 Utfärdade certifikat

CSM_018

Det utfärdade certifikatet är en digital signatur med delvis återskapning av certifikatinnehåll enligt ISO/IEC 9796-2, med certifieringsinstansens referens (Certification Authority Reference - CAR) tillfogad.

Med certifikatinnehåll

Anmärkningar:

1. Detta certifikat är 194 bytes långt.

2. CAR, som är dold av underskriften och är också tillfogad till signaturen, så att certifieringsinstansens öppna nyckel kan väljas för verifiering av certifikatet.

3. Certifikatverifieraren skall indirekt känna till den algoritm som används av certifieringsinstansen för att signera certifikatet.

4. Den headerlist som associeras med detta utfärdade certifikat ser ut på följande sätt:

3.3.3 Verifiering och uppackning av certifikat

Verifiering och uppackning består i att underskriften verifieras enligt ISO/IEC 9796-2, och att certifikatinnehållet och den öppna nyckeln däri hämtas: X.PK = X.CA.PKo X.C, och verifiering av certifikatets giltighet.

CSM_019

Detta inbegriper följande steg:

Verifiera signatur och hämta innehåll: — from X.C retrieve Sign, Cn′ and CAR′: — from CAR' select appropriate Certification Authority Public Key (if not done before through other means) — open Sign with CA Public Key : Sr' = X.CA.PK [Sign], — check Sr' starts with ′6A′ and ends with ′BC′ — compute Cr′ and H′ from: — Recover certificate content C′ = Cr′ || Cn′, — check Hash(C′) = H′

Om kontrollerna är OK är certifikatet äkta och dess innehåll är C′.

Verifiera giltighet. Från C′: — om tillämpligt, kontrollera sista giltighetsdag,

Hämta och lagra öppen nyckel, nyckelidentifierare, certifikatinnehavarens auktorisering (CHA) och certifikatets sista giltighetsdag från C′: — X.PK = n || e — X.KID = CHR — X.CHA = CHA — X.EOV = EOV

4. ÖMSESIDIG AUTENTISERINGSMEKANISM

Ömsesidig autentisering mellan kort och fordonsenheter (VUs) bygger på följande princip:

Varje part skall demonstrera för den andra att den äger ett giltigt nyckelpar, vars öppna nyckel har certifierats av en certifieringsinstans i en medlemsstat, som i sin tur har certifierats av den europeiska certifieringsinstansen.

Detta görs genom att man med den privata nyckeln signerar med ett slumptal som sänts av den andra parten, som måste återskapa det sända slumptalet när signaturen verifieras.

Mekanismen utlöses av fordonsenheten (VU) när kortet sätts i. Den börjar med utbyte av certifikat och uppackning av öppna nycklar och slutar med inställning av en sessionsnyckel.

CSM_020

Följande protokoll skall användas (pilar anger kommandon och data som byts ut (se tillägg 2)):

5. MEKANISMER FÖR SEKRETESS, INTEGRITET OCH AUTENTISERING VID ÖVERFÖRING AV DATA FRÅN FORDONSENHETSKORT

5.1 Säker meddelandehantering

CSM_021

Integriteten hos överföring av data från fordonsenhetskort skall skyddas genom säker meddelandehantering (secure messaging) enligt referenserna [ISO/IEC 7816-4] och [ISO/IEC 7816-8].

CSM_022

När data behöver skyddas vid överföring skall ett kryptografiskt kontrollsummedataobjekt (Cryptographic Checksum Data Object) fogas till de dataobjekt som sänds inom kommandot eller svaret. Den kryptografiska kontrollsumman (Cryptographic Checksum) skall verifieras av mottagaren.

CSM_023

Den kryptografiska kontrollsumman hos data som sänds inom ett kommando skall integrera kommandohuvudet (command header), och alla sända dataobjekt (= > CLA = ′0C′, och alla dataobjekt skall kapslas in med taggar i vilka b1 = 1).

CSM_024

Bytes för information om svarets status skall skyddas av en kryptografisk kontrollsumma om svaret inte innehåller något datafält.

CSM_025

Kryptografiska kontrollsummor skall vara 4 Bytes långa.

Strukturen på kommandon och svar vid användning av säker meddelandehantering är därför följande:

De dataobjekt som används är en delmängd (partial set) av de dataobjekt vid säker meddelandehantering som beskrivs i ISO/IEC 7816-4: Tag Mnemonic Meaning ′81′ TPV Plain Value not BER-TLV coded data (to be protected by CC) ′97′ TLE Value of Le in the unsecured command (to be protected by CC) ′99′ TSW Status-Info (to be protected by CC) ′8E′ TCC Cryptographic Checksum (CC) ′87′ TPI CG Padding Indicator Byte || Cryptogram (Plain Value not coded in BER-TLV)

Med ett okrypterat kommandosvarspar: Command header Command body CLA INS P1 P2 [Lc-field [Data field] [Le-field] four bytes L bytes, denoted as B1 to BL Response body Response trailer [Data field] SW1 SW2 Lr data bytes two bytes

Det motsvarande krypterade kommandosvarsparet är:

Krypterat kommando: Command header (CH) Command body CLA INS P1 P2 [New Lc-field] [New Data field] [New Le-field] ′OC′ Length of New Data field TPV LPV PV TLE LLE Le TCC LCC CC ′00′ ′81′ Lc Data field ′97′ ′01′ Le ′8E′ ′04′ CC Data som skall integreras i kontrollsumman = CH || PB || TPV || LPV || PV || TLE || LLE || Le || PB PB = Padding Bytes (utfyllnads-bytes) (80 .. 00) enligt ISO-IEC 7816-4 und ISO 9797, metod 2. Dataobjektens klarvärde (PV) och LE är närvarande endast när det finns motsvarande data i det okrypterade kommandot.

Krypterat svar: 1. Response body Response trailer [New Data field] new SW1 SW2 TPV LPV PV TCC LCC CC ′81′ Lr Data field ′8E′ ′04′ CC Data som skall integreras i kontrollsumman = TPV || LPV || PV || PB 2. Response body Response trailer [New Data field] new SW1 SW2 TPI CG LPI CG PI CG TCC LCC CC ′87′ PI || CG ′8E′ ′04′ CC Data som skall överföras av CG: icke BER-TLV-kodade data och utfyllnads-bytes. Data som skall integreras i kontrollsumman = TPI CG || LPI CG || PI CG || PB 3. Response body Response trailer [New Data field] new SW1 SW2 TSW LSW SW TCC LCC CC ′99′ ′02′ New SW1 SW2 ′8E′ ′04′ CC Data som skall integreras i kontrollsumman = TSW || LSW || SW || PB

5.2 Behandling av fel vid säker meddelandehantering

CSM_026

När färdskrivarkortet känner av ett fel vid säker meddelandehantering vid tolkning av ett kommando måste status bytes returneras utan säker meddelandehantering. Enligt ISO/IEC 7816-4 definieras följande status bytes för angivelse av fel vid säker meddelandehantering:

′66 88′ Verification of Cryptographic Checksum failed, ′69 87′ Expected SM Data Objects missing, ′69 88′ SM Data Objects incorrect.

CSM_027

När färdskrivarkoret returnerar status bytes utan SM-dataobjekt eller med ett felaktigt SM-dataobjekt måste sessionen avbrytas av fordonsenheten.

5.3 Algoritm för beräkning av kryptografiska kontrollsummor

CSM_028

Kryptografiska kontrollsummor byggs med användning av en retail MACs enligt ANSI X9.19 med DES:

— Initial stage: The initial check block y0 is E(Ka, SSC).

— Sequential stage: The check blocks y1, .. , yn are calculated using Ka.

— Final stage: The cryptographic checksum is calculated from the last check block yn as follows: E(Ka, D(Kb, yn)).

där E() betyder kryptering med DES, och D() betyder dekryptering med DES.

De fyra mest signifikanta bytes i den kryptografiska kontrollsuman överförs.

CSM_029

Send Sequence Counter (SSC) skall initieras vid förfarandet för överenskommelse om nyckel till:

Initial SSC: Rnd3 (4 least significant bytes) || Rnd1 (4 least significant bytes).

CSM_030

Send Sequence Counter skall ökas med 1 varje gång innan en MAC beräknas (dvs. SSC för första kommando är Initial SSC + 1, SSC för det första svaret är Initial SSC + 2).

I följande figur visas beräkningen av retail MAC:

5.4 Algoritm för att beräkna kryptogram för sekretessdataobjekt

CSM_031

Kryptogram beräknas med hjälp av TDEA i driftläge TCBC enligt referenserna [TDES] och [TDES-OP] och med nollvektorn som Initial Value block.

I följande figur visas tillämpningen av nycklar i TDES:

6. MEKANISMER FÖR DIGITAL SIGNATUR VID DATAÖVERFÖRING

CSM_032

Intelligent Dedicated Equipment (IDE) lagrar data som tas emot från en utrustning (fordonsenhet eller kort) under en överföringssession inom en fysisk datafil. Filen måste innehålla certifikaten MSi.C och EQT.C. Filen innehåller digitala signaturer av datamängder enligt specifikation i tillägg 7 Protokoll för dataöverföring.

CSM_033

Digitala signaturer för överförda data skall använda ett schema för digitala signaturer med tillägg så att överförda data kan läsas utan att dekrypteras om så önskas.

6.1 Signaturgenerering

CSM_034

Utrustningens generering av datasignaturer skall följa det signaturschema med tillägg som definieras i referens [PKCS1] med SHA-1 hashfunktion:

Signature = EQT.SK[′00′ || ′01′ || PS || ′00′ || DER(SHA-1(Data))]

PS= Padding string of octets with value ′FF′, such that length is 128.

DER(SHA-1(M)) is the encoding of the algorithm ID for the hash function and the hash value into an ASN.1 value of type DigestInfo (distinguished encoding rules):

′30′||′21′||′30′||′09′||′06′||′05′||′2B′||′0E′||′03′||′02′||′1A′||′05′||′00′||′04′||′14′||Hash-Value.

6.2 Verifiering av signatur

CSM_035

Verifiering av datasignaturer för överförda data skall följa det signaturschema med tillägg som definieras i referens [PKCS1] med SHA-1 hashfunktion:

Den som verifierar måste oberoende känna till (och lita på) den europeiska öppna nyckeln EUR.PK.

Följande tabell illustrerar det protokoll som en IDE med ett kontrollkort kan följa för att verifiera integriteten hos data som överförs och lagras på externa lagringsmedia (ESM). Kontrollkortet används för att dekryptera digitala signaturer. Denna funktion får i detta fall inte genomföras i IDE.

Den utrustning som har överfört och signerat de data som skall analyseras betecknas EQT.