Deliverable D2.2: Specification of security services incl. virtualization and firewall mechanisms

Transcription

1 Project acronym: OVERSEE Project title: Open Vehicular Secure Platform Project ID: Call ID: FP7-ICT Programme: 7th Framework Programme for Research and Technological Development Objective: ICT : ICT for Safety and Energy Efficiency in Mobility Contract type: Collaborative project Duration: to (30 months) Deliverable D2.2: Specification of security services incl. virtualization and firewall mechanisms Authors: Reviewers: Dissemination level: Deliverable type: Jan Holle (Uni Siegen) André Groll (Uni Siegen) Alfons Crespo (UPVLC) Hakan Cankaya (escrypt) Thomas Enderle (escrypt) Nicholas Mc Guire (OpenTech) Andreas Platschek (OpenTech) Hakan Cankaya (escrypt) Thomas Enderle (escrypt) Florian Friederici (FOKUS) Public Version: 1.4 Report Submission date: 3 rd June 2011

2 Abstract This document specifies all capabilities and services of OVERSEE, which are related to security. Thus, it defines a large part of the OVERSEE design since the project has a strong focus on security. Security services that are part of the generic OVERSEE implementation will be depicted. These services are offered to the partitions through an appropriate API and are reused by other OVERSEE components, too. Additionally, the following security related features are specified: Whole virtualization concept, OVERSEE firewall, secure assurance of prioritized resource access and internal communication requirements in the virtualized environment. ii

3 Contents Abstract... ii Contents... iii List of Figures... vi List of Tables... vii List of Acronyms and Abbreviations... viii Document History... xi 1 Introduction Scope and Objectives of the Document Definitions Document Outline Security Services Overall Structure of Security Services Hardware Security Module HSM Cryptographic Functions HSM Secure Key Storage HSM Secure Boot Registers HSM Hardware Interface Security Services Partition Security Partition Binding Hardware Security Module I/O Driver Cryptographic Services Module Key Management Module Secure Storage Certificate Handler Security Services Configuration Table Security Services Provider Module Cryptographic Services API Key Management API Secure Storage API Alternative Secure Storage Secure Communication API iii

4 2.5 Secure Boot Guideline for Providing Secure Boot in OVERSEE User Authentication and Authorization User Model of OVERSEE Authentication Methods for OVERSEE Extended Authorization Capabilities Secure Software Load Requirements for a Secure Software Load Specification of the Whole Virtualization Concept Partitions Virtualized Resources Configuration and Deployment Overview Concepts Subjects, Objects and Privileges Subject Identification Exported Resource Identification Partitions and the Partitioned Information Flow Policy Auditable Events Secure States Concepts Operations TOE Attestation Health Monitor Events Traces and Logs OVERSEE Firewall Communication Paths and Interfaces Security Methods Concerning the Communication Paths to be Considered for the OVERSEE Firewall Specification of the OVERSEE firewall Role Model for Definition of Firewall Policies Policy language for the OVERSEE firewall Secure Assurance of Prioritized Resource Access Classes of Resources Concerning Prioritized Resource Access Time shared resources iv

5 5.1.2 Resources capacity shared resources Classification of OVERSEE Resources Concerning Prioritized Resource Access Special Issues concerning Prioritization in SVAS Concepts for Prioritized Resource Access in OVERSEE Resources shared over time Resources with shared Capacity Change of Resource Sharing During Operation Policy Language for Definition of Prioritized Resource Access Security Challenges for Assurance of Prioritized Resources Access Residual Risks Specification of internal communication requirements in the virtualized environment High-Level Requirements Available Communication Mechanisms Sampling Ports Queuing Ports Compliance with RTE API Shared Memory Design Discussion - Robust SHM: Requirements on the Internal Communication Scenario1: Secure Communication - Dedicated Partition Scenario2: Non/low-secure device access - integrate in guest OS partition Scenario3: Device Multiple Access - Virtual Multiplexing Scenario 4 - Virtual Device - Interpartition Communication Scenario 5 - Scalability of the Architecture Next Steps References v

