3, block 2004).

FIGS. 4A-4E are sequence diagrams illustrating messages communicated between and actions taken by components illustrated in FIG. 1 to implement secure access point authentication credential generation in a mobile device according to some examples. In this implementation the secure credential task 60 executing on the mobile device 42 executes in the primary operating system (OS) of the mobile device 42, such as the Android® OS, the Apple® iOS OS, or the like, and communicates, such as via an API, with the secure enclave 58. Depending on the implementation of the secure enclave 58, the secure enclave 58 may execute in a separate OS and may execute via a secure enclave processor device that is different from the processor device 48.

The secure credential task 60 may be provisioned by the ISP 12 to execute upon startup of the mobile device 42 in the background such that the subscriber 38 may be unaware of the execution of the secure credential task 60. The secure credential task 60 may be provisioned by the ISP 12 with an address of the computing system 14. The secure credential task 60 may determine that there is no Wi-Fi network established on the mobile device 42 and thus may utilize the cellular network 54 for communications initially. The secure credential task 60 may initially determine that the secure channel 62 has not yet been established between the mobile device 42 and the computing system 14. This may be determined, for example, by the lack of information in the storage device 46 that would exist if the secure channel 62 had been established.

The secure credential task 60 initially sends a registration message to the computing system 14 (step 3000). The registration message may be any suitable message known to the secure credential task 60 and the credential provider task 61 to be an initial registration message. The computing system 14 determines that the registration message lacks a JSON Web Token (JWT) and in response sends a message, such as, by way of non-limiting example, a status 403 message, that indicates that the registration message is incomplete (step 3002).

In response, the secure credential task 60 sends a request to the computing system 14 to obtain a verification value, sometimes referred to as a nonce (step 3004). The request may, in some implementations, be issued via a HTTP POST method. The request may include metadata, such as an operating system identifier (ID) that identifies the primary OS of the mobile device 42 and an application ID that identifies the secure credential task 60. The computing system 14 receives the request and verifies that the operating system ID and application ID are suitable, and sends a message to the secure credential task 60 with a verification value (step 3006). The verification value may, for example, be a random number or alphanumeric string generated by the computing system 14. The computing system 14 stores the verification value for later use (step 3008). The secure credential task 60 sends a request that includes the verification value to the secure enclave 58 to generate a public key/private key pair, to send the public key to the secure credential task 60, and to encrypt the verification value with the private key (step 3010). The secure enclave 58 generates a public key/private key pair, encrypts the verification value with the private key to generate an encrypted verification value, and sends the public key and the encrypted verification value to the secure credential task 60 (steps 3012, 3014, 3016). The private key does not leave the secure enclave 58.

The secure credential task 60 cause an attestation to occur via an attestation service (step 3018). The secure enclave 58 communicates with a predetermined attestation service to obtain an attestation token (step 3020). The communication includes the encrypted verification value which will be included in the attestation token. Any suitable attestation service may be used. In one implementation, the attestation service is the Google® Play Integrity attestation service. The secure enclave 58 receives an attestation token from the attestation service and sends the attestation token to the secure credential task 60 (step 3022). The attestation token uniquely identifies the mobile device 42.

The secure credential task 60 sends a request to the computing system 14 to obtain a JWT (step 3024-1). The request includes the attestation token, the encrypted verification value, the public key, and may include additional information such as the OS ID that identifies the primary OS of the mobile device 42 and the application ID that identifies the secure credential task 60. In some implementations, the request may be issued via a HTTP POST method.

Referring now to FIG. 4B, the computing system 14 communicates with the attestation service using the attestation token received from the mobile device 42. The computing system 14 determines based on information received from the attestation service that the attestation token is valid (step 3026). The computing system 14 decrypts the verification value using the public key (step 3028). The computing system 14 accesses the previously stored verification value and determines that the decrypted verification value is the same as the previously stored verification value (step 3030). In response to the computing system 14 determining that the device can be trusted, the computing system 14 generates a device ID, such as a globally unique ID (step 3032).

The computing system 14 generates a hash of the public key received from the mobile device 42 (step 3034). The computing system 14 stores in a data store, such as a database 66, a record that corresponds to the mobile device 42 that contains the device ID and is indexed by the hash of the public key (step 3036). The computing system 14 creates a JWT and includes in the JWT the public key hash and the device ID (step 3038). The computing system 14 encrypts the JWT using the public key (step 3040). The computing system 14 sends the encrypted JWT to the mobile device 42 (step 3042).

Referring now to FIG. 4C, the secure credential task 60 receives the encrypted JWT and sends the encrypted JWT to the secure enclave 58 in the secure enclave 58 to be decrypted with the private key (step 3044). The secure enclave 58 decrypts the encrypted JWT using the private key and sends the decrypted JWT to the secure credential task 60 (steps 3046, 3048). The secure enclave 58 stores the JWT in the storage device 46 (step 3049). The secure credential task 60 sends a hardware device ID of the mobile device 42 to the secure enclave 58 to be encrypted (step 3050). The hardware device ID may comprise any unique ID that is associated with the mobile device 42 and known to the computing system 14, such as, by way of non-limiting example, the IMEI (International Mobile Equipment Identity) of the mobile device 42, the MDN (mobile directory number) mobile device