Welcome to the dreiAttest White Paper!¶
You’ve found our white paper going into the technical details of how dreiAttest works behind the scenes. For information on how to use dreiAttest in your project check out the GitHub page of the corresponding package:
Introduction¶
dreiAttest is a framework built on top of Apple’s DeviceCheck and Google’s SafetyNet. It protects services by restricting access to the corresponding App and genuine iOS / Android devices, e.g. preventing access via scripts. Furthermore, dreiAttest can be extended through plug-ins to enforce different policies such as evaluating Apple’s risk metric or by using the per-device data.
Limitations¶
DeviceCheck / SafetyNet cannot determine the integrity of the operating system. Under some circumstances it may also be possible to manipulate the local data stored by an app without it being possible to detect such tampering via DeviceCheck / SafetyNet. Furthermore DeviceCheck cannot be used in App Extensions.
Structure¶
On a high level dreiAttest consists of 2 components: a mobile library (implemented for iOS, Android, and Kotlin multiplatform) and django specific library running on the server. Before a request can be sent the mobile library generates a key pair and registers it with the server. During the registration process DeviceCheck / SafetyNet is used to attest that the key was generated by a genuine installation of the app. The server is responsible for validating the attestation with the help of a view decorator and storing the public key by exposing different api endpoints for the mobile clients. Afterwards the private key is used to sign any requests sent to the server and the view decorator can verify that it was signed by a genuine installation.