6 List of Figures Figure 1: Structure of Security Services... 2 Figure 2: Key for OVERSEE communication paths Figure 3: OVERSEE communication paths Figure 4: Example of prioritized capacity resource sharing Figure 5: Asymmetric Bi-directional mapping (ABM) Figure 6: Exchange Page Table Entry (XPTE) Figure 7: Secure Communication - Dedicated Partition Figure 8: Non/low-secure device access - integrate in guest OS partition Figure 9: Device Multiple Access - Virtual Multiplexing Figure 10: Virtual Device - Interpartition Communication Figure 11: Scalability of the Architecture vi

7 List of Tables Table 1: Security Service General Command Structure... 5 Table 2: Internal Key Structure... 6 Table 3: Key Structure for Export/Import... 7 Table 4: Cipher API... 9 Table 5: Cipher API, Output... 9 Table 6: CMAC API Table 7: CMAC API, Output Table 8: Hash and HMAC API Table 9: Hash and HMAC API, Output Table 10: Signature Generation API Table 11: Signature Generation API, Output Table 12: Signature Verification API Table 13: Signature Verification API, Output Table 14: Random Number Generator API Table 15: Random Number Generator API, Output Table 16: Counter API, Create counter Table 17: Counter API, Delete counter Table 18: Counter API, Output value create counter Table 19: Counter API, Increment counter Table 20: Counter API, Read counter Table 21: Counter API, Output value read counter Table 22: File encryption API Table 23: File encryption API, Output Table 24: File decryption API Table 25: File decryption API, Output Table 26: Content of software download configuration file Table 27: Captured errors, TOE and partition operation Table 28: Captured errors, Partition operation Table 29: Predefined actions Table 30: Security issues to be handled by the OVERSEE firewall Table 31: Classification of resources concerning prioritized resource access vii

8 List of Acronyms and Abbreviations 2G 3G ABM AES AMT API ARINC BIOS CA CAM CAN CBC CBC-MAC CC CCM CEN CMAC CPU CRL DENM DoS DSRC DTD ecall ECB ECC ECR ECU FiFo FPU GCM Second generation mobile phone system Third generation mobile phone system Asymmetric Bi-directional mapping Advanced Encryption Standard Abstract Machine Test Application Programming Interface Aeronautical Radio Incorporated Basic Input Output System Certification Authority Cooperative Awareness Message Controller area Network Cipher Block Chaining Cipher Block Chaining Message Authentication Code Common Criteria Counter with CBC-MAC European Committee for Standardization Cipher based MAC Central Processing Unit Certification revocation list Decentralized Environmental Notification Message Denial of Service Dedicated Short-Range Communications Document Type Definition Emergency Call Electronic Code Book Elliptic Curve Cryptography ECU configuration registers Electronic Control Unit First in First out Floating point unit Galois/Counter Mode viii

9 GNU GPS HAL HMAC HMI HSM HW I/O ICT IMA IP IPC ITS LDM MAC MILS MMU NIC NIST OEM OS OSEK PIFP PKCS PKI PoS POSIX PRNG PSAP QoS RAM RTE RTEMS RTOS GNU's not Unix Global Positioning System Hardware Abstraction Layer Hash based MAC Human Machine Interface Hardware Security Module Hardware Input Output Information and Communication Technology Modular Avionics Internet Protocol Inter Process Communication Intelligent Transportation System Local Dynamic Map Message Authentication Code Multiple Independent Levels of Security and Safety Memory Management Unit Network Interface Card National Institute of Standards and Technology Original Equipment Manufacturer Operating System Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug Partitioned Information Flow Policy Public Key Cryptography Standards Public Key Infrastructure Positioning Service Portable Operating System Interface (for Unix) Pseudo Random Number Generator Public-Safety Answering Point Quality of Service Random-access memory Runtime Environemnt Real-Time Operating System for Multiprocessor Systems Real-time Operating System ix

