User Tools

Site Tools


mobile-linux:mobile_platform_security_guidelines

Contents

Introduction

The Mobile Linux Platform security section contains security objectives and guidelines essential to analyzing and mitigating threats and improving resiliency to attacks on mobile Linux-based systems. These guidelines support security objectives for mobile systems derived from assumptions based on the following:

  • Intended use of the systems
  • Environment in which the systems operate
  • Security policies that carriers will expect to be observed by such systems
  • Exposure of such systems to expected threats and vulnerabilities

Mobile devices are characterized by the following:

  • They have a single user.
  • The user does not have administrative or root access; this is reserved to the carrier.
  • MLI systems are configured without shell access.
  • MLI systems typically present non-standard or custom user interfaces.

The Mobile Linux Platform Security section contains guidelines essential to ensuring and maintaining operational integrity of mobile devices, both internal- and external-facing. An example of an internal-facing security guideline is:

  • A program should not be able to access protected data on a device for which it does not have clear authorization.

An example of an externally-facing guideline is:

  • A program should not be able to interfere with the operation of the network used by the device.

Some general guidelines that were used to develop these guidelines for security for mobile devices are described below. Specific guidelines are driven by specific objectives including:

  • Confidentiality - Secret things should stay secret
  • Origin integrity - Only code that is certified to run gets run
  • Resistance to external threat - Bad guys can't keep me from using my phone
  •  ??? - You can't use my phone to attack a trusted network
  •  ??? - You can't use a trusted network to attack my phone

For some types of phones, capabilities are specified that enable the network operator to add:

  • Digital rights management (DRM) – To prevent the user from improperly using content.
  • Attestability – To enable a device to be measured for trust assurance. The ability to trust the device to be measurable to allow for attestation generally implies that the measuring agent and data paths can be trusted. This is typically going to result in a trusted platform position, which in turn drives requirements for the platform from well before Linux ever starts to execute.

Security Guidelines

SEC.1.0 Confidentiality

Linux Foundation MLI specifies that system software MUST provide a robust set of cryptographic primitives.

SEC.1.1 Configurability—Minimal Strength

Description: Linux Foundation MLI specifies that the system software SHOULD be configurable to disallow low-strength cryptography.

SEC.1.2 Configurability—Maximal Strength

Description: Linux Foundation MLI specifies that the system software SHOULD be configurable to disallow high-strength cryptography.

SEC.1.3 “Token” Interface

