Wind River® Intelligent Device Platform XT

SECURITY GUIDE

2.0

EDITION 4 Copyright Notice

Copyright © 2014 Wind River Systems, Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means without the prior written permission of Wind River Systems, Inc. Wind River, Tornado, and VxWorks are registered trademarks of Wind River Systems, Inc. The Wind River logo is a trademark of Wind River Systems, Inc. Any third-party trademarks referenced are the property of their respective owners. For further information regarding Wind River trademarks, please see: www.windriver.com/company/terms/trademark.html This product may include software licensed to Wind River by third parties. Relevant notices (if any) are provided in your product installation at one of the following locations: installDir/product_name/3rd_party_licensor_notice.pdf installDir/legal-notices/ Wind River may refer to third-party documentation by listing publications or providing links to third-party Web sites for informational purposes. Wind River accepts no responsibility for the information provided in such third-party documentation.

Corporate Headquarters Wind River 500 Wind River Way Alameda, CA 94501-1153 U.S.A. Toll free (U.S.A.): 800-545-WIND Telephone: 510-748-4100 Facsimile: 510-749-2010 For additional contact information, see the Wind River Web site: www.windriver.com For information on how to contact Customer Support, see: www.windriver.com/support

10 Dec 2014 Contents

1 Introduction to IDP Security ...... 5 Overview of Security Guide ...... 5 Security Architect Tasks ...... 6 About Trusted Boot ...... 6 About Deployed Embedded Devices ...... 7 Embedded Terms ...... 7 Stakeholder Roles ...... 7 Target Software System ...... 8 Public Key Cryptography ...... 9 The Chain of Trust ...... 9 Overview of the SRM Trusted Software Stack ...... 10 TMP OpenSSL Engine ...... 11 SRM Workflow ...... 12

2 Security Planning ...... 13 Security Planning Workflow ...... 13 Initial Development Assessment ...... 14 Review Security Design Techniques ...... 14 Run-time Security Assessment ...... 15 Application Security Assessment ...... 15 Lifecycle Planning ...... 16 Certificate and Key Management ...... 16

3 Risks, Threats, and IDP Security Mechanisms ...... 19 IDP Security Mechanisms ...... 19 About Handling and Analyzing Attacks ...... 20

4 Security Best Practices ...... 25

5 Keys and Certificates ...... 27 Root Certificate Management ...... 27 Fetching Certificates at Run Time ...... 28 Maintaining Certificate Security ...... 28 Vendor Key Lifecycle ...... 29 About Documentation for Device Users ...... 30 Verifying Packages Using OpenSSL ...... 30

iii Wind River® Intelligent Device Platform XT Security Guide, 2.0

6 Integrity Measurement ...... 33 Integrity Measurement ...... 33 IMA Appraise ...... 33 McAfee Embedded Control ...... 34

7 Secure Repository ...... 37 The Secure Repository ...... 37 Extended Signature in RPM Design ...... 38 IM Check Structure ...... 38 IM Tools Script Design ...... 39

8 Encrypted Data Storage ...... 41 Encrypted Data Storage ...... 41 dm-crypt and cryptsetup ...... 41 TPM-Backed Encrypted Storage ...... 42

iv 1

Introduction to IDP Security

Overview of Security Guide 5 Security Architect Tasks 6 About Trusted Boot 6 About Deployed Embedded Devices 7 Embedded Terms 7 Public Key Cryptography 9 The Chain of Trust 9 SRM Workflow 12

Overview of Security Guide

This document provides systems integrators and security architects with guidance on using Wind River Intelligent Device Platform XT to secure their products. IDP XT provides capabilities to help you secure your product throughout its life: • during design • during development • during deployment The security guide also provides guidance about best practices.

5 Wind River® Intelligent Device Platform XT Security Guide, 2.0

Security Architect Tasks

The security architect plans and implements the owner's requirements for the security of the device. Tasks performed by security architects include the following: • Determining the overall security policy, including up-front security policy and periodic security policy reviews. • Determining the environment the device is placed in and the security threats that the device must mediate. • Determining the communication posture of the device, including choosing supported networks, networking devices, and protocols, as well as specifying the network topology if it is not determined by the choice of networks. • Defining procedures for handling attacks when they are discovered. (By definition, successful attacks are discovered after the attack, while unsuccessful attacks are discovered before or during the attack.) • Defining a forensics strategy to analyze data about possible attacks, successful or unsuccessful. This could both prevent or mitigate subsequent attacks and identify the attacker. • Determining the management strategy for the device. • Assisting with selection of device hardware and application vendors. • Monitoring the device vendor during development and deployment. • Monitoring the device vendor and software providers during device provisioning. • Monitoring the device vendor and software providers during device firmware and software updates. • Planning a schedule of device retirement, and monitoring the device vendor and software providers or special disposition teams at the time of device retirement. • Creating documentation for the end user, which defines the required security procedures and practices.

About Trusted Boot

A trusted platform must provide a high assurance that the system behaves as it is expected to behave. One of the challenges is ensuring that the entire executing software stack is of a known source and has not been tampered with. The IDP XT software stack consists of the following components: • platform firmware • boot loader • operating system kernel • drivers • libraries • applications

6 1 Introduction to IDP Security About Deployed Embedded Devices

