Integration of a Secure Physical Element as a Trusted Oracle in a

Hyperledger Blockchain

Andreas Schaad

, Tobias Reski

and Oliver Winzenried

Faculty of Media, University of Applied Sciences Offenburg, Badstraße 24, 77652 Offenburg, Germany

Wibu-Systems AG, Rueppurer Strasse 52, 76137 Karlsruhe, Germany

Keywords: Software Protection, Blockchain, Hyperledger.

Abstract: Blockchain frameworks enable the immutable storage of data. A still open practical question is the so called

“oracle” problem, i.e. the way how real world data is actually transferred into and out of a blockchain 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 CmDongle / the “dongle”) to function as such a

hardware-based oracle 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.

1 INTRODUCTION

Blockchain frameworks enable the immutable storage

of data (Yaga et al., 2018, Androulaki et al., 2018). A

still open practical question is the so called “oracle”

problem, i.e. the way how real world data is actually

transferred into and out of a blockchain (Buck, 2017)

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 CmDongle / the “dongle”) to

function as such a hardware-based oracle (Apla, 2019)

for the Hyperledger blockchain framework.

Hyperledger is an open-source framework of

blockchain technologies (Androulaki et al., 2018). It is

a so-called permissioned network, where participants

are known and have been provided with an identity

when joining the network. This allows to support more

efficient proof of work concepts than in traditional

blockchain frameworks such as Bitcoin

(Antonopoulus, 2017).

The Wibu 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 is integrated into an

embedded system (Wibu, 2019). Recently a cloud-

based software protection solution has been presented

(Schaad et al., 2018).

Using the capabilities of the dongle, software can

be cryptographically protected at run-time 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 differently used.

The dongle consists of hardened cryptographic

hardware as well as allows to persist data. One standard

use case for such data are so called unit counters that

allow to measure how often a certain action has been

performed or which threshold a data value may have

reached.

We present a case study that demonstrates how to

use this industrial strength secure element for

cryptographic software protection (Wibu CmDongle /

the “dongle”) to function as a hardware-based oracle

(Apla, 2019) for the Hyperledger blockchain

framework.

Because the invocation of any Hyperledger APIs

is part of the protected software, we can achieve a

498

Schaad, A., Reski, T. and Winzenried, O.

Integration of a Secure Physical Element as a Tr usted Oracle in a Hyperledger Blockchain.

DOI: 10.5220/0007957104980503

In Proceedings of the 16th International Joint Conference on e-Business and Telecommunications (ICETE 2019), pages 498-503

ISBN: 978-989-758-378-0

Figure 1: Blockchain-based value chain (with Dongle).

seamless and tamperproof recording of real-world

activities.

2 SCENARIO

2.1 Business Case

The real-world scenario we support is that of a leased

industrial 3D printer limited to print only a certain

amount of items (for example for printing dental inlays

directly at a dentist’s workplace). With every print

action the unit counter of the attached dongle is

decremented. As soon as a 0 threshold is reached the

printer will not print anymore until the lessee (e.g.

dentist) acquires more print units from the machines

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 reasons why a blockchain may make sense

in this context are based on the decision criteria

recommended by NIST (Yaga et al., 2018):

- 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

More specifically, we were interested in the ability

to execute and synchronize business logic between the

participants.

We thus considered using a blockchain framework

for:

- Storing unit counter data

- Defining domain logic (smart contracts) that

automates transactions between participants in a

Figure 2: 3 Intel NUCs with one attached Dongle.

value chain

As a suitable blockchain framework we identified

Hyperledger (Androulaki et al., 2018) which supports:

- An operational model not based on a crypto

currency

- A private consortium

- Lightweight consensus models

- Coordination of participant activity through

smart contracts

2.2 Technical Setup

Our setup consists of several standard Intel NUCs

(Intel NUC, 2018) 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.

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.

In a protected application an activity that leads to a

unit decrement is invoked via the CmAccess()

function in the application code. CodeMeter is a locally

running background process that controls

cryptographic access to cryptographically protected

code. Any such access will request a CmCrypt()

operation in the Dongle’s firmware which will

decrease the unit counter on the dongle by one (Figure

9).

Right after the CmCrypt() command we address

the Hyperledger network and issue a

DecrementUsage API call (this is done from the

protected code (Figure 9) but could also be done from

inside the secure element). We discuss the

implementation of this API in the following section on

our Hyperledger implementation (Figure 5).

This will lead to an immutable decrement of the

Integration of a Secure Physical Element as a Trusted Oracle in a Hyperledger Blockchain

499

Figure 3: Architecture.

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.

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.

3 DESIGN AND

IMPLEMENTATION

3.1 Data Model

Our data model is rather simplistic as defined in figure

4, but suffices to model our value chain (Figure 1). 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 Ressourcer.

Customer in this context is our dentist, lender is the

