Short position paper: Mobile Device Attestation

The controller within the meaning of data protection law pursuant to Art. 4 No. 7 of the General Data Protection Regulation (GDPR) is generally the app operator, as he, alone or jointly with others, decides on the purposes and means of processing. Pursuant to Art. 32 GDPR, he must implement technical and organizational measures (so-called TOMs) to ensure the security of processing. This includes both the parts of the processing taking place in the operator’s backend and the parts taking place directly on the users’ terminal devices.

The operator can structure the processing so that the processing of personal data necessary to provide the service takes place in the backend as far as possible. This happens under his direct (technical) control, as he either operates the systems himself or uses a processor who is bound by his instructions in accordance with Art. 28 (3) (a) GDPR. Nevertheless, some processing (usually at least input and output functions and access to the backend) will inevitably take place on the terminal device. Here, too, he, as the controller, must use appropriate TOMs. This could include using operating system functions such as protected memory areas or the prevention of screenshots. The implementation of his own measures is also conceivable. The measures mentioned are directly aimed at protecting the data on the terminal device during processing. Furthermore, the operator may also be interested in additionally securing access to the backend against attackers, for example as protection against bots. After all, in many cases, other users’ personal data are also likely to be processed in the backend.

Through his technical control, the operator can directly check the correct functioning of the TOMs implemented in the backend. In contrast, he, (for good reasons) does not have a corresponding degree of control over the users' terminal devices and must rely on the TOMs implemented there to be executed according to the operators’ expectations. The operator is therefore acting on the basis of security assumptions. If the terminal device or app is compromised – for example, by malicious apps and other malware on the device or by using a modified app – the operator can be deceived about the correct functioning of the app – and the security assumptions would then no longer be valid. To obtain an indicator of whether the terminal device is in a state in which the operators’ security assumptions are valid, many operators want to use the method of so-called Mobile Device Attestation.

What is Mobile Device Attestation?

Mobile Device Attestation is a class of services providing an assessment of the state of the system under consideration, a so-called Integrity Verdict. Various techniques can be used to generate an Integrity Verdict. One method is the cryptographic certification of a defined device state, for example, in the form of the integrity of a trust chain consisting of the device certificate, bootloader, and operating system kernel. Heuristic methods provided by mobile platform providers are also often used. These include Google's Play Integrity Services and Apple's DeviceCheck; there are also third-party services in the area of mobile device management. These methods are intended to allow conclusions about the device's state by linking a variety of metrics. Examples of checks for signs of rooting or jailbreaking, bootloader unlocks, and integrity violations of system partitions have already been observed. This also includes proxy detection, API hooks, and log file analysis. The exact functioning of such heuristic techniques is usually only known to the providers of the attestation services and is not fully documented transparently – not even for the app operator.

Using the Integrity Verdict, the app operator can then decide whether the assumptions underlying the app's security model are likely to be met or not. In practice, this can serve several purposes, such as protecting the users, the network of all devices using the app, or the app backend from potential threats posed by compromised devices or modified apps. It is state of the art that the Integrity Verdict is evaluated not directly on the potentially compromised device, but in the backend of the digital service.

What data protection issues arise when using Mobile Device Attestation?

Is Mobile Device Attestation a processing of personal data?

An Integrity Verdict created on the user's device during Mobile Device Attestation can, inherently, be uniquely attributed to this personal device and thus to a data subject. In addition, the provision of attestation services on the device often requires the user to have a personal account with the respective platform operator. When creating the Integrity Verdict, device or network identifiers such as the International Mobile Station Equipment Identity (IMEI), the Mobile Equipment Identifier (MEID), the International Mobile Subscriber Identity (IMSI), the IP address or information about the services and apps used on the device can conceivably also be evaluated. Therefore, the Integrity Verdict generally is personal data according to Art. 4 No. 1 GDPR, the processing of which, such as storage, reading or transfer, constitutes processing of personal data according to Art. 4 No. 2 GDPR.

When generating the Integrity Verdict, data stored on the device are also processed. If the app operator does not have documentation of exactly which data are being processed, but if these data necessarily relate to the individual state of the device and the software components running on it, and, as the case may be, to any data stored on these components, it must be assumed that personal data are being processed. With the Integrity Verdict, some attestation procedures also return personal data such as the device's IMEI and MEID verbatim to the attestation service provider and the app operator. In such a case, personal data are also being read (and thus processed) from a device.

Who is the controller?

The controller within the meaning of data protection law is the person who decides on the purpose and means of processing. When creating the Integrity Verdict, a distinction must be made as to whether personal data are being processed continuously or regularly for this purpose, for example as part of the platform services of the terminal device, or whether this only happens when an Integrity Verdict is requested by the app. Ongoing creation is likely to be a separate processing operation for which the provider of the attestation service is the controller, as this provider determines both the purpose of the processing – namely the advance creation of the Integrity Verdict as part of the Mobile Device Attestation service offered to app operators – and the means used for this purpose. If processing only occurs when an Integrity Verdict is requested by the app, the decisive factor is the implementation in the individual case. For example, it is generally conceivable that the processing is carried out by the provider of the attestation service on behalf of the app operator as the controller.