Verified Boot Process A vital piece of establishing a trusted platform is providing a trusted boot process from power-on and firmware start-up until the operating system loads. IDP XT uses the following techniques to provided a trusted boot process: • Carries out measurements of firmware, the boot loader, and the kernel as well as all associated configuration data before using them. • Verifies that measurements are consistent and as expected. Successful performance of these steps means that the platform can be trusted to be the real application, neither tampered with nor replaced. Trusted boot is implemented on a per-platform basis.

About Deployed Embedded Devices

Embedded devices deployed in the field have multiple stakeholders. Each stakeholder has different levels of responsiblity and control over the device. For example, the entity that keeps and uses embedded devices in the field (the end user) may not have permission to make arbitrary modifications or updates to the software system resident on an embedded device. Users are restricted to using a device for specific purposes with specific software components. The privilege of updating the device software system and specifying what functions the device can perform throughout its lifecycle belongs to the entity that owns the device, or to entities that receive limited delegation from it. SRM (Secure Remote Management) supports this business model, providing secure control for owners of the software system deployed onto embedded devices. End users are prevented from doing arbitrary modifications to the software system after they receive the devices. The system can only be updated using authorized methods of remote management.

Embedded Terms

Stakeholder Roles

Related Links Target Software System on page 8 target device An embedded device which is deployed and managed remotely. The target consists of: • hardware • board level firmware • application software

7 Wind River® Intelligent Device Platform XT Security Guide, 2.0

device owner The entity that owns the target device and specifies which functions it will perform. This entity manages the device throughout its life cycle. device vendor The entity that manufactures the target device for the device owner. The device vendor provides the following to the device owner: • hardware • board-level firmware (BSP) • base software (operating system) The device vendor may also provide application software. software provider The entity that provides application software to the device owner. The software provider is often known as a 3rd-party software vendor. The device owner delegates authority to the software provider to deploy software in the form of an authorized software package onto the target device. end user The person or external device that interacts with the target device. For example, the end user may view or store information on the device or use the device as an intermediate network- connectivity device.

Target Software System

Related Links Stakeholder Roles on page 7 boot loader When a modern computer system is powered on, it typically executes a relatively small program stored in read-only memory (ROM). The ROM also contains a small amount of data needed to access nonvolatile devices. The small program that starts this sequence is known as a bootstrap loader, bootstrap, or boot loader. The only action boot loader performs is loading other data and programs. These programs are then executed from RAM to load the operating system and data. Grub is the boot loader provided in IDP XT's SRM-enabled solution. operating system An operating system (OS) is a collection of software that manages computer hardware resources and provides common services for computer programs. The operating system is a vital component of the system software; application programs usually require an operating system in order to function. Wind River Linux 5.0.x is the operation system currently supported to deploy SRM. initramfs The initramfs is a complete set of directories found in a normal root file system. It is bundled into a cpio archive and compressed.

8 1 Introduction to IDP Security Public Key Cryptography

An initramfs can be built directly into the Linux kernel. When the kernel boots, it checks for the presence of initramfs and, if found, mounts it as / and runs /init. A significant number of the security-related actions performed by SRM are executed from initramfs early in the user-space stage before the whole system switches to the normal root file system. root file system The root file system is the file system located on the same partition where the root directory is located. It is the file system on which all other file systems are mounted. The root file system includes the root directory together with a minimal set of subdirectories and files. These include /boot, /dev, /etc, /bin, /sbin and sometimes /tmp (for temporary files). SRM installs end-user applications in the root file system and controls what specific actions the device owner permits users to take. Applications can be installed or uninstalled using RPM. RPM package RedHat Package Manager (RPM) is a package management system. An RPM package typically contains the compiled version of the software. The RPM5 program interprets and installs the application software contained in an RPM package. SRM uses RPM packages to update and manage the software system on a device after it is deployed in the field.

Public Key Cryptography

Public-key cryptography or asymmetric cryptography allows users to interact securely with different entities in an insecure environment and allows the device to use its digital signatures to verify the identity of a user reliably. The following are key characteristics in the asymmetric cryptographic system SRM uses: • The key is a set of extremely large numbers. • Each key consists of an RSA key-pair, containing a private key and a public key. • From the public key, it is impossible to calculate the corresponding private key. • Cipher text encrypted by one public key can only be decrypted by the corresponding private key. • Cipher text that can be decrypted successfully by one public key must have be encrypted or signed by the corresponding private key. This is known as a digital signature.

The Chain of Trust

SRM prevents unauthorized software from running on deployed embedded systems, while allowing authorized software to be deployed using remote management and executed. SRM uses public key cryptography and digital signatures to implement its security system.

9 Wind River® Intelligent Device Platform XT Security Guide, 2.0

Authorized software is considered trusted, while unauthorized software is considered untrusted. A software component becomes trusted after its associated digital signature is validated by a trusted digital certificate, which must contain at least one public key and the key's signature. A digital certificate becomes trusted after its signature is validated by another trusted digital certificate or public key. Starting at the lowest hardware or software level, successive validations build a chain of trust up to the application level. The chain structure makes it possible to change upper-level components of the chain without changing lower ones, as long as the changed components can still be validated by lower components. This keeps the system secure while still being flexible. Related Links Overview of the SRM Trusted Software Stack on page 10 The SRM trusted software stack starts with the boot process and confirms that each stage of booting and running applications is trusted. TMP OpenSSL Engine on page 11 Secure Remote Management (SRM) provides a secure back-end communication channel using TPM hardware for networking scenarios. This is supported by the OpenSSL TPM engine.