10 SecS SKPP SSL SSPM SVAS TLS TOE TSF USB V2X VDX VFB VM VMA VMM Wi-Fi XEX XML XPTE XTS Security Services Separation Kernel Protection Profile Secure Sockets Layer Security Services Provider Module Secure Vehicle Access Service Transport Layer Security Target Of Evaluation TOE Security Functions Universal Serial Bus Vehicle-to-X Vehicle Distributed executive Virtual Function Bus Virtual Machine/Virtual Machine Manager Virtual Memory Area Virtual Machine Manager/Monitor Wireless Fidelity Xor-Encrypt-Xor Extensible Markup Language Exchange Page Table Entry XEX-based Tweaked CodeBook x

11 Document History Version Date Changes Final version xi

12 1 Introduction The Open Vehicular Secure Platform (OVERSEE) project has produced this deliverable; therefore it contains contributions from all partners, while the main contributors are: escrypt, UPVLC, OpenTech and University of Siegen. The present document contains the specification of the security relevant features and capabilities of OVERSEE, hence a large part of the overall specification, since OVERSEE has a dedicated focus on security for open platforms. 1.1 Scope and Objectives of the Document The scope of this document is the specification of the security related features and capabilities of OVERSSE. Since OVERSEE is a project focusing on security from secure communication aspects to secure parallel execution of applications, this document contains a large part of the overall OVERSEE design. The objective of the actual document is to provide a global description for the implementation of the security related parts of OVERSEE. Thus, the document would be used as a kind of functional specification for the implementation phase and also a reference book concerning the security capabilities of the platform during usage. 1.2 Definitions For the purpose of the present document, the terms and definitions given in [1], [4] and [6] apply, if not otherwise noted. 1.3 Document Outline The document is structured as follows: Section 1 gives an introduction on the scope and intentions. Section 2 specifies the security services provided by OVERSEE. Section 3 is concerned with the description of the overall virtualization concept. Section 4 contains the specification of the OVERSEE firewall concept. Section 5 is dedicated to the secure assurance of prioritized access on shared resources and finally section 6 specifies the internal communication requirements in the virtualised environment. 1

13 2 Security Services 2.1 Overall Structure of Security Services Figure 1: Structure of Security Services Two main facts play a key role defining the requirements of the security services. First of all OVERSEE aims to provide a platform for ICT applications, which require a set of dependable security services. The second aspect is that OVERSEE provides multiple isolated runtime environments. This demands a strong level of isolation, which also has an impact on the security services. The OVERSEE security architecture basically consists of three parts. The first part is the hardware security module (HSM). The HSM provides accelerated cryptographic function execution, secure key and certificate storage, and registers for secure boot services. The second part is a dedicated partition for the security services. This partition owns exclusive rights to access the HSM and also hosts building blocks for further security services. The last part is the so-called security service provider module (SSPM). This module is a high level client located at the user partitions (or any other partition if needed) providing the link between user applications and security services. 2.2 Hardware Security Module The HSM is not part of the OVERSEE design however a crucial element in the security architecture. This part of the document will still list some requirements for the HSM on which the security services of OVERSEE will be build on. 2