When using the Integrity Verdict, the app operators integrate the Mobile Device Attestation service to achieve a purpose they define. They determine the means of processing by integrating a specific Mobile Device Attestation service into their app, and they define the purposes of the processing for which the Mobile Device Attestation service is integrated. This applies even if they follow a technology- neutral technical guideline: In this case, too, they themselves determine the purposes and means, even if the implementation of the guideline may be legally required for a given application.

An example of a technology a technology-neutral technical guideline that generally provides for the use of an integrity check without specifying the services or technologies to be used is TR-03161 of the Federal Office for Information Security (BSI), which is set out in Part 1, Version 3.0, requirement O.Resi_5.

What data protection requirements arise from this?

An Integrity Verdict can only provide information about the system state at the time of generation. Therefore, each newly requested statement about the current state requires the processing of fresh data from the terminal device to create an Integrity Verdict (that is itself personal data). Either the source data or the resulting Integrity Verdict are then retrieved from the terminal device for further analysis and processed in the app operator's backend. Both represent a readout of data stored on the terminal device within the meaning of the Telecommunications Digital Services Data Protection Act (TDDDG). According to Section 25 TDDDG, access to information already stored in a terminal device requires either user consent or absolute necessity for providing the desired service. With regard to Mobile Device Attestation, absolute necessity for providing the desired service cannot be assumed across the board. If the app operator nevertheless refers to such an absolute necessity for providing the desired service, within the scope of his accountability, he is at least responsible to prove that the function corresponds to the purpose of the processing and thus that it is effective on a technical level.

App operators require a suitable legal basis for processing the Integrity Verdict. If consent is given in accordance with Art. 6 (1) (a) GDPR, it must be ensured that the requirements of Art. 4 (11), Art. 7, and, if applicable, Art. 8 GDPR are also implemented. Particularly with regard to the voluntary nature of consent, it is necessary to consider that, subject to a specific case-by-case assessment, the use of the app must also be possible without consent to the Mobile Device Attestation. If the controller intends to base the processing on a legitimate interest, among other things, it is required to carry out a balancing of interests, and to provide an option to object to the processing in accordance with Art. 21 GDPR. See also the corresponding Guideline 1/2024 of the European Data Protection Board (EDPB). Information such as services and apps used on a device that relate to the physical or mental health of users, including the provision of healthcare services, and from which information about the user's state of health can be inferred, is health data according to Art. 4 No. 15 GDPR. Their processing, for example to establish an Integrity Verdict, is generally prohibited according to Art. 9 (1) GDPR unless there is a legal basis according to Art. 9 (2) GDPR.

In the case of apps implementing or supporting services of general interest, it must also be examined whether the automatic evaluation of an Integrity Verdict and a functional restriction of the app resulting from a negative Integrity Verdict in the specific case constitutes (impermissible) automated decision-making with legal effect pursuant to Art. 22 GDPR.

The app operator must also be able to demonstrate that he actually complies with the data protection requirements arising from his legal position vis-à-vis the provider of the attestation service. This may, for example, involve concluding a data processing agreement or an appropriate agreement regulating joint controllership with the provider of the attestation service.

In addition, the principles of processing personal data pursuant to Art. 5 (1) GDPR give rise to further requirements that must be implemented. In addition to an appropriate level of transparency of the processing vis-à-vis the app users as data subjects, a function appropriate to the purpose must be mentioned here, which the controller must ensure. In its Guidelines 4/2019 on Data Protection by Design and by Default, the EDPB demonstrates that algorithms that are functioning in line with the processing are an essential requisite for the fairness of processing and thus for the principle of fair processing pursuant to Art. 5 (1) (a) GDPR. The principle of data minimization pursuant to Article 5(1)(c) GDPR must also be respected, so that only those personal data that are adequate, relevant and necessary for the purpose may be processed when creating and evaluating the Integrity Verdict. Furthermore, a sudden exclusion from important  services may restrict the availability of processing and thus actively counteract the purpose of ensuring the security of processing.

The app operator as the controller must be able to demonstrate compliance with these requirements in accordance with Art. 5 (2) GDPR as part of his accountability.

Conclusions

If data controllers use a Mobile Device Attestation in the apps they operate, the data protection dimension must also be considered. Users need to be informed about the consequences of a negative Integrity Verdict and should be given the opportunity to make an informed decision to still use the app following their information, apart from exceptional cases that need to be justified in a transparent way.
The absolute necessity to use Mobile Device Attestation on the terminal device in order to ensure the security of processing in the backend is unlikely to exist in general. If app operators nevertheless claim this absolute necessity applies, they are also responsible for proving the necessity of this implementation and the technical effectiveness of this measure in the specific case. A more detailed discussion of the requirements arising in particular from the TDDDG can be found in the Digital Services Guidance of the Data Protection Conference (DSK) (only available in German).
App operators must also consider whether they are unlawfully implementing automated decision-making with legal effect through the use of Mobile Device Attestation if a negative Integrity Verdict could result in a sudden exclusion from important services. This is especially true if the application is a public service of general interest or other important services such as e-prescriptions or online banking.
Even if technical effectiveness can be demonstrated, it is essential to also examine whether the processing of personal data associated with device attestation is appropriate, relevant, and limited to what is necessary in the overall context of the app's objectives. Any processing of personal data constitutes an interference with the right to informational self-determination, which must be proportionate to the intended purpose of the processing.