Overview of the SRM Trusted Software Stack

The SRM trusted software stack starts with the boot process and confirms that each stage of booting and running applications is trusted.

1. For Intel Architecture devices, Grub verifies that the bzImage has an authorized certificate and a digital signature appended.

10 1 Introduction to IDP Security TMP OpenSSL Engine

If the image lacks an authorized certificate and digital signature, Grub prints an error message similar to the following:

##################### # # # Verified Failed! # # # ##################### Press Any Key to Reboot... 2. After the Linux kernel in the verified image boots, it mounts the root file system and verifies the RSA signature of every executable before the application executes. 3. Because the IM tools are executable bash scripts, the Linux kernel also verifies that they have an authorized RSA signature. Related Links The Chain of Trust on page 9 SRM prevents unauthorized software from running on deployed embedded systems, while allowing authorized software to be deployed using remote management and executed. TMP OpenSSL Engine on page 11 Secure Remote Management (SRM) provides a secure back-end communication channel using TPM hardware for networking scenarios. This is supported by the OpenSSL TPM engine.

TMP OpenSSL Engine

Secure Remote Management (SRM) provides a secure back-end communication channel using TPM hardware for networking scenarios. This is supported by the OpenSSL TPM engine. For typical SSL/TLS-based network communication, data transported during the handshake period is encrypted by another peer's public key before sending. This means that the data can be decrypted only by the peer that has the corresponding private key required for decryption. SRM enhances this process by storing the private key in the TPM chip so that it can never be extracted or used for decryption on any other platform. During the handshake period, the peer device encrypts negotiation messages using the TPM public key before it sends them. Only the authorized peer device containing the TPM hardware can decrypt the cipher message. An integrated TPM engine allows the embedded device to act as both a secure enhanced SSL server and as an SSL client. OpenSSL or its libcrypto library must be programmed correctly to use the TPM engine, which is implemented as the dynamic shared library /usr/lib/ssl/engines/libtpm.so. Related Links The Chain of Trust on page 9 SRM prevents unauthorized software from running on deployed embedded systems, while allowing authorized software to be deployed using remote management and executed. Overview of the SRM Trusted Software Stack on page 10

11 Wind River® Intelligent Device Platform XT Security Guide, 2.0

The SRM trusted software stack starts with the boot process and confirms that each stage of booting and running applications is trusted.

SRM Workflow

Establishing a chain of trust for a device starts with configuring the device, continues through installing certificates and deploying the device, and concludes with installing software updates and managing the device remotely. 1. The device developer configures and builds the target image and root file system. IDP XT provides default configurations for early development. 2. The device developer installs the root and vendor certificates in the target image. The SRM signing tool (SST) simplifies creating and managing default certificates and installing actual certificates. 3. The device developer loads the signed system image onto the target from a USB stick or other portable media and boots the development target. The deployed device has the system installed to boot at power-on. 4. The application software developer provides signed applications. They may be loaded on the target by the device developer or placed in a secure repository for download to the device by the owner. 5. The owner deploys system and application software updates remotely from the secure repository to devices. 6. The owner may distribute updated certificates to devices at any time. 7. The owner uses remote tools to verify that the downloaded packages are correctly signed before installing them on the device. 8. The owner monitors security systems for unauthorized changes. 9. Every time the system boots or starts an application, the device confirms that the software has not been modified without authorization.

12 2

Security Planning

Security Planning Workflow 13

Security Planning Workflow

The planning process helps you determine which IDP XT features and capabilities to incorporate into your product and how you should configure these features and capabilities. For example, you may determine that you require secure remote login, so you might choose to include SSH. You may determine that you do not require a secure file transfer protocol, so you can use FTP or TFTP instead of including and configuring SFTP. You might want to include EAP because you are developing a product that requires an authentication framework, and furthermore that you want to use EAP-TLS authentication with client-side certificates. Related Links Initial Development Assessment on page 14 Create or review the overall threat assessment. Review Security Design Techniques on page 14 Compare system requirements to IDP XT capabilities. Run-time Security Assessment on page 15 Determine what capabilities the device requires to meet system requirements. Application Security Assessment on page 15 Determine what run-time capabilities are required to support your secure applications. Lifecycle Planning on page 16 Establish plans and processes for comprehensive lifecycle support. Certificate and Key Management on page 16

13 Wind River® Intelligent Device Platform XT Security Guide, 2.0

Establish plans and processes for management of keys and certificates.

Initial Development Assessment

Create or review the overall threat assessment. Answer the following questions: • Does an overall threat assessment exist? If not, should an overall threat assessment be performed? • Is the device in a non-secure physical location where it accessible and perhaps vulnerable to reverse engineering? How does that affect the design? • How will the device be deployed? Will it be located in physically secure locations? If not, what are the physical ports an attacker can exploit? • What are the types of I/O used by the device? How are the protocols of ports secured? Should a network test tool be used to verify the device network robustness? • What types of users and roles will interface with the device? How are user accounts for these administrators managed? What is the consequence if an administrator's password is stolen? What is the consequence if a disgruntled employee decides to commit sabotage? • How will the device be provisioned? • How is the system upgraded? How do you ensure that the upgraded image comes from a legitimate source? • How is the device booted? Is there a risk that the boot image can be manipulated? • Process aspects are also relevant. How do you ensure that a developer does not insert a trojan horse in the software? Related Links Security Planning Workflow on page 13 The planning process helps you determine which IDP XT features and capabilities to incorporate into your product and how you should configure these features and capabilities. Review Security Design Techniques on page 14 Compare system requirements to IDP XT capabilities.

