BSI publishes security requirements for smartphones


As a basis for discussion on the development of security requirements for smartphones, the Federal Office for Security in Information Technology (BSI) has developed a catalogue of requirements Published.

For improved security of smartphones, the requirements catalog lists criteria that smartphones should meet in the delivery state and beyond. The BSI sees the catalogue of claims as a starting point for a public discourse with manufacturers and OEMs (Original Equipment Manufacturers, OEMs), network operators and civil society.
Federal Office for Information Security (Picture: BSI)
The BSI aims to involve all social groups in the further development of these requirements, which are to be incorporated into guidelines for the granting of the IT security label for smartphones planned by the Federal Government in the future.

“Smartphones have developed into a control centre in recent years, through which we control and handle more and more everyday operations. Insecure smartphones can therefore have very real negative effects very quickly. Consumers should be able to rely on a smartphone to include basic IT security at the time of purchase, so that they can make the most of the possibilities offered by digitalisation. Manufacturers and OEMs are therefore called upon to make the devices as safe as possible, right from the start and over a period of service life. Our catalogue of requirements is a guide to more security-by-design and security-by-default,” emphasizes BSI President Arne Schönbohm.

The BSI’s requirements catalog contains criteria for securing the devices by certain hardware properties as well as for curing and protecting the software contained in the delivery state.

In addition, the catalog specifies and standardizes requirements for providing updates during the runtime of the devices. In addition, the catalogue includes criteria for the protection of user data, for example in the field of telemetry functions, as well as for greater transparency for consumers.

Here is the catalogue of demands in the text:

Manufacturer requirements for the safety of smartphones

1. Introduction

This catalogue of requirements is aimed at oems, so-called Original Equipment Manufacturers (OEM) of smartphones. It describes the required basic equipment of the devices from an IT security perspective during delivery as well as measures for safe operation.

The implementation of the requirements, which are described in general in the individual chapters, must be carried out according to the respective state of the art. In addition, the referenced bsi technical guidelines to be taken into account.

2. Catalogue of receivables

2.1 Conformity to EU and national law

Each new device or apps pre-installed by the manufacturer and the related services must comply with the requirements of the General Data Protection Regulation of the European Union (EU-DSVGO) as well as the national data protection regulations in Germany. A corresponding declaration must be made by the manufacturer.

In order to underline the importance of this requirement, it is partly repeated in the following chapters.

2.2 Timeliness

2.2.1 Up-to-dateness of the OS version

For each device type, a statement must be made about the supply of operating system updates (major versions). This declaration must include the duration of support in years after release and the minimum number of scheduled major releases. (This assumes that mobile operating systems are released annually in a new major version.)

New devices must be equipped with the latest (latest) operating system available at the time of device release. If a newer operating system is available at the time of device commissioning, it must be offered for installation.

2.2.2 Security Update Support

Devices must be supplied with security updates for 5 years after device release. The device description must clearly indicate when a device will fall out of the supply of security updates.

The security updates must close all known vulnerabilities of all software components (driver, operating system, customized software layer and pre-installed apps). This must be set out in a bulletin in full and transparent.

2.2.3 Duration until security updates are rolled out

Security updates must be deployed for installation within one month of release.

2.3 Protection against unauthorized access to the terminal

2.3.1 Lock Mechanism

At least one of the following mechanisms to unlock the device must be in place and must be securely implemented:

  • Alphanumeric password
  • Fingerprint
  • Face recognition / 3D face recognition
  • High secure biometric scan

2.3.2 Device encryption

Devices must be equipped with full disk encryption for internal, fixed storage. In addition to the user password, the key material used for encryption must be based on a device-specific, individual feature. The key material must be stored securely, see chapter “Safe Flow Environment/HSE”.

2.3.3 Encryption of the SD card

For devices with an external memory card, there must be the possibility of secure encryption.

2.3.4 Safe Drain Environment / HSE

The device must contain a Trusted Execution Environment (TEE) that is separate from the normal operating system. This must be based on a Hardware Secure Element (HSE). The HSE must also be used to protect critical data. See also chapter “Dedicated Hardware for Cryptographic Functions”.

2.3.5 Safe boot process

In a secured boot process, each level performed checks the next level for integrity and authenticity before giving it control. It also uses the first stage of the process, the boot loader, to verify the integrity and authenticity of updates. Changes must be logged and the boot process must be aborted. The user must be offered a recovery option of the delivered system state. In addition, the possibility should be offered to turn off the device.

2.3.6 Unlocking the Boot Loader

A process to unlock the boot loader must be offered. This process must be transparent, i.e. the manufacturer must provide a tool for doing so and/or provide an easy-to-understand instruction.

During the unlocking process, all user data generated to date must be safely deleted.

In addition, after the boot process is complete, the user must be shown an understandable indication of the unlocked boot loader, indicating the potential risks.

2.3.7 Cyphering

The use of the latest radio channel cyphering algorithms of phones has from a network point of view very high priority. Devices that support the latest algorithms are better protected.

New equipment must be equipped according to the state of the art, i.e. support the latest algorithms. For more information: see the Technical Directive of the BSI TR-02102 chap. 4.7 “Cyphering.

2.4 Privacy

2.4.1 Pre-installed apps in the system partition

Only apps that require special (system) permissions may be installed in the system partition (example: Signature Permission for Android). On the other hand, standard user apps, such as the manufacturer’s own browser or third-party apps, may not be installed there.

2.4.2 Permissions for (pre-installed) apps

