Cloud-based whitebox node locking
A secure cloud-based node-locking service with built-in attack detection to eliminate fuzzing, cloning and other attacks is disclosed. White-box base files are securely stored on the cloud service and are not vulnerable to accidental leakage. A secure cloud-based dynamic secret encoding service reduces the risk of exposure of unprotected secrets and other sensitive data.
1. A method of enabling secure generation of an output in a run-time device, comprising:
receiving a request to register a whitebox implementation for generating the output in a network service from a build-time device, the request to register comprising:
a base file; and
a list of unlocked whitebox look up tables (LUTs);
registering the base file and the list of unlocked whitebox LUTs in the network service;
returning a surrogate whitebox implementation having a build identifier (ID) and a plurality of blank LUTs to the build-time device;
receiving a lock request from the run-time device upon execution of the surrogate whitebox implementation, the lock request comprising a fingerprint of the run-time device determined by the run-time device upon first execution of the surrogate whitebox implementation and the build identifier;
generating a locked whitebox implementation according to the received fingerprint of the run-time device and the build identifier, the locked whitebox implementation having a plurality of run-time device specific locked whitebox LUTs;
transmitting the plurality of run-time device specific locked whitebox LUTs from the network service to the run-time device;
receiving a request for a secret from the run-time device, the request for the secret including the build ID; and
transmitting an encoded secret.
2. The method of claim 1 , wherein:
generating a locked whitebox implementation according to the fingerprint of the run-time device and the build identifier comprises:
encoding the unlocked whitebox LUTs by applying run-time device specific locking transformations to the unlocked whitebox LUTs according to the fingerprint.
3. The method of claim 2 , further comprising:
generating the encoded secret by applying the run-time device specific locking transformations to the secret.
4. The method of claim 3 , wherein the encoded secret is generated in response to the request for the secret.
5. The method of claim 3 , wherein the encoded secret is before the request for the secret.
6. The method of claim 1 , wherein the base file and list of unlocked whitebox LUTs generated by a second device executing a toolchain executing in the network service.
7. The method of claim 1 , wherein:
the request to register the whitebox implementation comprises build-time device credentials;
the method further comprises:
determining if the build-time device credentials are valid; and
if the build-time device credentials are not valid, refusing registration of the whitebox implementation.
8. The method of claim 1 , wherein:
the lock request is automatically transmitted from a first address; and
the method further comprises:
determining if a preceding node locking request having the same build identifier was received from a second address; and
rejecting the lock request if the preceding node locking request the build identifier was received from the second address.
9. The method of claim 1 , wherein:
the lock request is automatically transmitted from a first address and;
the method further comprises:
determining if a preceding node locking request having a different build identifier was received from the first address; and
rejecting the lock request if the preceding node locking request having the different build identifier was received from the first address.
10. An apparatus for enabling secure generation of an output in a run-time device, comprising:
a processor;
a memory, communicatively coupled to the processor, the memory storing processor instructions comprising processor instructions for:
receiving a request to register a whitebox implementation for generating the output in a network service from a build-time device, the request to register comprising:
a base file; and
a list of unlocked whitebox look up tables (LUTs);
registering the base file and the list of unlocked whitebox LUTs in the network service;
returning a surrogate whitebox implementation having a build identifier (ID) and a plurality of blank LUTs to the build-time device;
receiving a lock request from the run-time device upon execution of the surrogate whitebox implementation, the lock request comprising a fingerprint of the run-time device determined by the run-time device upon first execution of the surrogate whitebox implementation and the build identifier;
generating a locked whitebox implementation according to the received fingerprint of the run-time device and the build identifier, the locked whitebox implementation having a plurality of run-time device specific locked whitebox LUTs;
transmitting the plurality of run-time device specific locked whitebox LUTs from the network service to the run-time device;
receiving a request for a secret from the run-time device, the request for the secret including the build ID; and
transmitting an encoded secret.
11. The apparatus of claim 10 , wherein:
the processor instructions for generating a locked whitebox implementation according to the fingerprint of the run-time device and the build identifier comprises processor instructions for:
encoding the unlocked whitebox LUTs by applying run-time device specific locking transformations to the unlocked whitebox LUTs according to the fingerprint.
12. The apparatus of claim 11 , wherein the processor instructions further comprise processor instructions for:
generating the encoded secret by applying the run-time device specific locking transformations to the secret.
13. The apparatus of claim 12 , wherein the encoded secret is generated in response to the request for the secret.
14. The apparatus of claim 12 , wherein the encoded secret is before the request for the secret.
15. The apparatus of claim 10 , wherein the base file and list of unlocked whitebox LUTs generated by a second device executing a toolchain executing in the network service.
16. The apparatus of claim 10 , wherein:
the request to register the whitebox implementation comprises build-time device credentials;
the processor instructions further comprise processor instructions for;
determining if the build-time device credentials are valid; and
if the build-time device credentials are not valid, refusing registration of the whitebox implementation.
17. The apparatus of claim 10 , wherein:
the lock request is automatically transmitted from a first address; and
the processor instructions further comprise processor instructions for:
determining if a preceding node locking request having the same build identifier was received from a second address; and
rejecting the lock request if the preceding node locking request the build identifier was received from the second address.
18. The apparatus of claim 10 , wherein:
the lock request is automatically transmitted from a first address;
the processor instructions further comprise processor instructions for:
determining if a preceding node locking request having a different build identifier was received from the first address; and
rejecting the lock request if the preceding node locking request having the different build identifier was received from the first address.
19. The apparatus of claim 10 wherein said network service is a cloud service.
20. The apparatus of claim 10 wherein said network service is an on-line service.
21. A method of enabling secure generation of an output in a run-time device, comprising:
receiving a request to register a network based device implementation for generating the output in a network service from a build-time device, the request to register comprising:
a base file; and
a list of unlocked network based device data tables (DTs);
registering the base file and the list of unlocked network based device DTs in the network service;
returning a surrogate network based device implementation having a build identifier (ID) and a plurality of blank DTs to the build-time device;
receiving a lock request from the run-time device upon execution of the surrogate network based device implementation, the lock request comprising a fingerprint of the run-time device determined by the run-time device upon first execution of the surrogate network based device implementation and the build identifier;
generating a locked network based device implementation according to the received fingerprint of the run-time device and the build identifier, the locked network based device implementation having a plurality of run-time device specific locked network based device LUTs;
transmitting the plurality of run-time device specific locked network based device LUTs from the network service to the run-time device;
receiving a request for a secret from the run-time device, the request for the secret including the build ID; and
transmitting an encoded secret.