Please note that the date you requested in the address for this web page is not an actual date upon which a change occurred to this item of legislation. You are being shown the legislation from , which is the first date before then upon which a change was made.
ANNEX I CU.K. Requirements for construction, testing, installation, and inspection
Appendix 11
COMMON SECURITY MECHANISMS U.K.
PART AU.K. FIRST-GENERATION TACHOGRAPH SYSTEM
3.KEYS AND CERTIFICATESU.K.
3.1. Keys generation and distribution U.K.
3.1.1 RSA Keys generation and distribution U.K.
CSM_006RSA keys shall be generated through three functional hierarchical levels:U.K.
European level,
Member State level,
Equipment level.
CSM_007At European level, a single European key pair (EUR.SK and EUR.PK) shall be generated. The European private key shall be used to certify the Member States public keys. Records of all certified keys shall be kept. These tasks shall be handled by a European Certification Authority, under the authority and responsibility of the European Commission.U.K.
CSM_008At Member State level, a Member State key pair (MS.SK and MS.PK) shall be generated. Member States public keys shall be certified by the European Certification Authority. The Member State private key shall be used to certify public keys to be inserted in equipment (vehicle unit or tachograph card). Records of all certified public keys shall be kept with the identification of the equipment to which it is intended. These tasks shall be handled by a Member State Certification Authority. A Member State may regularly change its key pair.U.K.
CSM_009At equipment level, one single key pair (EQT.SK and EQT.PK) shall be generated and inserted in each equipment. Equipment public keys shall be certified by a Member State Certification Authority. These tasks may be handled by equipment manufacturers, equipment personalisers or Member State authorities. This key pair is used for authentication, digital signature and encipherement servicesU.K.
CSM_010Private keys confidentiality shall be maintained during generation, transport (if any) and storage.U.K.
The following picture summarises the data flow of this process:
3.1.2 RSA Test keys U.K.
CSM_011For the purpose of equipment testing (including interoperability tests) the European Certification Authority shall generate a different single European test key pair and at least two Member State test key pairs, the public keys of which shall be certified with the European private test key. Manufacturers shall insert, in equipment undergoing type approval tests, test keys certified by one of these Member State test keys.U.K.
3.1.3 Motion sensor keys U.K.
The confidentiality of the three Triple DES keys described below shall be appropriately maintained during generation, transport (if any) and storage.
In order to support tachograph components compliant with ISO 16844, the European Certification Authority and the Member State Certification Authorities shall, in addition, ensure the following:
CSM_036The European Certification authority shall generate KmVU and KmWC, two independent and unique Triple DES keys, and generate Km as: Km = KmVU XOR KmWC. The European Certification Authority shall forward these keys, under appropriately secured procedures, to Member States Certification Authorities at their request.U.K.
CSM_037Member States Certification Authorities shall:U.K.
use Km to encrypt motion sensor data requested by motion sensor manufacturers (data to be encrypted with Km is defined in ISO 16844-3),
forward KmVU to vehicle unit manufacturers, under appropriately secured procedures, for insertion in vehicle units,
ensure that KmWC will be inserted in all workshop cards ( in elementary file) during card personalisation.
3.1.4 T-DES session keys generation and distribution U.K.
CSM_012Vehicle units and tachograph cards shall, as a part of the mutual authentication process, generate and exchange necessary data to elaborate a common Triple DES session key. This exchange of data shall be protected for confidentiality through an RSA crypt-mechanism.U.K.
CSM_013This key shall be used for all subsequent cryptographic operations using secure messaging. Its validity shall expire at the end of the session (withdrawal of the card or reset of the card) and/or after 240 use (one use of the key = one command using secure messaging sent to the card and associated response).U.K.
3.2. Keys U.K.
CSM_014RSA keys shall have (whatever the level) the following lengths: modulus n1 024 bits, public exponent e 64 bits maximum, private exponent d1 024 bits.U.K.
CSM_015Triple DES keys shall have the form (Ka, Kb, Ka) where Ka and Kb are independent 64 bits long keys. No parity error detecting bits shall be set.U.K.
3.3. Certificates U.K.
CSM_016RSA Public key certificates shall be ‘non self-descriptive’‘Card Verifiable’ certificates (Ref.: ISO/IEC 7816-8)U.K.
3.3.1 Certificates content U.K.
CSM_017RSA Public key certificates are built with the following data in the following order:U.K.
Data | Format | Bytes | Obs |
---|
CPI | INTEGER | 1 | Certificate Profile Identifier (‘01’ for this version) |
CAR | OCTET STRING | 8 | Certification Authority Reference |
CHA | OCTET STRING | 7 | Certificate Holder Authorisation |
EOV | TimeReal | 4 | Certificate end of validity. Optional, ‘FF’ padded if not used. |
CHR | OCTET STRING | 8 | Certificate Holder Reference |
n | OCTET STRING | 128 | Public key (modulus) |
e | OCTET STRING | 8 | Public Key (public exponent) |
| 164 | |
Notes: U.K.
1.The ‘Certificate Profile Identifier’ (CPI) delineates the exact structure of an authentication certificate. It can be used as an equipment internal identifier of a relevant headerlist which describes the concatenation of Data Elements within the certificate.U.K.
The headerlist associated with this certificate content is as follows:
‘4D’ | ‘16’ | ‘5F 29’ | ‘01’ | ‘42’ | ‘08’ | ‘5F 4B’ | ‘07’ | ‘5F 24’ | ‘04’ | ‘5F 20’ | ‘08’ | ‘7F 49’ | ‘05’ | ‘81’ | ‘81 80’ | ‘82’ | ‘08’ |
Extended Headerlist Tag | Length of header list | CPI Tag | CPI Length | CAR Tag | CAR Length | CHA Tag | CHA Length | EOV Tag | EOV Length | CHR Tag | CHR Length | Public Key Tag (Constructed) | Length of subsequent DOs | modulus Tag | modulus length | public exponent Tag | public exponent length |
|
|
2.The ‘Certification Authority Reference’ (CAR) has the purpose of identifying the certificate issuing CA, in such a way that the Data Element can be used at the same time as an Authority Key Identifier to reference the Public Key of the Certification Authority (for coding, see Key Identifier below).U.K.
3.The ‘Certificate Holder Authorisation’ (CHA) is used to identify the rights of the certificate holder. It consists of the Tachograph Application ID and of the type of equipment to which the certificate is intended (according to data element, ‘00’ for a Member State).U.K.
4.The ‘Certificate Holder Reference’ (CHR) has the purpose of identifying uniquely the certificate holder, in such a way that the Data Element can be used at the same time as a Subject Key Identifier to reference the Public Key of the certificate holder.U.K.
5.Key Identifiers uniquely identify certificate holder or certification authorities. They are coded as follows:U.K.
5.1
Equipment (VU or Card):
Data | Equipment serial number | Date | Type | Manufacturer |
---|
Length | 4 Bytes | 2 Bytes | 1 Byte | 1 Byte |
---|
Value | Integer | mm yy BCD coding | Manufacturer specific | Manufacturer code |
---|
In the case of a VU, the manufacturer, when requesting certificates, may or may not know the identification of the equipment in which the keys will be inserted.
In the first case, the manufacturer will send the equipment identification with the public key to its Member State authority for certification. The certificate will then contain the equipment identification, and the manufacturer must ensure that keys and certificate are inserted in the intended equipment. The Key identifier has the form shown above.
In the later case, the manufacturer must uniquely identify each certificate request and send this identification with the public key to its Member State authority for certification. The certificate will contain the request identification. The manufacturer must feed back its Member State authority with the assignment of key to equipment (i.e. certificate request identification, equipment identification) after key installation in the equipment. The key identifier has the following form:
Data | Certificate request serial number | Date | Type | Manufacturer |
---|
Length | 4 Bytes | 2 Bytes | 1 Byte | 1 Byte |
---|
Value | Integer | mm yy BCD coding | ‘FF’ | Manufacturer code |
---|
5.2
Certification Authority:
Data | Authority Identification | Key serial number | Additional info | Identifier |
---|
Length | 4 Bytes | 1 Byte | 2 Bytes | 1 Byte |
---|
Value | 1 Byte nation numerical code
3 Bytes nation alphanumerical code
| Integer | additional coding
(CA specific)
‘FF FF’ if not used
| ‘01’ |
---|
The key serial number is used to distinguish the different keys of a Member State, in the case the key is changed.
6.Certificate verifiers shall implicitly know that the public key certified is an RSA key relevant to authentication, digital signature verification and encipherement for confidentiality services (the certificate contains no Object Identifier to specify it).U.K.
3.3.2 Certificates issued U.K.
CSM_018The certificate issued is a digital signature with partial recovery of the certificate content in accordance with ISO/IEC 9796-2 (except for its annex A4), with the ‘Certification Authority Reference’ appended.U.K.
X.C = X.CA.SK[‘6A’ || Cr || Hash(Cc) || ‘BC’] || Cn || X.CAR
With certificate content = Cc = | Cr | || | Cn |
| 106 bytes | | 58 bytes |
Notes: U.K.
1.This certificate is 194 bytes long.U.K.
2.CAR, being hidden by the signature, is also appended to the signature, such that the Public Key of the Certification Authority may be selected for the verification of the certificate.U.K.
3.The certificate verifier shall implicitly know the algorithm used by the Certification Authority to sign the certificate.U.K.
4.The headerlist associated with this issued certificate is as follows:U.K.
‘7F 21’ | ‘09’ | ‘5F 37’ | ‘81 80’ | ‘5F 38’ | ‘3A’ | ‘42’ | ‘08’ |
CV Certificate Tag (Constructed) | Length of subsequent DOs | Signature Tag | Signature Length | Remainder Tag | Remainder Length | CAR Tag | CAR Length |
|
3.3.3 Certificate verification and unwrapping U.K.
Certificate verification and unwrapping consists in verifying the signature in accordance with ISO/IEC 9796-2, retrieving the certificate content and the public key contained: X.PK = X.CA.PK o X.C, and verifying the validity of the certificate.
CSM_019It involves the following steps:U.K.
Verify signature and retrieve content:
—from X.C retrieve Sign, Cn' and CAR': | X.C = | Sign | || | Cn' | || | CAR' |
| | 128 Bytes | | 58 Bytes | | 8 Bytes |
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: Sr' = | ‘6A’ | || | Cr' | || | H' | || | ‘BC’ |
| | | 106 Bytes | | 20 Bytes | | |
If the checks are OK the certificate is a genuine one, its content is C'.
Verify validity. From C':
Retrieve and store public key, Key Identifier, Certificate Holder Authorisation and Certificate End of Validity from C':
X.PK = n || e
X.KID = CHR
X.CHA = CHA
X.EOV = EOV