CodeMeter Embedded 2.0 - New Features

Catégories: Embedded

CodeMeter Embedded is entering its new generation, bringing with it several important and exciting innovations and giving the library a well-deserved version number – CmE 2.0

The internal architecture of the CodeMeter Embedded Library has been completely reworked and brought up to date. CodeMeter Embedded can now access the shared key storage with multiple processes at the same time. PC users might consider this a standard capability, but this feature had deliberately been left out of earlier embedded versions.

The code was meant to be kept to a minimum size, with no active services, and with the CodeMeter Embedded Library included directly as part of protected programs. For many implementations, such a single instance is still a viable option. However, increasingly powerful embedded systems allow a new feature set, with multiple programs or processes sharing access to a single CmContainer.

This opens up new possibilities for many oft-requested use cases that would have several program parts or CodeMeter-protected programs from different makers running simultaneously: the desktop world has come to the embedded world. The processes are coordinated in the background, but with full transparency for the user, and no service or daemon is required. This means that CodeMeter Embedded 2.0 can still be integrated without much adjustment and upgrades from CodeMeter Embedded 1.x are directly possible. The internal design changes are making the licensing system more flexible and capable. Our name for it is License Core.

Using the New UFC Firm Codes > 6,000,000

The move to the 2.x version also marks the beginning of license transfer capabilities for CodeMeter Embedded. Starting with version 2.0, users can employ existing UFC firm codes on their dongles, keeping the Firm and Product Codes compatible across the entire CodeMeter universe.

Work has already started on version 2.1, which will be able to update UFC licenses remotely. CodeMeter Embedded 2.1 with dongles can then also act as license transfer endpoints. The license transfer function for CmActLicenses will be included in version 2.2 and complete the transition to the new license transfer feature set.

A typical industrial use case would be a machine that is installed at the client and commissioned by a technician. The license required for a CodeMeter-protected sensor or PLC program can be brought along on a CodeMeter USB dongle and injected on site into the machine’s controllers.

The same approach is used for replacement services. Machines of this nature are often connected to the Net, but usually not allowed to access external services like CodeMeter License Central for security reasons. License transfer makes it easier for users to transfer licenses without having to integrate the RaC/RaU handling on a mobile storage device.

CodeMeter ASIC with SPI Interface

The standard dongle functionality in CodeMeter Embedded is being expanded with another interface. On top of USB and SD bus interfaces, SPI is now another option. Designers of circuit boards can get the CodeMeter chip in ASIC format and integrate it directly into their layouts. The CmASIC itself comes with two integrated interfaces: USB and SPI.

The USB specifications include the hardware interface and a protocol stack to enable connecting with the basic functions of most operating systems. Like the USB dongle, the ASIC functions either as a mass storage device (MSD Mode) or a keyboard (HID Mode).

The latter ability is a viable choice for more restrictively hardened environments that disallow flash memory access to prevent accidental malware infections. The new SPI interface represents a low-level hardware interface, which bypasses the USB stack to save power and connect directly with the chip. SPI enables the ASIC to be used with custom implementations, not the least in very lean systems without USB stacks or bare-metal implementations without actual operating systems. The required communication protocol comes integrated in CodeMeter Embedded 2.0 and needs no more adjustments on the part of the client. The SPI function in CodeMeter Embedded Library uses the SPI kernel driver to communicate with CodeMeter ASIC.

What Else Is New?

The version numbering for CodeMeter Embedded now follows the standard conventions for our other products, like CodeMeter License Central or AxProtector. The build number ceases to be part of the version. Instead, we will distinguish between major and minor releases with an alphanumerical count. This makes the new version of CodeMeter Embedded 2.0b.

CodeMeter Embedded 2.0 also includes more powerful processors like ARMv8 with 64-bit operating systems such as Linux and Windows.

CodeMeter Embedded will not be offered only as an off-the-shelf product. Many features are now modular. in order to keep the software as compact as possible. Only what is needed will be delivered. Depending on the configuration and platform, the library will change in size in a range of a few hundred kilobytes. This flexibility means that the target system and use case will now be considered and custom packages prepared for each new client. CodeMeter Embedded can now be scaled to match the client’s specific needs. We are testing possible combinations for different versions of common operating systems on different platforms (cf. the attached table). This covers most use cases in the real world. For more specialized needs, the client can compile the source code with the required tool chain himself and adapt it for real-time operating systems or other custom implementations.

Tested Combinations:

Linux x86 and x86_64
Linux ARMv6hf (RaspberryPi 2)
Linux ARMv6 (RaspberryPi 2, Pandaboard)
Linux ARMv7hf (NanoPi, RaspberryPi 3, Cubietruck, BeagleBoneBlack)
Linux AARCH ARMv8hf (ODROID-C2)
QNX ARM (Pandaboard)
QNX x86 (Intel Desktop Board D525MW)
VxWorks 6.9 PPC (P2020), x86 (NITX315), ARMv7 (SabreLite IMX6Q)
VxWorks 7 PPC (P2020), x86 (NITX315), ARMv7 (SabreLite IMX6Q), 64 (DELL Optiplex)
Windows x86 and x86_64
Android 5.1 (Raspi3)