Figure 4: Hyperledger Data Model.

owner of the machine and Ressourcer is the material

supplier.

Figure 5: Hyperledger Chaincode.

The actual implementation of, for example, the

DecrementUsage operation is done by chaincode

in Hyperledger (Figure 5). 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.

We defined explicit permissions in an access

control list using these entities (Figure 6).

SECRYPT 2019 - 16th International Conference on Security and Cryptography

500

Figure 6: Hyperledger ACLs.

4 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 8). The

same value initial value is maintained in the

Blockchain when querying the Printer asset interface.

We now invoke the DecrementUsage API call

(Figure 5) from our simulated printer software. More

precisely, through the integration of Wibu CodeMeter

daemon any print action will enforce such a decrement

at the local unit counter as well as in the Blockchain.

Enforcement implies real-time cryptographic

enforcement locally as well as in the Blockchain.

The effect of such a decrement operation can again

be observed locally or in the Blockchain (Figure 8).

Once the unit counter hits a zero value, we invoke

a refill operation (Figure 7) via a Python script that

calls the corresponding chaincode.

Figure 7: Hyperledger API call (in Python).

This will now lead to creation of a Debt transaction

which reflects that between the three participants a

certain monetary value has been created. At the same

time the local unit counter was increased by the

requested amount (Figure 5).

The overall code is available on Github:

https://github.com/AdSHSO/CmDongleHyperledger

5 SUMMARY

We have provided an integration of a Hyperledger

blockchain with the Wibu CmDongle as an external

hardware-based oracle. The dongle enforces

cryptographic access control down to the individual

method- or function level of an application through a

local daemon.

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 CmDongle 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).

Because the invocation of any Hyperledger APIs is

part of the protected printer software, we can achieve a

seamless and tamperproof recording of real-world

activities.

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.

As a side-effect, our dongle can record any real-

world activities even in a temporary offline scenario

and later persist them to the blockchain.

Of course, this is only a basic proof of concept with

the intent to demonstrate how a local secure element

(the Wibu 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

existing 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).

We are not concerned with any throughput or

performance issues as the figures reported in

(Androulaki et al., 2019) appear to make Hyperledger

suitable for real-time applications opposed to the

consensus model in Bitcoin (Antonopoulus, 2017).

Integration of a Secure Physical Element as a Trusted Oracle in a Hyperledger Blockchain

501

Figure 8: Local (“dongle”) unit counter and blockchain unit counter.

Finally, as indicated in Figure 3, we currently

investigate how to use Intel’s SGX (Software Guard

Extensions) in a next step to further increase the trust

regarding the communication of the local dongle with

the Hyperledger blockchain. That means that any

Hyperledger API call from the local dongle should be

invoked from within an enclave.

Figure 9: Example protected Java code.

6 CONCLUSION

We provided a practical answer to the „Oracle“

problem by using an existing industrial strength secure

element as a hardware-based oracle. The main

advantage of our work is that any API invocation of the

Hyperledger blockchain is part of the

cryptographically protected code. This implies that the

vendor of the software can “hardwire” desired

interactions with the blockchain and any man-at-the-

end attacks (i.e. by the paying customer) are not

possible (Figure 9). The vendor can protect

functionality at build time of his software as fine-

grained as at the individual method / function level and

thus place any corresponding blockchain API calls

where required. As each later customer has a unique ID

this can then lead to individual API calls.

ACKNOWLEDGEMENTS

This work has been funded by a research cooperation

agreement between University of Offenburg and

Wibu-Systems AG. Alvaro Forrero, Thomas Falk and

Alexander Eger did help with implementing the proof

of concept.

REFERENCES

Androulaki et al., 2018: Hyperledger Fabric: A distributed

operating system for permissioned blockchains. ACM

Eurosys, 2018

Antonopoulus, A., 2017: Mastering Bitcoin: Unlocking

Digital Cryptocurrencies. OReilly, 2017

Apla, 2019 What is a blockchain oracle? Available at:

https://blog.apla.io/what-is-a-blockchain-oracle-

2ccca433c026

Buck, J. 2017: Blockchain Oracles, Explained.

Cointelegraph, Available at: https://cointelegraph

.com/explained/blockchain-oracles-explained

Intel NUC, 2018 Available at: https://www.intel.de/

content/www/de/de/products/boards-kits/nuc.html

SECRYPT 2019 - 16th International Conference on Security and Cryptography

502

Schaad et al., 2018 Towards a Cloud-based System for

Software Protection and Licensing. ICETE (2) 2018:

698-702

Wibu, 2019: Wibu Systems AG Available at www.wibu.com

Yaga et al., 2018 NISTIR 8202. Blockchain Technology

Overview. Available at: https://csrc.nist.gov/

publications/detail/nistir/8202/final

Integration of a Secure Physical Element as a Trusted Oracle in a Hyperledger Blockchain

503