Review Security Design Techniques

Compare system requirements to IDP XT capabilities. The answers to these questions will help you determine which IDP XT features to use and how to incorporate them. • Does the system require advanced manageability? • Does it require policy-based security-enabled capability? • Does it require remote power-up and power-cycle? • Does it require remote software updates? • Does it require digitally signed software components? • Does it require agent checking and alerts? • Does it require robust encryption and access control? • Does it require remote diagnostics and repair? • Does it require auditing of security events? • Does it require remote attestation of the device? • Does it require secure file storage?

14 2 Security Planning Run-time Security Assessment

Related Links Security Planning Workflow on page 13 The planning process helps you determine which IDP XT features and capabilities to incorporate into your product and how you should configure these features and capabilities. Initial Development Assessment on page 14 Create or review the overall threat assessment. Run-time Security Assessment on page 15 Determine what capabilities the device requires to meet system requirements.

Run-time Security Assessment

Determine what capabilities the device requires to meet system requirements. • Is a base network stack satisfactory (for a system locked in a secure area for example), or does a full-featured network stack with a complete security portfolio make more sense? • Is VPN support required? If so, should the VPN implementation be independently certified by the VPN Consortium (VPNC)? • Will standard cryptography libraries suffice, or does the system require FIPS-140-2 certifiable libraries? • Does the system require Achilles certification to prove that it can withstand many rigorous denial-of-service attacks? • Does the system require proactive measures against software executed by untrusted local or remote users? Related Links Security Planning Workflow on page 13 The planning process helps you determine which IDP XT features and capabilities to incorporate into your product and how you should configure these features and capabilities. Review Security Design Techniques on page 14 Compare system requirements to IDP XT capabilities. Application Security Assessment on page 15 Determine what run-time capabilities are required to support your secure applications.

Application Security Assessment

Determine what run-time capabilities are required to support your secure applications. This requires that you augment the runtime platform with application-specific security support. This may include leveraging networking analytics, for example, using network intelligence to determine the reliability of information using endpoint reputation. The system may be required to ensure data is coming from a trusted source. Related Links Security Planning Workflow on page 13 The planning process helps you determine which IDP XT features and capabilities to incorporate into your product and how you should configure these features and capabilities. Run-time Security Assessment on page 15 Determine what capabilities the device requires to meet system requirements. Lifecycle Planning on page 16

15 Wind River® Intelligent Device Platform XT Security Guide, 2.0

Establish plans and processes for comprehensive lifecycle support. IDP Security Mechanisms on page 19 IDP XT provides many capabilities and configuration options for general security and for countering specific types of threats.

Lifecycle Planning

Establish plans and processes for comprehensive lifecycle support. • Define security best practices. • Provide system architects and the development team with security training and awareness. • Schedule security reviews to assess the system design and architecture. • Filter or control all I/O. • Use embedded tools support to analyze complex security questions, including memory, cache, packet tracing, simulation, thread analysis, and most importantly, “what-if” scenario support. • Define processes to deal with various attack scenarios. • Perform regular reviews of the logs to ensure that no attack has been detected. • Define a process to decommission the device and to destroy it properly if necessary. Related Links Security Planning Workflow on page 13 The planning process helps you determine which IDP XT features and capabilities to incorporate into your product and how you should configure these features and capabilities. Application Security Assessment on page 15 Determine what run-time capabilities are required to support your secure applications. Certificate and Key Management on page 16 Establish plans and processes for management of keys and certificates.

Certificate and Key Management

Establish plans and processes for management of keys and certificates. • Provide system architects and the development team with key management training. • Define development and testing processes to ensure that keys and certificates are kept secure. • Define a release process that ensures that security keys are not inadvertently left in software or firmware. • Define comprehensive software release mechanisms that ensure that keys and certificates are kept secure. • Define how keys will be deployed, whether during manufacture or during initial system provisioning. • Define a process for key replacement in the case where the encryption algorithm or certificate authority is compromised. • Establish a key lifecycle, from development to device end-of-life or disposal. This should also encompass any test keys that may have been used during development or field testing. Related Links Security Planning Workflow on page 13 The planning process helps you determine which IDP XT features and capabilities to incorporate into your product and how you should configure these features and capabilities. Lifecycle Planning on page 16

16 2 Security Planning Security Planning Workflow

Establish plans and processes for comprehensive lifecycle support.

Risks, Threats, and IDP Security Mechanisms

IDP Security Mechanisms 19 About Handling and Analyzing Attacks 20

IDP Security Mechanisms

IDP XT provides many capabilities and configuration options for general security and for countering specific types of threats. It provides an underlying infrastructure that can support customized and individualized approaches to specific security concerns. IDP XT can also support and work in conjunction with additional security measures, such as security hardware that detects tampered boot code and prevents startup of a compromised system.

To Secure or Protect... See this IDP XT Feature...

encrypted data storage DM-Crypt

integrity measurement IMA-Appraise, McAfee Embedded Control

key management Smart Signing Tool

secure boot for Intel Atom boards Grub-IMA

secure network IPSEC VPN

secure repository online updates + signed package manager

secure system management Webif, OpenSSH

