Securing ML models

Whitebox attacks require the attacker to gain access to the target AI model. Blackbox attacks require the attacker to interact with the target AI model. Machine Learning and Neural Model encryption enables developers to protect their AI models against both by giving them control over who can access and interact with their AI models. It provides this protection by encrypting ML models, wrapping those models alongside a usage policy, and mediating all decryption and usage of those wrapped models.

Knox ML Model Protection consists of the following components:

• Knox ML Encryption Tool — The Knox ML Encryption Tool converts an ML model file and policy information into a Wrapped ML Model file. The input ML model file can be either a Tensorflow Saved Model(.pb) or a TFLite (.tflite) model.

• Knox ML Platform Service — The Knox ML Platform Service is a service component available on Samsung Knox devices. This on-device service interfaces with TrustZone and hardware acceleration features to securely load and execute machine learning models. Android apps running on Samsung devices can communicate with the Knox ML Service through Knox ML APIs in the Knox SDK.

• Knox ML Trusted Applet — The Knox ML Trusted Applet runs in TrustZone to get access to on-device decryption keys. This Trusted Applet integrates with the Samsung Knox Trusted Boot process to ensure that decryption keys are only available when running on trusted firmware.

• Model Protection Key Server — The Model Protection Key Server provisions decryption keys to each device. This server requires that the client device provide a valid Knox Attestation result before provisioning the decryption key. Decryption keys are provisioned to the Knox ML Trusted Applet to prevent them from being leaked.

Wrapping model files

The Knox ML Encryption Tool is responsible for wrapping ML models so they can be securely transferred to the Knox ML service running on target devices. ML models are wrapped using the following hierarchy of keys and data:

• Model Origin Key — This key is provisioned to devices to decrypt Wrapped ML Model files. An ECIES-SECP256R1-AES256-CBC-PKCS5 Model Origin Key is transferred from an HSM to the Knox ML Trusted Applet through a one-time initialization process. During the initialization process, the Model Origin Key is transferred to the Knox ML Trusted Applet over a client-attested, server-authenticated TLS session. The transfer can only be initiated by the Knox ML Service, as validated through Knox Attestation. During the transfer, the Model Origin Key is additionally encrypted using an RSA-PKCS1.5 key that must be derived from a valid Device Root Key. The public component of the Model Origin Key is included with the Knox ML Encryption Tool.

• Model Root Key — This key is used to derive two per-model keys:

  • a model decryption key

  • a model verification key

The Model Root Key is randomly generated when creating a Wrapped ML Model file. This key is then encrypted with the Model Origin Key using ECIES-SECP256R1-AES256-CBC-PKCS5, then included within the Wrapped ML Model file. The Knox ML Trusted Applet is able to decrypt this key once it receives the appropriate Model Origin Key.

• Model Decryption Key — This key is derived using HMAC-SHA256 from:

  • the Model Root Key

  • a salt value that is randomly generated when creating the Wrapped ML Model file

  • a constant string

This key is used directly to encrypt the machine learning model file using AES256-GCM. The Model Decryption Key is unique and distinct for each Wrapped ML Model. To support parallel decryption, large models are split into multiple blocks. Each block is encrypted using AES256-GCM using a distinct IV, and the block index used for ordering is included as part of the Authenticated Additional Data.

• Policy File — The Policy File includes information such as dictating which apps can use the ML model. The policy file must specify the list of allowed apps by package name, developer key, and minimum version code. The Knox ML service requires any apps using a model to match an allow rule in this policy file.

• Model Metadata — The Model Metadata includes:

  • the encrypted Model Decryption Key

  • a model identifier that acts as a semantic identifier usable by policy files

  • a model version code

  • the model policy that determines usage restrictions

  • a reference to the Model Origin Key that may be used to decrypt the model.

  The purpose of the Model Metadata is to associate each ML model with a policy file. The Wrapped ML Model file includes an authentication code calculated over the Model Metadata to prevent it from being modified.

• Model Validation Key — This key is derived using HMAC-SHA256 in the same way as the Model Decryption Key using (1) the same Model Root Key, (2) the same salt value, and (3) a different constant string. This key is used to generate an HMAC-SHA256 authentication code for the Model Metadata. The Knox ML Trusted Applet only accepts decryption requests where the calculated authentication code matches the authentication code stored in the Wrapped ML Model file. This authentication code informs the Knox ML Trusted Applet that the given encrypted model was intended to be used with the given policy.

In conjunction, these keys and metadata bind a policy file to each ML model. This ensures that Knox ML is in the critical path for decryption and policy validation, and that only Knox ML can decrypt Wrapped ML Model files. Thus, this enables Knox ML to enforce flexible policies on ML model usage.