14 Furthermore it is also possible to implement most of the functionality of a HSM in the security partition as a software version, though respectively in a less secure way. The design of OVERSEE is based on the existence of a HSM but the structure of the security partition will be specified in a flexible way to enable also a software implementation of HSM functionalities HSM Cryptographic Functions The cryptographic functions provided by the HSM are hardware-accelerated implementations of the algorithm thus offering higher performance than software implementations. In addition the HSM enables a secure environment for the cryptographic functions making any tampering attempts practically impossible. Furthermore key data used for the algorithms are also handled internally in the HSM, thus assuring security of key data. In order to satisfy the requirements to sign, verify and encrypt messages for V2X communications and PKI Infrastructure communications the following minimum set of functions are proposed by the OVERSEE design to be supported by the HSM: ECC-256: Asymmetric cryptographic engine based on elliptic curve arithmetic. Whirlpool: A hash function proposed by NIST. AES-128: A symmetric block encryption standard with a key length of 128 bits. It should support standard block encryption modes as ECB and CBC but also advanced modes as GCM and CCM. PRNG: A pseudo random number generator. Counters: Counter management with authorization. An implementation of further needed cryptographic functions into the security services partition would be a solution for creating a flexible and expandable design but is not a very secure method regarding key security. Therefore the HSM should also provide enhancement capabilities regarding cryptographic functions. That is the firmware of the HSM should enable realization of further cryptographic functions, even if supporting hardware blocks do not exist in the HSM. This would enable the implementation of cryptographic functions in software, e.g., ECC-224 as a candidate for cryptography in the upcoming ITS standards for Europe HSM Secure Key Storage The HSM features an internal storage for keys and certificates. The internal storage is not accessible directly over any interface, hence creating a secure storage for security relevant data. The exportation of a key from the HSM depends on the configuration of the relevant key. For further information on the security of key material and key management refer to Deliverable 2.4 [8]. 3

15 2.2.3 HSM Secure Boot Registers The HSM features so called ECU configuration registers (ECR) and assigned functions on which a secure and/or authenticated boot process can be built on. The following functionalities are provided in this context. Further information on secure boot process can be found in chapter 2.5. Extend ECR: This function is used for updating the ECR with a new (hash) value. The new value is pro-vided as input and chained together with the existing value stored in the ECR using a hash update function. Retrieve ECR: For any ECR, this function may be used to retrieve and verify its actual value. The ECR value is signed by a certification key whose usage authorization data needs to be presented as input. Furthermore, a nonce value, possibly obtained as a challenge from an external verifier, may be included to be able to prove the freshness of the signature. The ECR value together with its signature are returned as output Preset ECR: This function is used to manage references to ECR values by ECR indices in the context of secure boot. The function provides the possibilities to directly update an ECR with a new value, to set a new reference to an ECR index ("inherit") or to remove an existing reference ("clear"). Compare ECR: This function allows the direct comparison of the current ECR with a reference. If match fails, an automatic secure boot alarm may be activated. As a precondition, a reference must be set for the given ECR index, and an internal secure boot failure mechanism must be given HSM Hardware Interface The HW interface provided by the HSM is the dedicated interface to reach the functionality of the HSM. The interface depends on the HSM and the OVERSEE platform and will not be specified any further in the OVERSEE design. The proof of concept implementation will use any interface provided by the HSM without concerning any security aspects although the HW interface is an important communication path in the design respective security. Later implementations of the platform have to assure a secure interface; for further information refer to the document D2.4 [8]. 2.3 Security Services Partition The security services partition provides a secure and isolated runtime for the shared security services. Multiple partitions thus multiple applications will access the security functions of the platform. The security partition provides a trustable anchor in the whole security architecture and a controlled access to the security services as user partitions (and applications) have only restricted access to the security partition and services provided by the partition. In this section of the document the building blocks of the security partition are listed and described. Further specification of the building blocks is left to the implementation phase of the platform. The API to the security services are listed in section 2.4 where the client module for user partitions is specified. 4

16 2.3.1 Security Partition Binding The security services partition binding module is the first instance interfacing requests from the other partitions. The connection between the other partition and the security partition binding module exists of a queue in each direction for the commands and a shared memory for exchanging large chunks of data. The command structure received by the binding module can be seen in Table 1. The request ID is a unique label defined by the other partition for internal use at the other partition. This ID is followed by the command id and the parameters of the command. The security partition binding module handles the incoming command by adding the origin of the request and a unique handling id to the command before forwarding the command to the appropriate module. No. Name Description 1 Request ID A unique ID given by the user partition for the request. 2 Command ID ID of requested command. 3 Command parameters Parameters needed for the command. Details are specified in every method. Table 1: Security Service General Command Structure Hardware Security Module I/O Driver The HSM I/O driver is the interface to the HSM module. The driver is provided by the HSM manufacturer and therefore is out of scope of the OVERSEE design. The driver should provide a seamless integration of the HSM services into the runtime environment and function as a non-blocking device Cryptographic Services Module Any request for a cryptographic function is handled by the cryptographic functions module. The request is forwarded from the security services partition binding module and handled basically in this sequence: Check for authorization of requesting partition for requested service. Check for authorization of requested key and key usage. Subsequently the cryptographic service on the HSM is triggered or a software implementation of the requested cryptographic function is executed with the needed parameters Key Management Module The Key Management Module plays an important role in the security architecture of the OVERSEE design. Issues as authenticity, integrity and encryption are closely coupled to ownership of key information as the isolation of the security services for the multiple 5