19 Wind River® Intelligent Device Platform XT Security Guide, 2.0

The diagram shows which security mechanisms can be used to protect different areas of the IDP XT software stack.

About Handling and Analyzing Attacks

Responding effectively to attacks requires understanding what parts of the system are at risk and what capabilities of IDP XT can address the issues. 1. What aspect of security is at stake? 2. What are the attack vectors and risks? 3. What capability of IDP XT (if available) can address that issue? 4. What caveats should the security architect take into consideration?

Attack Type Description IDP XT Security Caveats Mechanism

IP spoofing The attacking system IP network level DoS is still possible and impersonates either your encryption using IPSEC must be handled by a device or a remote and SSH/SSL can be different defense system it is used to counter against mechanism. communicating with. these attacks; they The intention is to cause provide authentication a denial of service (DoS), and encryption of to hijack network networking sessions. sessions, or to obtain information about network topology as a basis for further attacks.

20 3 Risks, Threats, and IDP Security Mechanisms About Handling and Analyzing Attacks

Attack Type Description IDP XT Security Caveats Mechanism

Eavesdropping The attacking system IPSEC, SSH, and Locally based passive attempts to intercept TLS/SSL provide eavesdropping such as data or secrets being protection against covert channels require exchanged between two network eavesdropping more careful analysis of hosts. The attack can be and other man-in-the- the entire system and its in either of the following middle-based attacks. running applications and forms: users. • active eavesdropping such as man-in-the- middle attacks, in which connections are established to unaware communicating parties and falsified messages are sent • passive eavesdropping where data is collected using covert channels

Replay The attacking system IPSEC and SSL/TLS transmits data that it secured communication previously intercepted in can protect against order to impersonate a replay attacks. trusted system and gain access to the target system and its resources. This technique can also be part of a man-in-the- middle attack.

21 Wind River® Intelligent Device Platform XT Security Guide, 2.0

Attack Type Description IDP XT Security Caveats Mechanism

Software The attacking system The following Grsecurity The more complex a vulnerabilities exploits bugs in the capabilities aid in system is, the more software to elevate reducing the attack opportunities exist for security privileges for surface for software bugs and related the attacker. Even with vulnerabilities: software vulnerabilities; trusted signed packages handling successful • non-executable data and integrity software-based attacks monitoring, a system is • address space layout must be an integral part still susceptible to pre- randomization of the security plan. existing software • supervisor mode vulnerabilities; active execution prevention security measures must • supervisor mode be taken to reduce the access prevention attack surface. • UDEREF • role-based access control • exploit brute force detection

Disclosed The attacking system Minimize the exposure software exploits bugs in the of vulnerable software to vulnerabilities software to elevate exploits by securely security privileges for deploying fixes to the attacker. Software running systems: vendors must correct 1. integrate fixes into known defects using the software hotfixes and patches repository before exploits can be developed and 2. use the remote deployed. software update facility to update deployed systems

Untrusted The attacking system The SRM signing tool A certificate revocation software replaces trusted software digitally signs packages policy must be in place packages packages with modified and embeds certificates, to deal with falsified packages containing allowing packages to be certificates. viruses or back-doors. verified for authenticity Verifying the origin and before installation by the trustworthiness of Smart package manager. software packages is a key part of maintaining overall system security.

22 3 Risks, Threats, and IDP Security Mechanisms About Handling and Analyzing Attacks

Attack Type Description IDP XT Security Caveats Mechanism

Physical The attacking system can DMCrypt with optional This level of protection tampering bypass most software TPM backing provides only provides security level security capabilities encrypted storage that against adversaries with if physical access allows ties the decryption key limited funding or moving data to another to a specific TPM and resources. system for external software configuration. analysis. This increases the difficulty of the attack as all the dependent components need to present and running unchanged.

Software The attacking system can The Integrity Local detection relies on tampering install unauthorized Measurement the Linux kernel not modifications to Architecture (IMA- being compromised and software and malicious Appraise and McAfee still being a trusted configuration software Embedded Control) can component. that persists across detect these reboots. Access may be modifications locally. gained either by either local software vulnerabilities or by remote attacks. These modifications may be difficult to locate.

Network The attacking system can The following Grsecurity An adversary with denial-of- use network-based DoS can lessen the effect of sufficient network service in a variety of forms DoS: resources can still cause including distributed a DoS; the defense • TCP/UDP blackhole variants that recruit mechanisms listed allow multiple hosts to target a • LAST_ACK DoS the server to reduce the specific system or prevention effects of some attacks. network. DoS is a Further protection can be directed attack that provided by configuring attempts to cause IPTABLES to provide interruption of services firewalling at the by overloading systems network interface. and exhausting resources.

Security Best Practices

Determine how you will implement best practices in your system. Best practices include the following: 1. booting using secure or trusted boot 2. closing unnecessary network ports 3. providing adequate network resources 4. utilizing password protection mechanisms 5. storing and managing keys securely, as described in 6. applying secure upgrade policies, procedures, and methods 7. applying device-local security policies for users 8. reviewing logs to detect possible attacks 9. encrypting data that is transmitted over the network 10. reducing the amount of software running on the system to minimize attack surfaces

Related Links The OpenSSL package included in IDP XT is configured for enhanced security. For information on using OpenSSL, see the Wind River Intelligent Device Platform XT Programmer's Guide.

Keys and Certificates

