Spookfiles A58
SRSSSD PKI infrastructure
Spookfiles A58
SRSSDD PKI infrastructure
14 October 2015Document version: 1.2
Spookfiles A58
SRSSSD PKI infrastructure
Documentinformatie
Title: SRSSSD PKI infrastructure
Version: 1.2
Date: 14-10-2015
Project: Spookfiles A58
Document versions:
Version / Data / Author / Comments1.0 / 10-07-2015 / W Nouwens / First release
1.1 / 2-10-2015 / W Nouwens / Editorial changes
Ready for review
1.2 / 14-10-2015 / W Nouwens / Updated after review
Content
1. Introduction 3
1.1 Background 3
1.2 Scope 4
2. References 5
3. Requirements 6
3.1 Supported algorithms 6
3.2 Root Certificate Authority 6
3.3 Pseudo Certificate authority 7
3.4 Pseudo Certificates 8
4. DESIGN 10
4.1 Overview 10
4.2 Functional design 10
4.2.1 general 10
4.2.2 Datatypes 12
4.2.3 Main 12
4.2.4 certificate authority (ca) 13
4.2.5 Pseudo certificates (pseudo) 15
4.2.6 File formats 16
5. Deployment 17
5.1 General 17
5.2 Software 17
5.3 Directory structure 17
6. Qualification 18
7. Tracebility 19
8. Abbreviations & Concepts 20
8.1 Abbreviations 20
8.2 Concepts 20
1. Introduction
1.1 Background
The A58 spookfile project wants to use signing of ITS G5 messages for authentication of the messages. This requires a Public Key Infrastructure (PKI) for generating the certificates that make up the chain of trust.
ETSI describes in their security architecture a proposal for the PKI infrastructure [see TS 102 731, TS102 940 & TS 102 941].
Figure 1 ETSI security model
In the A58 spookfile project it was decide to implement a limited version of the Public Key Infrastructure known in the project as “the friendly chain of trust”. Only the Authorization Authority (also known as the pseudo certificate authority) and a Root Certificate Authority are used. The certificates for the vehicles and roadside units (RSU) are generated at the beginning of the project valid for the duration of the project. The enrolment part of the procedure is not used in the A58 spookfile project. Also the automatic certificate request procedures will not be used but the installation of the pseudo certificates will be done manually using files..
1.2 Scope
The PKI implementation for the A58 spookfile project is focused on getting experience with the security and privacy issues for the communication between ITS stations.
In scope of this document are:
· Providing tooling for the root authority certificate to be used in the project.
· Providing tooling for one or more pseudo authority (authorization authority) certificates to be used in the project.
· Providing tooling for generating a set of pseudo certificates to be used by vehicles/RSUs in this project.
· Describing the import/export mechanism for public/private keys and certificates to be used in the project.
· Implementation of the import of public keys from the ITS devices.
· Implementation of the export of root certificates, pseudo authority certificates and the generated set of pseudo certificates and optionally private keys.
· Documentation on design and usage of the PKI tooling
Out of scope of this document are:
· The enrolment part as described in the ETSI security architecture.
· The automatic request procedures as described in the ETSI security architecture.
· The procedures for using the PKI infrastructure in the A58 spookfile project.
This will be a separate document [PROC].
· The generation of private/public key pair for the device. The Certificate authority normally only signs the certificates containing the public key but does not generate the key pairs.
· The implementation of the export of the public keys from the ITS devices.
· The implementation of the import of the certificates and optionally the private keys by the ITS devices.
2. References
ID / Reference[JSTD] / J-STD-016-1995 Standard for Information Technology, Software Life Cycle Processes, Software Development,
Acquirer-Supplier Agreement
TS 103 097 / Intelligent Transport Systems (ITS);
Security;
Security header and certificate formats
Draft v 1.1.18 (2015-01)
SSSD PKI / SSDD PKI structuur
Percelen 2,3
V0.6, Oktober 2014
TS 102 731 / Intelligent Transport Systems (ITS);
Security;
Security Services and Architecture
ETSI TS 102 731, v1.1.1 (2010- 09)
TS 102 940 / Intelligent Transport Systems (ITS);
Security;
ITS communications security architecture and
security management
ETSI TS 102 940 v1.1.1 (2012-06)
TS 102 941 / Intelligent Transport Systems (ITS);
Security;
Trust and Privacy Management
ETSI TS 102 941 v1.1.1 (2012-06)
PROC / Spookfiles A58
Procedures PKI CA
Version 1.0
ACF / Aerolink Credential File format
Version 1.2 – 25 November 2014
3. Requirements
3.1 Supported algorithms
Req-ID / SRS-PKI-001Title / Key algorithm
Description / The system shall use the Elliptic Curve Digital Signature Algorithm with curve NIST P-256 (ECDSA p-256).
See [TS 103 097].
Source
Comment
Req-ID / SRS-PKI-002
Title / Signing algorithm
Description / The system shall use the Elliptic Curve Digital Signature Algorithm with curve NIST P-256 and Secure Hashing Algorithm with hash size 256.
See [TS 103 097].
Source
Comment
3.2 Root Certificate Authority
Req-ID / SRS-PKI-003Title / Generation of a root certificate authority
Description / The system must be able to generate a public/private key pair for the root certificate authority (root CA).
Source
Comment
Req-ID / SRS-PKI-004
Title / Storage of root certificate authority key information
Description / The private key belong to the root certificate authority must be safely stored.
Source
Comment
Req-ID / SRS-PKI-005
Title / Generation of a certificate for the root certificate authority
Description / The system must be able to generate a self-signed certificate for the root CA.
Source
Comment
Req-ID / SRS-PKI-006
Title / Export of the certificate for the root certificate authority
Description / The system must be able to export the certificate of the root CA.
Source
Comment
Req-ID / SRS-PKI-007
Title / Format of root authority certificate
Description / The system must support root CA certificate format as specified by ETSI [TS 103 097]
Source
Comment
3.3 Pseudo Certificate authority
Req-ID / SRS-PKI-008Title / Generation of a pseudo certificate authority
Description / The system must be able to generate a public/private key pair for the pseudo certificate authority (PCA).
The keys are generated for use with the ECDSA NIST-p256 algorithm (see TS 103 097)
Source
Comment
Req-ID / SRS-PKI-009
Title / Storage of pseudo certificate authority key information
Description / The private key belong to the pseudo certificate authority must be safely stored
Source
Comment
Req-ID / SRS-PKI-010
Title / Generation of a certificate for the pseudo certificate authority
Description / The system must be able to generate certificate for the PCA signed by the root CA
Source
Comment
Req-ID / SRS-PKI-011
Title / Export of the certificate for the pseudo certificate authority
Description / The system must be able to export the certificate of the PCA.
Source
Comment
Req-ID / SRS-PKI-012
Title / Format of the pseudo certificate authority
Description / The system must support PCA certificate format as specified by ETSI [TS 103 097]
Source
Comment
Req-ID / SRS-PKI-013
Title / Support for multiple pseudo certificate authorities
Description / The system must be able to support multiple PCA’s
Source
Comment
3.4 Pseudo Certificates
Req-ID / SRS-PKI-014Title / Generation of pseudo certificates from set of public keys
Description / The system must be able to generate a set of certificates signed by a specified PCA for a given set of public key of one ITS station
Source
Comment
Req-ID / SRS-PKI-016
Title / Format of pseudo certificate
Description / The system must support pseudo certificate format as specified by ETSI [TS 103 097]
Source
Comment
Req-ID / SRS-PKI-017
Title / Format of pseudo Certificate export
Description / The certificates are exported in ACF format [ACF] or in HEX based format (see APPENDIX B)
Source
Comment
Req-ID / SRS-PKI-018
Title / Format of pseudo public key import
Description / The pseudo certificate request (including the public key) are inported in HEX based format (see APPENDIX A)
Source
Comment
Req-ID / SRS-PKI-019
Title / Import of public pseudo keys
Description / The system must have a mechanism to import the public pseudo keys from the ITS stations
Source
Comment
Req-ID / SRS-PKI-020
Title / Export and pseudo certificates
Description / The system must have a mechanism to export pseudo certificates.
Source
Comment
Req-ID / SRS-PKI-021
Title / Certificate lifetime
Description / A set of pseudo certificates will be generated for each vehicle device. The certificate will specify the validity fo the certificate.
Source
Comment
Req-ID / SRS-PKI-022
Title / Storage of public keys
Description / The system shall store the generated and/or imported pseudo public keys. This allows for generation of new pseudo certificates for exiting pseudo private/public key pairs.
Source
Comment
Req-ID / SRS-PKI-023
Title / Support of authorisation information
Description / The system must include authorisation information in the Service Specific Permission fields (ssp) of the pseudo certificate
Source
Comment
Req-ID / SRS-PKI-024
Title / Support of multiple profiles
Description / The system must be able to generate multiple profiles with authorisation information. E.g. A profile as a normal vehicle and a profile as an emergency vehicle.
Source
Comment
4. DESIGN
4.1 Overview
The PKI infrastructure consists of the tool for generating the certificates, definitions of the formats used to exchange the certificates between the tool and the ITS devices and the procedures to handle the PKI infrastructure (not described in this document)
The PKI tool must handle several tasks:
1. Creation of a root certificate authority
2. Export of root certificate authority certificate in TS 102 097 format
3. Creation of one or more pseudo certificate authorities signed by the root CA
4. Export of pseudo certificate authority certificates in TS 102 097 format
5. Generation of a set of pseudo certificates in TS 102 097 format signed by a pseudo certificate authority for a given set of public keys.
6. Storage of the imported or generated public keys of the pseudo certificates for later usage (e.g. to generate new certificates with a new end date).
4.2 Functional design
4.2.1 general
The tool will be implemented in Java and will be a command-line tool.
The tool uses the Java Cryptography architecture as described in the java.securtity API.
The ETSI security framework uses Elliptic Curve Digital Signature for signing of messages and certificates. The signing algorithm uses NIST P-256 curves.
The standard java.security API implementation does not support Elliptic Curve cryptography, but the Oracle implementation and the Bouncy Castle Cryptography library do support Elliptic Curve Cryptography and are extensions to on the Java Cryptography architecture.
All actions performed by the tool are logged to an audit file. The entries will contain the date/time, authority, action requested, the result and any relevant parameters for the action.
4.2.1.1 Authority
The tool implements the functions an Authority needs to execute. The tool can handle multiple authorities. When giving a command the user specifies which authority is used.
The authority consist of a keystore for storing key pair and certificates and configuration. An authority can have one or more public/private key pairs.
When using a keystore or private key, the user is prompted for the password or phrase for that store or key.
4.2.1.2 Command structure
The tool is a program which has several sub-commands. Each sub-command will have its own set of parameters. The tool uses the following general command structure:
pki-tool subcommand authority [subcommand-parameters]+
where: subcommand identifies the subcommand e.g. createKey
authority points to the authority configuration data
which is stored in the file
authorities/<authority>.conf
subcommand-parameters
parameters specific for the subcommand
The following sub-commands are identified:
· createKey
Create an public/private key pair for an authority.
· exportPub
Export the public key e.g. for creating a certificate by another tool.
· createCert
Create a certificate for a public key that is stored or imported in the tool. The certificate can be self-signed or sign by an CA of the tool.
· exportCert
Export certificate that is stored or imported in the tool.
· importCert
Imports a (set of) certificate(s) for authorities in the tool.
· genPseudoCert
Generate a set of pseudo certificates that are signed by a pseudo CA of the tool for a given set of public keys
· listCa
List all certificates and keys available in the tool for the given authority
4.2.1.3 Class structure
The main classes used to build this tool are shown in the diagram below.
Figure 2 Class overview
4.2.2 Datatypes
The c2c-common library [see c2c-common] implements the data types as specified in the ETSI TS 102 097 v1.1.1. This project will use the ETSI security specification TS 102 097 v1.1.18. However the c2c-common library is a good starting point for the implementation of the tool.
The library implements version 1 of the Certificate and Payload data structure.
We will use the version 2 of the Certificate
In order to support version 2 of the certificate format, additions are made to supplement the c2c-common library. The c2c-common library is used unchanged.
The c2c-common library is released under the GNU Public licence.
4.2.3 Main
The main package contains the general interfaces and classes used in the tool:
· Main
· Configuration
· Command
4.2.3.1 Main
The Main class initialize the tool and select the sub command and execute the sub command.
The main class checks if it knows the sub command and loads the authority configuration. After this its passes the configuration and the subcommand specific parameters to the subcommand for execution.