A Blockchain Root of Trust for Digital Works

Enforcing digital rights to activate only the specific user’s device was an entirely separate security challenge, yet it was essential to automating Software Asset Management (SAM). It’s a common desire that each Activate token only authorizes a single product on a single device at a time (laptop, tablet, phone, etc.). There are other means of locking an activation besides a device identifier — these will not be discussed but can integrate in the same way. With each device having immutable hardware identifiers it was possible to use one or more of these as the activation identifier. While different for every device operating system, here’s an example of using the Linux dbus/machine-id as the unique hardware identifier. For Windows, the process is similar except we use the SMB/BIOS interface to access the read-only MachineGuid in the Registry.

/*****************************************************************/
/* AutoLmMachineId: Find and return the Unix Dbus machine-id */
/* */
/* Inputs: comp_id = OUT the dbus machine-id from Unix */
/* */
/* Returns: OUT comp_id length if success, otherwise error */
/* */
/*****************************************************************/
// Get the MachineId in string, hexadecimal format
// OUT: comp_id array size must be 35 bytes or larger
int AutoLmMachineId(char *comp_id)
{
char tmp[64];
FILE *pFILE; tmp[0] = 0;
pFILE = fopen("/var/lib/dbus/machine-id", "r");
if(pFILE) {
fgets(tmp, 32, pFILE);
tmp[32] = 0;
}
sprintf(comp_id, "0x%s", tmp);
return strlen(comp_id); // Return string length
}

Using the hardware ID directly led to obvious conflicts between different products on the same device and raised privacy concerns. Scalable device association required product-specific information to be added to the identifier to ensure uniqueness across products. Also, for privacy purposes, it was important to anonymize the information before storing it on the public blockchain. Additionally, it’s paramount to have a unique one-to-one lookup for the efficient operation of activation lookup checks.

These requirements meant a one-way hash was needed that could also guarantee a unique result (ie. SHA 256). Including the product information with the unique device identifier as part of the input to the SHA 256 calculation ensures uniqueness of the resulting activate ID’s across different products on the same device. And, by design, the 1-way hash is just that — one way. There’s no leakage of information regarding the original hardware identifier.

Using a unique and immutable hardware identifier as the base of data input to a one-way hash function whose result is also unique is the core security of this system. The check to verify a product has been activated performs the one-way hash calculation on the unique hardware ID and product information known by the application (see AutoLM for more details). If an Activate NFT is found associated with an identical activation identifier, and the associated Activate token is valid (correct product, not expired, etc.), then the verify check is considered successful and the digital product is considered activated on this device (application features enabled, video plays, art displayed, etc.).

To step briefly into the code, the Solidity function and comments below describe the interface to check the status of a product activation. The organization (entity) and product identifiers are known to the application and can be statically compiled, while licenseHash is the unique result of the hardware identifier plus the product specifics going through the one-way hash algorithm.

 /// @notice Return user activation value and expiration for product
/// Entity and product must be valid.
/// @param entityIndex The entity the product license is for
/// @param productIndex The specific ID of the product
/// @param licenseHash the external unique identifier to activate
/// @return the activation value (flags, expiration, value)
/// @return the price in tokens it is offered for resale
function activateStatus(uint256 entityIndex, uint256 productIndex,
uint256 licenseHash)
external view returns (uint256, uint256)
{
require(entityIndex > 0, EntityIsZero);
uint256 tokenId = ActivateIdToTokenId[licenseHash]; if (tokenId > 0)
{
require(entityIndex == (tokenId & EntityIdMask) >>
EntityIdOffset, "EntityId does not match");
require(productIndex == (tokenId & ProductIdMask) >>
ProductIdOffset, "ProductId does not match");
} // Return license flags, value. expiration and price
return (
(tokenId & (FlagsMask | //flags
ExpirationMask | //expiration
ValueMask)), //value
TokenIdToOfferPrice[tokenId] //price
);
}

Let’s try to identify weak spots in the security. One obvious attack vector would be to try and create fake credentials or Activate tokens. However, even with fake product names it would be rejected. The smart contracts (see activateStatus() above) will detect if an Activate token with matching activation was minted from a different organization (entityIndex within the NFT token ID will differ). Only the creator’s wallet, directly or through offers, can mint NFTs containing their unique organization identifier (entityIndex). Another leverage of uniqueness and immutability that forms the basis for both the strength and simplicity of this solution.

With the license activation check in the smart contracts ensuring that the correct product and organization identifiers are present, the Ethereum wallet registered by the owner of that product is the only viable means to mint (ie. create) these tokens. Fake credentials/NFTs with an identical ID can however be created on a test Ethereum network since our smart contracts are open source to allow third-party security audits and private blockchain deployments. To prevent an unofficial Immutable Ecosystem from impersonating yours, it is important that the software that ensures the read request to the blockchain (Infura, etc.) uses Ethereum Mainnet and our official Ecosystem contract address. Allowing options when configuring access to the blockchain could leave the path to be used when validating credentials for a blockchain out of your control. This design is required because it allows the Ecosystem to be deployed on private Ethereum networks to avoid ETH gas costs.

Enforcement of the most recent block is also required. Allowing old block times can allow a license from the past to be used (before resale or move to a new device). The time and expertise required to set up and maintain a testnet reduces the risk of this being used for fraud. Mitigate this by ensuring the configuration parameters used for the activation check are static within your application and not configurable by the user (default for AutoLM).

It is also important to defend against a reverse engineering attack that might attempt to remove the activation check entirely. Because of this, it is important to intertwine security within the product. For example, not only keep state (ensure activation was checked) but verify the code executing this check is untampered (a future article on file authentication coming soon). Strict license agreement rules against reverse engineering are recommended in your products as they can provide a powerful legal deterrent against these efforts, especially public disclosure thereof.

While not perfect, this software licensing solution has one advantage that other licensing systems do not. Prior device locked solutions had no public root of trust and thus relied upon a secret algorithm hidden in the code to calculate authenticity — a secret sauce as a root of trust. In the past, if the secret sauce was ever exposed then anyone could create licenses for a product. This was mitigated with server access technologies to some degree, but maintaining and securing uptime for these servers for customers has a cost and often leads back to centralization. The blockchain as a root of trust allows everyone to lose the secret sauce and centralized servers. Secure your digital works pipeline with the blockchain as your root of trust.

Source: https://betterprogramming.pub/a-blockchain-root-of-trust-for-digital-works-4726bbeb3c7e?source=rss——-8—————–cryptocurrency