Root Certificate Management 27 Vendor Key Lifecycle 29 About Documentation for Device Users 30 Verifying Packages Using OpenSSL 30

Root Certificate Management

In SRM, a root certificate (typically the device owner's certificate) is used to verify all the other certificates from various vendors. The root certificate management module in SRM provides a unified flow of management to protect and use the root certificates. The device owner's X509v3 certificate acts as the root-of-trust for the whole SRM system. It is a representation of the device owner throughout the entire system. The device owner's private key is used to sign all the delegated entities; both the device manufacturer and the software provider have their certificates signed by this private key and verified on the device by the owner's certificate. The owner key enables the following functions: • certificate signing • certificate validation • application validation In IDP XT, a root certificate is used in many places in the SRM chain of trust. For example: • In the early stages of boot, the GRUB boot loader uses it to verify the kernel image. • In initramfs, it is imported into the kernel keyring. • In the rootfs, the IMA-Appraise capability uses it to verify executable files. • In the rootfs, the IM tools use it to verify RPM packages. Related Links Fetching Certificates at Run Time on page 28

27 Wind River® Intelligent Device Platform XT Security Guide, 2.0

When using a RSA algorithm-based asymmetric key system, the private key must always be kept private. Different methods are used to fetch the owner certificate on the target. Maintaining Certificate Security on page 28 Maintain the security of certificates with TPM hardware or secure ROM.

Fetching Certificates at Run Time

When using a RSA algorithm-based asymmetric key system, the private key must always be kept private. Different methods are used to fetch the owner certificate on the target. The device owner's private key, after it is created, must be secure on the host and never released to a target in the field. The only access to the device owner's private key occurs when SST uses it to sign delegated digital certificates for a device vendor or software provider. The device owner's certificate, as a public key self-signed by its corresponding private key, must be deployed to thousands of target devices. Delegated certificates which represent a device vendor or software provider must be verified by the deployed device owner's certificate before they are trusted to verify deployed software. The following methods are used to retrieve certificates: boot loader For boot loaders, both grub-ima and U-boot must be able to get a plain-text version of the owner certificate using variable references in their C code. For boot loaders, grub must be able to get a plain-text version of the owner certificate using variable references in their C code. Linux kernel Boot loaders pass the device owner's certificate content in the boot command line, allowing the Linux kernel to obtain it by parsing the boot command line. user space scripts (IM tools) Applications in user-space fetch the root-of-trust from kernel space using a pseudo file-system entry: /proc/sys/security/integrity/owner-cert The content matches the device owner's X509v3 certificate. Related Links Root Certificate Management on page 27 In SRM, a root certificate (typically the device owner's certificate) is used to verify all the other certificates from various vendors. The root certificate management module in SRM provides a unified flow of management to protect and use the root certificates.

Maintaining Certificate Security

Maintain the security of certificates with TPM hardware or secure ROM. Where TPM hardware is available, you can use it to protect the certificate. When the device boots, the kernel interacts with the TPM hardware, encrypts (seals) the owner certificate using the TPM, and overwrites the original memory with cipher-text generated by the TPM.

28 5 Keys and Certificates Vendor Key Lifecycle

The encryption prevents an attack from overwriting memory buffers inside the Linux kernel to replace the root-of-trust. When a user space tool accesses the certificate, the Linux kernel decrypts (unseals) the cipher-text using the TPM and dumps plain text to user space. Where secure ROM is available, the certificates are placed in the secure ROM. Platform with secure ROM (for example, Cross Hill) When the device boots, the secure ROM verifies the grub.efi with the csbh file. If the owner certificate in grub.efi has changed, the target cannot boot. Where neither TPM nor secure ROM is available, the owner certificate is placed directly in Linux kernel memory. Related Links Root Certificate Management on page 27 In SRM, a root certificate (typically the device owner's certificate) is used to verify all the other certificates from various vendors. The root certificate management module in SRM provides a unified flow of management to protect and use the root certificates.

Vendor Key Lifecycle

Vendors use the SRM signing tool (SST) during development to sign their system and application executables, with either default or actual keys. SST signs a new digital certificate and creates a corresponding RSA private key. The device developer uses the key to sign the Linux kernel image and any pre-deployed software resident in the default root file-system. The application software developer uses the key to sign packages before delivering them to the owner for deployment. The device developer's vendor certificate is fetched and used in two validation scenarios: IM tools scripts validate RPM packages transported from the network. The IM tools fetch the certificate directly from the /etc/keys folder. The Linux kernel appraise capability validates the root file system executable applications before they run. The Linux kernel fetches the certificate from its appraised keyring inside kernel space. The initramfs (an early stage, verified, small user-space file-system) validates the vendor certificate and imports it to the Linux kernel's keyring after validation succeeds. The application software developer's vendor certificate is deployed to the device by the SRM device management server/client after deployment.

29 Wind River® Intelligent Device Platform XT Security Guide, 2.0

About Documentation for Device Users

In general an IDP XT user does not interact directly with the module but there are various instances in which the user can see the module in action. • the verification banner displayed on the target console during trusted boot on Intel Architecture platforms:

######################################################## ## ## ## Verification OK ## ## ## ########################################################

• messages which indicate that imported certificates verified successfully:

# imtools --verifyrpm spm-repo-0.0.2-r0.atom.rpm Header extend signature: OK Find right certificate: vendor-cert.pem Certificate vendor-cert.pem is verified successfully • two keys appearing in the _ima keyring after login to the IDP XT target:

# keyctl list `keyctl search @u keyring "_ima"` 2 keys in keyring: 785807782: --alswrv 0 0 user: F2D4A67FF9782BEC 30615420: --alswrv 0 0 user: 3EAA305063C67D6C • the root certificate in user space (viewed using the following command):

# cat /proc/sys/security/integrity/owner-cert

Verifying Packages Using OpenSSL

OpenSSL can be used to create keys, sign packages, and verify the signature of those packages. Step 1 Generate OpenSSL keys. a) Generate a private key named private_key.pem.

# openssl genrsa -out private_key.pem 2048 b) Generate a public key named public_key.pem.

# openssl rsa -pubout -in private_key.pem -out public_key.pem

Step 2 Add a signature to the RPM.

# ./SST sign-rpm –priv-key=private_key.pem spm-repo-0.0.2-r0.atom.rpm

30 5 Keys and Certificates Verifying Packages Using OpenSSL

Step 3 Verify the signature of the RPM.

# rpmtools verifyext spm-repo-0.0.2-r0.atom.rpm public_key.pem Verify extend signature OK

Alternatively, rpm -i, smart, or yum to install spm-repo-0.0.2-r0.atom.rpm. The installation forces verification.

Integrity Measurement

Integrity Measurement 33

Integrity Measurement

The IDP XT SRM capability provides two solutions for Integrity Measurement, the IMA-Appraise capability and McAfee Embedded Control. Related Links IMA Appraise on page 33 McAfee Embedded Control on page 34 McAfee Embedded Control uses dynamic whitelisting to ensure that only authorized code can run on the target.

IMA Appraise

The IMA-Appraise capability provides a tamper-proof file system which allows only authorized executables to run on the device. The tamper-proof file system includes the following capabilities: • Prevents unauthorized executable applications from running on the device. • Allows authorized software providers to deploy their applications to the device, where the applications can run without exceptions.

33 Wind River® Intelligent Device Platform XT Security Guide, 2.0

IMA-Appraise is based on confirming that the vendor’s CA certificate has been signed by the owner before installing packages from that vendor. The native IMA component implements three hooks into system calls: sys_exec an application requests that the Linux operating system execute it sys_open an application requests that the Linux operating system read its program from storage sys_mmap an application requests that the Linux operating system load required dynamically linked libraries The following hook is implemented in integrity management: IMA Appraisal Verifies the extended attribute security.ima of the file against the file SHA256 digest. security.ima must contain an RSA digital signature signed by a recognized RSA private key. IMA appraisal relies on the initramfs file system, which is bundled with the Linux kernel image and verified by the secure or trusted boot. The initramfs performs the following functions: 1. Initializes the _ima keyring, where the kernel hold public keys to verify executables. 2. Initializes the IMA policy, which tells the kernel what action it should take when verifying executables. 3. Updates the digital signatures of existing file system entities. Related Links Integrity Measurement on page 33 The IDP XT SRM capability provides two solutions for Integrity Measurement, the IMA-Appraise capability and McAfee Embedded Control.

McAfee Embedded Control

McAfee Embedded Control uses dynamic whitelisting to ensure that only authorized code can run on the target. McAfee Embedded Control has the following capabilities: Ensures that no unauthorized code can run • automatically inventories authorized programs

34 6 Integrity Measurement Integrity Measurement

• prevents all other code from executing • logs attempts to execute unauthorized code Provides real-time tracking of code coming into the enterprise • identifies the source of any new code appearing on the system • automatically include authorized updates in the inventory • ensures authorized installation mechanisms continue to function Ensures that running processes are available • traps unauthorized code injected into running a process • halts unauthorized code before it can gain control of the system • logs attempts to hijack a process Related Links Integrity Measurement on page 33 The IDP XT SRM capability provides two solutions for Integrity Measurement, the IMA-Appraise capability and McAfee Embedded Control.

Secure Repository

The Secure Repository 37 Extended Signature in RPM Design 38 IM Check Structure 38 IM Tools Script Design 39

The Secure Repository

The secure repository relies on enhancements to rpm5, modifications to the build system to implement rpm autosign, and tools for verifying certificates and packages. • rpm5 enhancements include adding a new index to the rpm signature header plus functions to set and test the contents. • RPM autosign applies the keys to the RPM. • The IM check structure provides three layers of checks: 1. The top level provides functions to install certificates, verify the RPM package, and so forth. 2. The second level is an encryption abstraction level to handle different types of encryption. 3. The bottom level is the specific realization of encryption using OpenSSL and RPM.

37 Wind River® Intelligent Device Platform XT Security Guide, 2.0

Extended Signature in RPM Design

The extended signature includes a new index in the RPM signature header and several routines.

Updated RPM Signature Header The new index in the ROM signature header includes a TAG defined as 1280.

When SST (the SRM Signing Tool) signs the RPM package, it generates the extended signature. SST also attaches the IMA signature list to the end of the RPM package and modifies the MD5 TAG in the RPM signature header. When you use the command rpm -i to install the RPM package, the extended signature is verified. If the verification passes, the IMA signature is imported into the kernel to make the binary executable.

IM Check Structure

IM check provides imtools to verify RPM packages and certificates and to import certificates and IMA signature lists into the kernel. The top level is imtools, which provides commands to verify RPM packages and certificates and import the certificates and IM signature lists into the kernel. The table shows the associated commands and their descriptions.

Command Description

imtools --verifycert verify the CA Certificate from vendor and import the verified certificate into the kernel

imtools --listcert list the CA certificates on the target

imtools --removecert remove a CA certificate from the target

The second level is the library level. It is an security option abstraction level that abstracts different security options. The table shows the associated commands and their descriptions.

38 7 Secure Repository IM Tools Script Design

Command Description

srm_verify_cert verify a CA certificate

srm_list_cert list the CA certificates on the target

srm_remove_cert remove a CA certificate from the target

srm_verify_rpm verify a signed RPM package

srm_get_rpmpkg_list get the IMA signature list from the RPM packa

srm_import_ima_signaturelist import the IMA signature into the kernel

The bottom level is the specific realization of the security options. IDP XT uses OpenSSL and rpmtools.

Command Detail

ept_common_verify openssl verify -CAfile $ownercert $vendorcert

ept_get_publickey openssl x509 -pubkey -in $certificate -noout

encrypt_verify_ext rpmtools verifyext $rpm_package $public_key

encrypt_get_nevra rpmtools getnevra $rpm_package

encrypt_update_md5 rpmtools updatemd5 $rpm_package

IM Tools Script Design

imtools provide scripts to verify and manage certificates. The imtools scripts can also be called by rpm. When you use one of the following commands, the imtools scripts process the SRM secure options: rpm -i smart installed imtools --verifycert The imtools --verifycert command verifies the CA certificate from a vendor. Before the device owner accepts files from a vendor, the owner verifies the vendor CA certificate.

39 Wind River® Intelligent Device Platform XT Security Guide, 2.0

If the verification is successful, the vendor’s CA certificate is installed on the device as shown below. If verification fails, the CA certificate is not installed on the device.

imtools --listcert This command lists all CA certificates on the device. imtools --removecert This command removes the named CA certificate from the device. imtools --verifyrpm This command verifies an RPM package on the device. When a device receives RPM packages from a vendor, IDP XT locates the correct CA certificate to verify the RPM. If the process completes without error, the RPM package is successfully verified.

40 8

Encrypted Data Storage

Encrypted Data Storage 41 dm-crypt and cryptsetup 41 TPM-Backed Encrypted Storage 42

Encrypted Data Storage

Encrypted data storage is based on dm-crypt. Where TPM is available, they can provide secure storage of encryption keys. TPM The TPM protects the encryption keys by using the TPM seal or wrap facilities. The encryption key is tied either to a specific TPMPCR value, or to a specific TPM-provided key. TrouSerS provides the application interface for the seal and wrap capabilities. dm-crypt The dm-crypt module uses the key to encrypt the data and generate the encrypted device. The device mounts in the standard way.

dm-crypt and cryptsetup

In the Linux kernel, the device mapper serves as a generic framework to map one block device onto another. It forms the foundation of LVM2, software RAIDs, and dm-crypt disk encryption, and offers additional capabilities such as file-system snapshots. The device mapper works by passing data from a virtual block device (provided by the device mapper itself) to another block device.

41 Wind River® Intelligent Device Platform XT Security Guide, 2.0

The device mapper's "crypt" target provides transparent encryption of block devices using the kernel crypto API. It is part of the device mapper infrastructure, and uses cryptographic routines from the crypto API. It appears as a block device, which can be used to back file systems, swap, or an LVM physical volume. The dm-crypt device mapper target resides entirely in kernel space, and is only concerned with encryption of the block device; it does not interpret any data itself. It relies on user space front- ends to create and activate encrypted volumes and to manage authentication. At least two front- ends are currently available: cryptsetup and cryptmount. IDP XT uses cryptsetup as the front-end of dm-crypt; dm-crypt uses the device mapper and a key to build the disk encryption.

TPM-Backed Encrypted Storage

Encrypted storage can take advantage of TPM security policy to seal the encrypted storage keys. TPM is an implementation of the TPM v1.2 specification, which proposes protocols and standards for attestation, key migration, and secure storage. The TPM v1.2 specification is published by the Trusted Computing Group (TCG). TCG is an industry consortium led by HP, IBM, Microsoft, and others, which coordinates implementations of trusted computing concepts. Their goal is to balance two opposing needs: • To provide secure platforms which can be relied upon for mission-critical operations needed by business and individuals. • Where possible, to avoid the privacy and liberty infringements which trusted computing makes possible. There are 16 or more Platform Configuration Registers (PCRs) in a TPM. They store platform configuration measurements. These measurements are normally hash values (SHA-1) of entities (applications) running on the platform. PCRs cannot be written directly; a process called extending the PCR stores data.

The seal operation converts the plain key, the Data, to a sealed key, the Sealed data in the figure. The sealed key is encrypted in such a way that it can only be decrypted if certain PCRs contain the same values.

42 8 Encrypted Data Storage TPM-Backed Encrypted Storage

Alternatively, you can use a TPM-provided storage root key (SRK) to protect the encrypted storage key. This method does not rely on specifying the firmware and software state. Instead, the method ties the key to the specific TPM as well as to the specific TPM-generated SRK. Therefore migrating the encrypted storage from one system to another renders the data unretrievable. You must take care to ensure that when data migration is required, you take appropriate steps before moving the data off the specific system. To use the cryptsetup tool, the sealed key is unsealed to produce the plain key which is a required argument for cryptsetup.