17 partitions is mainly provided by defining different access rights to the key material. A key request is strictly handled by the key management module. The requesting partition has to be authorized for the requested key and the requested usage of the key. Only in this case the key data may be used for the requested security service by the user partition. The reliability of the origin of the request is assumed to be provided by the virtualization layer. Information regarding key management can be found in D2.4 Specification of Secure Communication [8]. An important role of the key management module is to integrate the key management functionality of the HSM with the virtualized environment of OVERSEE. Basically the key management of the HSM is not aware of the multiple runtime environments. The key management module builds an extra management stage between the user partition and the HSM providing the needed access control. The key management module also handles key export, import and creation requests from the other partitions. The API for the functionality is specified in chapter 2.4 Security Services Provider Module. Table 2: Internal Key Structure shows the internal key structure used in OVERSEE, Table 3 shows the encrypted key blob structure which is used in case of key importation/exportation. No Name Description 1 Algorithm Identifier This parameter determines the algorithm to be used with the key 2 Use Flags This parameter indicates the operations that may be performed with the key. 3 Key ID Identifier of the key. 4 Validity Indicates the last valid date the key can be used. 5 Certification Data This parameter is optional and may be used to certify the origin and/or properties of the key (e.g., by MVK). It may consist of, but is not limited to a digital signature. 6 Authorization Data This vector represents the authorization data items for each individual. (Passwords, list of authorized partitions) 7 Public Key Data Public key data bytes. 8 Private Key Data Private key data bytes. 9 Key handle Internal handle. Table 2: Internal Key Structure 6

18 No Name Description 1 Algorithm Identifier This parameter determines the algorithm to be used with the key 2 Use Flags This parameter indicates the operations that may be performed with the key. 3 Key ID Identifier of the key. 4 Validity Indicates the last valid date the key can be used. 5 Public Key Data Public key data bytes. 6 Encrypted Blob This part of the key structure includes all confidential key material encrypted with corresponding transport key. 7 Authentication Code This parameter is used to protect the integrity and authenticity of the key data. It may be either a MAC created by the symmetric transport key or a digital signature w/ IDK. Table 3: Key Structure for Export/Import Secure Storage The secure storage module is responsible for encrypting and decrypting files. The encryption procedure is described in the following steps. 1. The file to be encrypted arrives at the module from the user partition. 2. A random key K R is generated. 3. K R is used to encrypt the file. 4. K R is encrypted with the requested storage key K S. The user partition has to have the usage rights of this key. 5. The encrypted file, the encrypted key K R and the applied encryption parameters are bundled together as a file and sent back to the user partition. The API for the functionality is specified in chapter Certificate Handler The certificate handler is responsible for creating new certificates and handling incoming certificates. Certificates can be stored by this module. Additionally, the access control management for certificates is also done within the certificate handler module Security Services Configuration Table As mentioned before access to security services and key data requires proper access rights of the partitions. The security service configuration table provides a configuration tool to manage the access rights of the partitions. 7