Description: Linux Foundation MLI specifies that the system software MUST provide a standard interface or interfaces to hardware and software cryptographic/security tokens (e.g. OpenSSL, PC/SC. PKCS#11, PKI)

SEC.1.4 Vaulting Services

Description: Linux Foundation MLI specifies that the system software SHOULD provide a facility to allow trusted processes to store sensitive information in a “secure facility”. To ensure the security of such a facility, all processes able to access vaulted information must be at a sufficient level of mutual trust.

Any process shall be able to store data inside the vault. The data would be visible only to the creator and to specified high trust level processes (e.g. backup application).

SEC.1.5 Cryptographic Certification

Description: Linux Foundation MLI specifies that the system software SHOULD provide the ability to specify a FIPS-140 or Suite-B mode in which only cipher-suites defined by those standards are active.

SEC.1.6 Data Clearing

Description: Linux Foundation MLI specifies that the system software MUST provide a mechanism for clearing user data. The mechanism may be activated manually by the user, or automatically by the system in case security of the device is compromised.

SEC.2.0 Origin Integrity

Linux Foundation MLI specifies that system software MUST provide mechanisms to distinguish the origin, and insure the integrity, of programs, libraries and other resources utilized by the system. Such mechanisms would typically include the use of certificates, signed binaries, etc.

SEC.2.1 Initial Trusted Root Certificates

Description: Linux Foundation MLI specifies that the system software MUST provide the capability to be pre-configured with a base set of trusted certificates.

SEC.2.2 Configurability of Root Certificates

Description: Linux Foundation MLI specifies that the set of trusted root certificates MUST be configurable by the device manufacturer, the network operator, corporate customers. The set of trusted root certificates MAY be configurable by the end user.

SEC.2.3 Application of Distinct Certificates

Description: Linux Foundation MLI specifies that the system software SHOULD support different “kinds” of trust for different certificates, e.g. a certificate which may allow email signing may not be trusted for code signing.

SEC.2.4 Certificate Management, Modification of Certificate Metadata

Description: Linux Foundation MLI specifies that the system software MUST provide a robust interface for the addition and deletion of certificates and for the alteration of certificate-related metadata.

SEC.2.5 Control of Certificate Management

Description: Linux Foundation MLI specifies that the interface for updating certificate metadata MUST be “protected.” In other words, messages that update certificate trust metadata MUST be signed by keys derived from a previously trusted root.

SEC.2.6 Types of Trust

Description: Linux Foundation MLI specifies that the types of trust to be supported MUST include (but are not limited to): SSL Server, Email Signing, Email Encryption, Policy Update, Root Key Update, Code Signing

SEC.2.7 Dynamic Policy

Description: Linux Foundation MLI specifies that trust policy SHOULD be updateable by a sufficiently authorized entity at runtime.

SEC.2.8 Code Signing Not Required

Description: Linux Foundation MLI specifies that the system software SHOULD support code signing, but not necessarily require it.

SEC.2.9 Capabilities of Signed Executables and Policy

Description: Linux Foundation MLI specifies that signed executables or shared object libraries MUST map to “policies” that describe what an application signed with a particular key can do. (I.e. signed applications may be able to access the SMS APIs without querying the user while non-signed applications may require the user to explicitly allow use.)

SEC.2.10 Trusted Boot

Description: Linux Foundation MLI specifies that the system software SHOULD be configurable to boot from a “known-good” state, and only launch certified executables. This would require facilities to exert control over the operation of the system software prior to the actual initiation of the kernel.

SEC.2.11 Attestability

Description: Linux Foundation MLI specifies that the system software SHOULD enable network operators and/or service providers to make measurements to determine that the platform on which the system software is running is in a “known-good” configuration for device management and high-value content services (for trusted network management and service attestation)

SEC.3.0 Resistance to External Threat

Linux Foundation MLI specifies that the system software MAY provide mechanisms to avoid the subversion of its operation by unprivileged parties.

SEC.3.1 Authentication

Description: Linux Foundation MLI specifies that the system software MAY be configurable, either by the carrier or by the user, to provide secure authentication and the ability to apply new authentication mechanisms.

SEC.3.2 Extensible Authentication Mechanism

Linux Foundation MLI specifies that the system software MUST support a mechanism for implementing new operating system authentication mechanisms.

SEC.3.2.1 Dynamic Loading of Authentication Modules

Description: Linux Foundation MLI specifies that the system software mechanism of MLISEC 3.2 MUST allow for dynamic loading of authentication modules.

SEC.3.3 Network Security

Description: Linux Foundation MLI specifies that the system software MUST provide mechanisms to provide integrity and confidentiality of network transmissions to and from the system.

SEC.3.4 Resource Management

Description: Linux Foundation MLI specifies that the system software MUST provide support for limiting the resource usage of users and processes. In particular, per-process limits on memory, file-system quotas, the number of processes which can be created, etc., will be controllable via policy.

Opportunities for Standardization

  • Certification Profile for Code Signing, Key Management Messages and Policy Update Messages
  • Techniques and data formats for executable and shared object library signing
  • Techniques and data formats for application distribution packaging
  • Key Management and Policy Update Message Formats and Semantics
  • Representation of distributed security policies
  • Semantics for distributed security policy assertions
  • API for Policy Queries
  • API for Crypto Services
  • API for Vault Management Services
  • API for Key Management
  • API for Attestation
  • “Assurance” processes to certify compliance with protection profiles

Contributors

  • Ron F. Buskey - Motorola, Inc.)
  • Matthew Hamrick - Access Company Ltd)
  • Toni Piponius
  • Rob Rhoads - Intel, Inc.
  • David “Lefty” Schlesinger - Access Company Ltd (spec editor)

Appendix A - Security References

TBS

mobile-linux/mobile_platform_security_guidelines.txt · Last modified: 2016/07/19 01:22 (external edit)