Only a decade ago, programming devices like these usually meant working on a very low-level Assembler language, just one mental step removed from the actual hardware and its functions, often fixed and set in stone in ASICs. Technology has evolved by leaps and bounds and made embedded devices more powerful, cheaper, and above all, more versatile. Instead of custom hardware, modern devices tend to use standard components, programmed with Java or C without the need for highly specialized Assembler coding experts. This has opened the floodgates for more innovation, but it has also raised the bar when protection, security, and monetization concepts are concerned.
Any entrepreneur who has invested their time and resources into innovations like these want to know that their IP is protected. Their first concerns are piracy and reverse engineering: Users might buy fakes or forged products by intent or by mistake, eroding considerable business from the original makers and potentially harming their reputation when users inevitably run into trouble with their knock-off products. On top of the threats for the makers themselves, users are at risk as well: Their data, be it sensitive sensor data or valuable production data, needs to be safe from theft, espionage, manipulation, or – currently a hot topic – hijacking.
When it comes to monetizing the resources and IP they have invested into their products, manufacturers generally used to have only one route: Selling the physical devices. In the modern world, business models and monetization options have multiplied: Money can be made by selling additional features and functions ("features-on-demand"). This could be the ability to configure additional axes in an industrial robot: The hardware and software could have the built-in 6-axis controls, but the user would have the opportunity to buy an add-on license to activate additional axes beyond the basic functions if they want to. This makes for leaner logistics, as the manufacturer only needs to sell one type of physical device, and for greater freedom for users to choose which features they actually need.
Another option are time-based licenses, like subscriptions. Users could enter into a leasing contract that allows them to use a device for a defined time with guaranteed updates in that period. The manufacturer benefits from the certainty of regular payments, and the user from lower upfront costs, upgrades to new functions, and permanent state-of-the-art security.
A third monetization option seems synonymous with our times: Apps. OEM or third-party developers can offer additional features in the form of apps that can be bought, licensed, and loaded onto devices. Opening up their ecosystem to third parties in this way can make a manufacturer’s products much more appealing for users and generate additional revenue in the form of licensing fees.
24. CodeMeter Core API – Overview
Software Protection
Usage of API to implement cryptographic license and tamper checks
Access, Crypt, Release, GetError
License Management
Showing licenses
License updates
Features for the user of the device, provided by vendor
Signatures, symmetric encryption, asymmetric encryption
2019-07-10 CodeMeter - Core Features 24
25. CodeMeter Core API – Best Practice Protection and Management
// Access license
CmAccess2(…)
// Use license
CmCrypt2(…)
// Read license properties
CmGetInfo(…)
// Release license
CmRelease(…)
// Error handling
CmGetLastErrorCode(…)
// Create license request
CmLtCreateContext(…)
// Import license update
CmExecuteRemoteUpdate(…)
// Retrieving license details
CmGetInfo(…)
2019-07-10 CodeMeter - Core Features 25