Blockchain frameworks enable the immutable storage of data [1,2]. A still open practical question is the so called “oracle” problem, i.e. the way real world data is actually transferred into and out of a Blockchain [3] while preserving its integrity.
We present a case study that demonstrates how to use an existing industrial strength secure element for cryptographic software protection (Wibu-Systems CmDongle / the “dongle”) to function as such a hardware-based oracle [8] for the Hyperledger Blockchain framework.
Our scenario is that of a dentist having leased a 3D printer. This printer is initially supplied with an amount of x printing units. With each print action the local unit counter on the attached dongle is decreased and in parallel a unit counter is maintained in the Hyperledger-based Blockchain. Once a threshold is met, the printer will stop working (by means of the cryptographically protected invocation of the local print method). The Blockchain is configured in such a way that chaincode is executed to increase the units again automatically (and essentially trigger any payment processes). Once this has happened, the new unit counter value will be passed from the Blockchain to the local dongle and thus allow for further execution of print jobs.
Introduction
Hyperledger is an open-source framework of Blockchain technologies [2]. It is a so called permissioned network, where participants are known and have been provided with an identity when joining the network. This allows support for more efficient proof of work concepts [2] than in traditional Blockchain frameworks such as Bitcoin [4].
The Wibu-Systems CmDongle is a secure element (a “dongle”) to enable cryptographic software protection and licensing of functionality. It can be attached to a device as a USB token or integrated into an embedded system [5]. Recently, a cloud-based solution has been presented [6].
Software can be cryptographically protected as fine-grained as controlling access to individual methods. A certificate chain rooted at the software vendor controls which customer should have access to which type of functionality (i.e. real-time decryption of code). This setup also supports commercial licensing where the same software is shipped but will be used differently.
The dongle consists of cryptographic hardware for secure key storage. One standard use case for such data are so called unit counters that allow measurement of how often a certain action has been performed or which threshold a data value may have reached.
Scenario
A real-world scenario we support is that of a leased industrial 3D printer limited to print only a certain amount of items (e.g. for printing dental inlays directly at a dentist’s workplace). With every print action the unit counter of the attached dongle is decreased by one unit. As soon as a 0 threshold is reached, the printer will be disabled until the lessee (e.g. dentist) acquires more print units from the machine’s actual owner via an online portal to obtain an activation code that will reset the unit counter. In parallel, the dentist has to order printing material from another vendor.
The reason why a Blockchain may make sense in this context is in part based on the decision criteria recommended by NIST [1]:
- We need shared consistent data storage between participants
- More than one entity needs to contribute data (dentist, machine owner, material supplier)
- We only need Create and Read but no Update or Delete actions
- No PII data is required to be stored
- Our participants have a common economic interest but limited trust
- Any data storage needs to be immutable
We thus considered using a Blockchain framework for:
- Storing unit counter data
- Defining domain logic (smart contracts) that automates transactions between participants in a value chain
As a suitable Blockchain framework we identified Hyperledger [2] which supports:
- An operational model not based on a crypto currency
- A private consortium
- Lightweight consensus models
- Coordination of participant activity through smart contracts
Figure 1: Blockchain-based value chain
Overall technical setup
Hardware
Our setup consists of several standard Intel NUCs [7] to simulate the entities participating in our scenario. One of the NUCs has an attached dongle and represents the 3D printer. The reason why we chose the largest available form factor of a dongle is because of an integrated LED that allows us to visualize the current unit counter status.
Figure 2: Intel NUCs with one attached Dongle (Wibu-Systems CmDongle) and activated LED (“orange”)
High-level logical Interaction
The interaction between the protected software (e.g. the simulated 3D printer), the secure element and the Hyperledger Blockchain is realized over several interfaces and follows the sequence in figure 3.
Figure 3: Overall Interaction
In a protected application an activity that leads to a unit decrement is invoked via the CmAccess() function. CodeMeter is a locally running background process that controls cryptographic access to protected code. Any such access will request a CmCrypt() operation which will decrease the unit counter on the dongle by one (Figure 4).
Figure 4: Example Java Code Snippets for local (“dongle”) unit counter decrement
Right after the CmCrypt() command we address the Hyperledger network and issue a DecrementUsage API call (by calling a Python script from the Java code in figure 5). We discuss the implementation of this API in the following section on our Hyperledger implementation (Figure 8). This will lead to an immutable decrement of the current unit counter value we defined in the Blockchain (also defined in the following section). More precisely, a series of transactions allows to determine the current (world) state at any time.
Figure 5: Python API call of custom Hyperledger “DecrementUsage” function
Regarding the LED within the dongle, we use green to indicate that sufficient units are available, orange for a currently ongoing decrement operation and red to indicate that no more units are available.
Implementation of a Hyperledger-based value chain
Data Model
Our data model is rather simplistic as defined in figure 6. We distinguish between:
- asset
- participant
- transaction
Assets are modified via transactions and represent our device that works on basis of a unit counter. A participant takes part in the overall value chain. Here “o” refers to an attribute, while “-->” refers to an object.
The usage attribute of the printer defines the current available units and reflects the unit counter of the CmDongle. The Debt asset is used to reflect that any “refill” of print units will create a relationship between Customer, Lender and Resourcer. Customer in this context is our dentist, lender is the owner of the machine and Resourcer is the material supplier.
The actual implementation of the DecrementUsage operation, for example, is done via the chaincode (Figure 8).
Figure 6: Hyperledger domain model
Access Control
We defined explicit permissions in an access control list using these entities (Figure 7).
Figure 7: Example rule “Only customer can invoke a DecrementUsage operation on a printer”
Domain Logic / Chaincode
Within our Hyperledger setup we used standard javascript to implement the domain logic. This is called chaincode and defines the actions that are executed when an external command from our printer application is received.
Figure 8: Domain Logic / Chaincode that is invoked with transactions
Demonstration
In a first step we imagine that the printer is currently equipped with 5 print units. The local CmDongle reflects this in an immutable fashion (Figure 9).
Figure 9: Local unit counter CmDongle
The same value is maintained in the Blockchain (Figure 10) when querying the Printer asset interface.
Figure 10: Unit counter maintained in Blockchain (“usage” attribute of “Printer” asset)
We now invoke the DecrementUsage API call (Figure 5) from our simulated printer. More precisely, through the integration of Wibu-Systems CodeMeter any print action will enforce such a decrement at the local unit counter as well as in the Blockchain (Figure 11).
Figure 11: Invoke local decrement as well as Blockchain chaincode
Such a decrement (here to 2 print units) can again be observed locally or in the Blockchain (Figure 12)
Figure 12: Both unit counters
Once the unit counter hits a zero value, we invoke a refill operation (Figure 13) via a Python script that calls the corresponding chaincode.
Figure 13: Refill operation
This will now lead to creation of a Debt transaction which reflects that between the three participants a certain monetary value has been created (Figure 14). At the same time the local unit counter was increased by the requested amount.
Figure 14: Final effect of refill operation
Summary and Conclusion
We have provided an integration of a Hyperledger Blockchain with the Wibu-Systems CmDongle as an oracle. Our scenario was that of a dentist having leased a 3D printer. This printer is initially supplied with an amount of x printing units. With each print action the local unit counter on the Wibu-Systems CmDongle is decreased and in parallel a unit counter is maintained in the Hyperledger-based Blockchain. Once a threshold is met, the printer will be disabled (by means of the cryptographically protected invocation of the local print method). The Blockchain is configured in such a way that chaincode is executed to increase the units again automatically (and essentially trigger any payment processes). Once this has happened, the new unit counter value will be passed from the Blockchain to the local dongle and thus allow for further execution of print jobs.
Of course, this is only a basic demo with the intent to demonstrate how a local secure element (the Wibu-Systems CmDongle) could assist as a trusted hardware oracle for a Blockchain. We have not yet registered the secure element as a trusted Blockchain participant, but this should only be minor technical issue when using Hyperledger as a framework and its identity management functionality. We have also not fully provided an end to end scenario for processing payment information and resetting any unit counters. Again, this is seen as an engineering exercise as such an integration of payment solutions already does exist as part of the current Wibu-Systems technology stack. Likewise, we only implemented one example where chaincode invokes other chaincode (refill operation creates Debt).
Finally, as indicated in Figure 3, we currently investigate how to use Intel’s SGX (Software Guard Extensions) in a next step to increase trust in the communication of the local dongle with the Hyperledger Blockchain.
Authors
Andreas Schaad, University of Applied Sciences Offenburg, Germany
Alvaro Forero, WIBU-SYSTEMS AG, Germany
Thomas Falk, University of Applied Sciences Offenburg, Germany
Alexander Eger, University of Applied Sciences Offenburg, Germany
Literature
[1] NISTIR 8202. Blockchain Technology Overview. Dylan Yaga. Peter Mell. Nik Roby. Karen Scarfone.
[2] Androulaki et al.: Hyperledger Fabric: A distributed operating system for permissioned blockchains (ACM Eurosys 2018)
[3] Buck, J. “Blockchain Oracles, Explained.” Cointelegraph, October 18, 2017, cointelegraph.com/explained/blockchain-oracles-explained
[4] Antonopoulus, A.: Mastering Bitcoin: Unlocking Digital Cryptocurrencies. O'Reilly, 2017
[5] WIBU-SYSTEMS AG: www.wibu.com
[6] Schaad et al. Towards a Cloud-based System for Software Protection and Licensing. ICETE (2) 2018: 698-702
[7] https://www.intel.de/content/www/de/de/products/boards-kits/nuc.html
