There is an ever-increasing demand for security in the current digital age. Security comes in different forms. For example, companies, such as software licensors, policy makers, or other authoritative entities, regard the protection of agent storage spaces (e.g., a “trusted storage”) and agent applications on foreign devices (e.g., consumer devices) not in their possession as an important priority. These companies may be referred to as external “influencers” of devices. These influencers may install policy-enforcing agents on the devices to ensure that certain policies or rules (e.g., access granting policies, usage restriction policies, or monitoring policies) are enforced on the devices without tampering. The policies may include policies regarding using the devices locally, using the devices to communicate with or access external resources, and remotely accessing the devices. In some cases, an influencer neither possesses nor owns the device it wants to influence. In other cases, the influencer owns the device, but does not possess the device.
An influencer remotely asserts influence over devices not in its possession through agent applications installed on the devices and by referring to the devices using some programmatically accessible identifier that uniquely identifies the device. That is, enforcement of the policies on a device depends on an identifier of the device. Therefore, if the possessor of the device wants to gain access previously denied according to the influencer's policies, remove existing access restrictions, or prevent activities from being monitored, then the possessor may attempt to change or replicate the device ID to circumvent the policies. For example, the possessor can change the device ID to impersonate other devices with different policies that matches the possessor's goals. Methodologies to change the device ID vary, and thus it has been a challenge to find a solution that is both accurate (e.g., not prone to false positive or false negatives) and resistant to exploits.
Traditionally, a device ID for a computing device is derived from one or more device component IDs that are stored in read-only memories (ROMs) of the device components. However, writing digital identification strings in the ROMs necessitates an inefficient manufacturing process. Other conventional techniques include storing a digital identification in a non-volatile memory of a device component instead of the ROM, thus enabling the manufacturer to serialize the device components in batches at the end of production. However, most non-volatile memories have relatively little safeguards against the possessor of the device component.
USPTO Backgrounds
USPTO Backgrounds