Apps are only allowed to apply for the permissions they absolutely need to perform their task. Before using a critical1 app permission in an application for the first time, the user must agree to this. Once granted permissions can be revoked. Rejected requests can be given retrospectively. Rejected or revoked permissions may cause traceable functional limitations, but not crashing the app. There must be a menu item about app permissions that reflects all public and internal permissions. There must be a complete and comprehensible description of the permissions.

This requirement applies in principle to all mobile apps. In this receivables catalog, the focus is on the apps pre-installed in the delivery state of the device.

1 Critical App Authorization: Permissions that allow access to personal data (e.g. contacts, message content, geodata), allow the manipulation of security-relevant system functions (for example, visually overlay system dialogs or settings) or whose use can cause costs for the user.

2.4.3 Secure Software Development Process

As part of a secure software development process, the platform manufacturer’s requirements must be implemented. For Android, this, for example, “Google Best Practices”. Additional policies for secure software development, such as the Mobile AppSec Verification Standard of the OWASP.ORG should also be considered.

2.4.4 Telemetry

The term telemetry data summarizes all data (user and usage data, system data) that a manufacturer collects on a device in order to further develop its products. The manufacturer may only process or pass on this data for this purpose with the prior explicit consent of the user. There must be a detailed and comprehensible description of the data collected and sent. The recording and discharge of the telemetry data must be limited to a required minimum.

The manufacturer must make a GDPR-compliant declaration on the collection and processing of telemetry data for the smartphone, consisting of operating system, manufacturer branding and pre-installed third-party apps. In the event of rejection by the user, no telemetry data may be collected, processed or transferred.

2.4.5 Secure Software Platform

For the manufacturer’s software installations and updates, a secure platform must be available that does not use the device and user information that this platform requires to perform its services for any other purpose, nor may it be shared with third parties. To do this, the provider must make a GDPR-compliant declaration.

2.4.6 Network Gateways

The data exchange of a device with the Internet must be carried out via the gateway proposed or self-registered by the network operator. There must be no hardcoded (non-changeable) relapse options over other servers.
The same applies to DNS configuration.

2.5 Minimize Attack Surface 2.5.1 Cloud Services

The use of cloud services must be displayed to the user prior to the first use and must be compliant with the GDPR. The use of all cloud services must be clearly displayed. New devices must not include preconfigured cloud services (examples: Google account, manufacturer apps). This includes the fact that there are no local services enabled that can communicate with these cloud services. The use of cloud services can be rejected or revoked, whereby non-anonymized data in the cloud must be deleted.

2.5.2 Basic configuration at purchase

In the delivery state, relevant settings must be selected in such a way that the security aspect is prior to the user’s comfort. You must be warned about unsafe settings. For example, offers for setting up a screen lock and for disk encryption.

2.5.3 Interfaces

Wi-Fi: The automatic connection to known WI-Fi must be turned off. Lists of known Wi-Fi access points stored in the device must be visible and editable. SSIDs may not be sent in so-called “WiFi probe requests”. In addition, the MAC address must be anonymized during the network search.

Bluetooth: The user must be configurable to use the Bluetooth interface. It must be switch-off at any time.

NFC: The NFC interface used must be GsM Association’s NFC Handset Test Books (TS 27). The use of the NFC interface must be configurable by the user. The interface should be turned off by default. Before data is loaded onto the end device via the NFC interface or an application – e.g. a payment service – uses this interface, the transmission or use by the user must be explicitly approved. The NFC interface must be separated appropriately in the operating system. There must be safeguards against unauthorized communication attempts and no unsigned code must be transmitted. In particular, only trusted connection attempts or certified applications should be accepted.

2.5.4 Dedicated hardware for cryptographic functions

The essential cryptographic functions of the operating system must be supported by dedicated hardware. In particular, all cryptographic keys must be managed directly in secure hardware by a certified Cryptographic Service Provider. The export of private and secret keys may only take place in a secure form.
Hardware support must be used for the security features fully disk encryption, Secure Boot, FIDO2, used by the operating system itself, and must also be made available to applications. The execution of security-critical applications in the form of applets on the hardware itself must also be supported.

The hardware element used must be used according to the Protection Profile “Cryptographic Service Provider” (BSI-CC-PP-0104-2019) or “Cryptographic Service Provider Light” (BSI-CC-PP-0111-2019 Commen- Criteria-certified.

Furthermore, it is necessary that the hardware element used is able to use eID applets in accordance with Section 2.2.4 of the BSI-TR 03159-2 “Mobile Identities Part 2: EAC and FIDO based mobile identities” to be processed.

2.5.5 Processor Security Features

The processor must use hardware-based security to help the operating system defend against attacks. These include mechanisms for mitigation of ROP/JOP attacks (pointer authentication), attacks on speculative execution, storage encryption, and separation mechanisms (Trusted Execution Environments).

2.6 Advanced Requirements 2.6.1 Data Migration for PIM Data

It must be possible to export so-called Personal Information Management (PIM) data in a standardized data format so that this data can be easily imported on another device. PIM data includes contacts, appointments, tasks, and notes, as well as local emails.

2.6.2 Localization of central services

Operating system-relevant services as well as services of system-integrated apps must be hosted and processed in German data centers. This includes, but is not only one of the updates servers, as well as the external processing of telemetry data.

2.6.3 FIDO2 Authentication

The device must offer a FIDO2 standard authentication mechanism that allows the user to easily authenticate to web services. The FIDO authenticator must be certified at least according to FIDO Level 2.


Please enter your comment!
Please enter your name here