19 Accessing and changing the table have to be done in a secure way to avoid any unauthorized changes in the table. The user has to prove authorization by a challenge-response process. Furthermore the table should also be not accessible offline. The table is either stored in the HSM or is encrypted before storing. The content of table should also be signed to avoid any offline changes in the table. 2.4 Security Services Provider Module The security services provider module (SSPM) is located at the user partition and is the client for accessing the security services provided by the security services partition. Furthermore, the SSPM provides high-level functionality for several services like communication protocols and secure storage. This means that only when services provided by the security services partition have to be accessed the client contacts the security services partition and requests the required service. The SSPM is an application level service running in the user partition. The connection to the security services partition is provided by the virtualization layer and consists of a queue for the requests and a shared memory area for exchanging larger chunks of data. The general command structure between the SSPM and security partition is described in section Security Partition Binding of this document. The next sections describe different services and the associated API s provided by the SSPM Cryptographic Services API Following are the methods provided by the cryptographic services module Cipher The cipher API provides the required method for general encryption/decryption. The algorithm and operation mode can be defined with the parameters. 8

20 No Name Description 1 Algorithm identifier Reference to associated symmetric algorithm 2 Cipher mode Indicate decryption or encryption mode 3 operation mode Indicate cipher mode of operation {ECB CBC GCM EAX..} 4 padding_scheme Indicate padding scheme {none bit byte pkcsx..} 5 IV_SIZE Size of given initialization vector (can be 0) 6 Key handle Handle (internal ID) of the requested key 7 Key Authorization Size Size of authorization value of the key 8 Key Authorization Value Authorization value of key 9 Input Data Pointer to input data 10 Input Data Size Size of input data Table 4: Cipher API No Name Description 1 Output Data Pointer to Output data 2 Output Data Size Size of Output data Table 5: Cipher API, Output CMAC The CMAC API provides the required method for cipher based MAC calculation. The algorithm and operation mode can be defined with the parameters. 9

21 No Name Description 1 Algorithm identifier Reference to associated symmetric algorithm 2 MAC mode Indicate MAC mode: sign, timestamped sign or verify 3 operation mode Indicate cipher mode of operation {CMAC/OMAC/ } 4 padding_scheme Indicate padding scheme {none bit byte pkcsx..} 5 Key handle Handle (internal ID) of the requested key 6 Key Authorization Size Size of authorization value of the key 7 Key Authorization Value Authorization value of key 8 Input Data Pointer to input data 9 Input Data Size Size of input data Table 6: CMAC API No Name Description 1 Output Data Pointer to Output data 2 Output Data Size Size of Output data Table 7: CMAC API, Output Hash and HMAC The HMAC API provides the required method for general hash calculation and hash based MAC calculation. The algorithm and operation mode can be defined with the parameters. No Name Description 1 Requesting Partition ID of partition requesting the service 2 Algorithm identifier Reference to associated symmetric algorithm 3 Hash mode Indicate hash or HMAC creation mode 4 Key handle Handle (internal ID) of the requested key 5 Key Authorization Size Size of authorization value of the key 6 Key Authorization Value Authorization value of key 7 Input Data Pointer to input data (to be verified MAC, or Data for creating MAC) 8 Input Data Size Size of input data Table 8: Hash and HMAC API 10

22 No Name Description 1 Output Data Pointer to Output data 2 Output Data Size Size of Output data Table 9: Hash and HMAC API, Output Signature Generation The following method is used to handle the generation of signatures with a private key. This method is applied to the complete message to be signed. No Name Description 1 Requesting Partition ID of partition requesting the service 2 Algorithm identifier Reference to associated asymmetric algorithm 3 Hash algorithm identifier Reference to associated hash algorithm 4 padding_scheme Indicate padding scheme {none bit byte pkcsx..} 5 Time stamp Indicate additional timestamp creation 6 Key handle Handle (internal ID) of the requested key 7 Key Authorization Size Size of authorization value of the key 8 Key Authorization Value Authorization value of key 9 Input Data Pointer to input data (to be verified MAC, or Data for creating MAC) 10 Input Data Size Size of input data Table 10: Signature Generation API No Name Description 1 Output Data Pointer to Output data 2 Output Data Size Size of Output data Table 11: Signature Generation API, Output Signature Verification The following method is used for signature verification. These functions are applied to the complete message whose signature shall be verified. 11