• 1 Introduction
• 2 Security Guidelines
  • 2.1 SEC.1.0 Confidentiality
    • 2.1.1 SEC.1.1 Configurability—Minimal Strength
    • 2.1.2 SEC.1.2 Configurability—Maximal Strength
    • 2.1.3 SEC.1.3 “Token” Interface
    • 2.1.4 SEC.1.4 Vaulting Services
    • 2.1.5 SEC.1.5 Cryptographic Certification
    • 2.1.6 SEC.1.6 Data Clearing
  • 2.2 SEC.2.0 Origin Integrity
    • 2.2.1 SEC.2.1 Initial Trusted Root Certificates
    • 2.2.2 SEC.2.2 Configurability of Root Certificates
    • 2.2.3 SEC.2.3 Application of Distinct Certificates
    • 2.2.4 SEC.2.4 Certificate Management, Modification of Certificate Metadata
    • 2.2.5 SEC.2.5 Control of Certificate Management
    • 2.2.6 SEC.2.6 Types of Trust
    • 2.2.7 SEC.2.7 Dynamic Policy
    • 2.2.8 SEC.2.8 Code Signing Not Required
    • 2.2.9 SEC.2.9 Capabilities of Signed Executables and Policy
    • 2.2.10 SEC.2.10 Trusted Boot
    • 2.2.11 SEC.2.11 Attestability
  • 2.3 SEC.3.0 Resistance to External Threat
    • 2.3.1 SEC.3.1 Authentication
    • 2.3.2 SEC.3.2 Extensible Authentication Mechanism
      • 2.3.2.1 SEC.3.2.1 Dynamic Loading of Authentication Modules
    • 2.3.3 SEC.3.3 Network Security
    • 2.3.4 SEC.3.4 Resource Management
• 3 Opportunities for Standardization
• 4 Contributors
• 5 Appendix A - Security References

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.

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

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

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

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)

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).

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.

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.

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.

Description: Linux Foundation MLI specifies that the system software MUST provide the capability to be pre-configured with a base set of trusted 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.

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.

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.

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.

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

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

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

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.)

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.

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)

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

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.

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

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

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.

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.

• 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

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

TBS