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, comprising:
receiving a lock request from a run-time device upon execution of a 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 a 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 associated with a plurality of blank LUTs at a build-time device;
transmitting the run-time device specific locked whitebox LUTs from a network service to the run-time device;
receiving a request for a secret from the run-time device, the request including the build identifier; 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 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.
7. 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.