SOFTWARE SIGNING ON THE

BLOCKCHAIN
White Paper
WP0156
 Software Signing on the Blockchain

Copyright
Information in this document is subject to change without notice, and is furnished under a license
agreement or nondisclosure agreement.

The information may only be used or copied in accordance with the terms of those agreements.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or
transmitted in any form or any means electronic or mechanical, including photocopying and recording for
any purpose other than the purchaser’s personal use without the written permission of nCrypt Holdings
Ltd.

The names of actual companies and products mentioned in this document may be trademarks of their
respective owners.

nCrypt Holdings Ltd accepts no responsibility or liability for any errors or inaccuracies that may appear in
this documentation.

Page 1 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd

WP0156
 Software Signing on the Blockchain

Problem Statement
Distributed software is frequently deployed over insecure channels such as the Internet, whilst distributed
proprietary software is typically sold with a software licence governing the use or redistribution of the
software. The consumer, in particular, will wish to ensure the integrity of any software that they purchase,
whilst the software vendor will seek to ensure that all distributed software is used in accordance with the
terms and conditions of the licence. It is in both parties’ interests to ensure that software purchasing,
integrity checking, licence management and upgrades are all managed as efficiently as possible.

Key Elements of the Invention

The invention facilitates the use of the Bitcoin network, which is straightforward and inexpensive to use (just
a small transaction fee is usually expected), inherently secure by design (it requires no trusted parties), global
and can be used at any time by anyone with access to the Internet. Furthermore, the Bitcoin blockchain is
both transparent and immutable, once data has been written to the blockchain, anyone can see it, but no
one can change it. Yet privacy is not unduly compromised either, it is possible to broadcast transactions on
the Bitcoin network without giving away any personally identifying information.
The invention offers advantages over the current state of the art in various areas:
 Purchasing — the purchasing of software will be registered and time stamped on a public ledger,
whilst preserving the anonymity of the customer, this facilitates auditing for both the customer and
the vendor.
 Licensing — one of the major innovations of this invention is that the software is encrypted and
comes with a ‘boot’ program that checks the public key derived from the licence before decrypting
itself.
 Integrity checking — the software automatically validates itself by verifying that its body hashes to a
hash stored in its header, and also validates that hash against a hash stored in a distributed hash
table (DHT). This both ensures that the software hasn’t been corrupted in transit and prevents
hacking.
 Authentication — the customer can be sure that they are not purchasing counterfeit software due
to the above integrity checking.
 Non-repudiation — as a record of each transaction, such as the purchase or upgrade of the software,
will be published on a public ledger, neither party will be able to deny the existence of any
transaction.
 Upgrading — the process of upgrading software will also be automated and transparent.
 Auditing — creating an immutable record of transactions between software vendors and consumers
provides obvious benefits for audit.

Page 2 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd

WP0156
 Software Signing on the Blockchain

Background
Software signing is a means of guaranteeing the integrity of software by digitally signing executables to both
confirm the software author and guarantee that the code has not been altered or corrupted since it was
published. This is particularly important in distributed environments such as when software is deployed over
the Internet. Software signing implementations typically involve signing the code using a system involving a
pair of cryptographic keys, one public and one private. To increase trust, the software author can obtain
their public key from a trusted central authority, known as a certification authority, who sign digital
certificates using their own private key and issue them. A digital certificate proves that a public key is owned
by the subject named in the certificate. This overall approach to the distribution and identification of public
encryption keys is known as public key infrastructure.
Distributed proprietary software is typically sold with a software licence governing the use or redistribution
of the software. When a consumer purchases some software, they will be required to agree to an end-user
licence agreement (EULA) before they are able to use it.

Current State of the Art

The current state of the art with regard to software signing is public key infrastructure as described above.
Regarding licencing, some software vendors, notably Microsoft, use a method of product activation that
transmits information about both the product key used to install the program and the user’s computer
hardware back to the vendor, thus ensuring that a single-user licence is not used across multiple hardware.

Benefits
The invention facilitates an inexpensive, simple, secure, anonymous, transparent and global procedure for
the purchase, integrity checking, licensing and upgrading of distributed proprietary software, whilst creating
an immutable record of transactions between software vendors and consumers.
The customers benefit from continuous integrity and transparency. Whilst the software vendors can ensure
that the conditions associated with their licence are adhered to on a continuous and cost-effective basis.
They could also enhance their reputation and increase their trustworthiness by being seen to be transparent.
Furthermore, the immutable record of transactions between software vendors and consumers could be
invaluable for both audit and cases of dispute resolution.

Proposal
Most importantly, if one wishes to create an immutable record of transactions between parties in an
environment where there are no trusted parties, the best known solution is to use the Bitcoin protocol, so
we propose to use the underlying blockchain. Now, without loss of generality, let us assume that we have a
software vendor, Bob, and an end user, Alice. We also introduce a third actor. Knowledge of whether the
terms and conditions of the licence are being adhered to or being breached depends on external events such
as whether the software is being used and the current date, so we need to import states from the external

Page 3 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd

WP0156
 Software Signing on the Blockchain

world, and rely on an oracle, a trusted third party server that has a private and public key pair, and signs
transactions when a user-provided expression evaluates to true. We also employ a distributed hash table
(DHT).
Bob is responsible for populating the DHT with the software licence, a hash of the encrypted executable and
the URL for the software download. Meanwhile the DHT stores Alice’s public key and a hash of Alice’s
hardware string. Whilst an oracle provides the DHT with the current date. Note that Alice, or, rather, the
software installed on her computer, is able to poll the Bitcoin blockchain in order to ascertain whether the
licence is valid. Whilst only the oracle and Alice are able to sign transactions on the blockchain. The oracle
when it is necessary to revoke the licence, and Alice if she wishes to cancel her licence. The overall structure
and relationship between the entities is represented in Figure 1.

Software
vendor
(Bob)

DHT

End user
Oracle
(Alice)

Blockchain

Figure 1: Relationship between entities

Firstly, Bob generates a data string that uniquely identifies the software, version and licence. He then
generates a hash of the downloadable executable of the software. Both pieces of data are uploaded to the
DHT.

Page 4 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd

WP0156
 Software Signing on the Blockchain

Alice uses her web browser to access the DHT which provides her with the download link. She opts to
purchase the desired software. But before she can do so, she is asked to enter her Bitcoin public key. She
then pays for the software in the usual manner, such as via credit card, debit card, PayPal or in bitcoins.
Alice then downloads a pre-installation executable, ideally via Transport Layer Security (TLS), the
cryptographic protocol designed to provide communications security over a computer network.
Different types of software licencing protocols exist, for example multi-licencing, volume licencing, cascade
licencing or licences tied to a single user. In instances when the vendor wishes limit the number of devices
on which the software can be used, the following step may be observed. The pre-installation software
uniquely identifies Alice’s computer hardware by identifying the MAC address, the motherboard serial
number and the processor ID, concatenating the three strings, and then taking a hash of the string. The hash
is used to generate a data string associated with Alice’s hardware, which is relayed over the Internet and
stored in the DHT. Alice’s hardware hash is stored to prevent a single licence from being used on multiple
installations, but in instances when software is licenced, say, on a per user case, such as for mobile phone
applications, this step can be omitted. Whilst some software is licensed per processor core, and again, the
number of cores running on a computer can be determined by the software.
We next borrow from nCrypt’s ‘Smart contract registry’ (WP0151) and ‘Tokenisation (Coloured Coins)’
(WP0165) white papers. In effect, the transaction is a token representing a contract on a DHT and the token
is paid to Alice, conferring the right to use the software under certain terms and conditions.
The software licence, the software’s hash and optionally a hash of Alice’s hardware string are stored as part
of a contract and stored in the DHT. The top level database fields are shown in Table 1, the contract (licence)
details are expanded in Table 2, so that we can prove the contract has not changed, all of these fields form
the contract and must all be included in the ContractHash. In practice, for example, we could use an XBRL to
write the contract so it may be one big field on the DHT. There is the possibility of adding other fields to the
DHT, but these can only be fields that do not affect any part of the contract—for example, we might include
some ‘housekeeping’ fields like ‘archived-flag’, etc. The ContractHash is the look-up key for this record on
the DHT and is the value stored in metadata2. The metadata is shown in Table 3.

Table 1: Top level fields stored in the DHT

ContractHash
Contract details (the licence)
URL for the software

Table 2: Contract details (the licence)

Alice’s public key

Bob’s public key—or Bob’s company identifier or other legally binding identifier
hardware hash
hash of the encrypted software
expiry date
any other contractually binding date

Page 5 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd

WP0156
 Software Signing on the Blockchain

Table 3: Generic contract metadata format

Field Sub-field Bytes Value Comments

Metadata1 ContractType 4 Coded value indicates type of contract.
ContractPointer 16 IPv6 address identifying the DHT.
Format depends on value of ContractType. Padded
ContractTypeData1 12 with zeros.
RIPEMD-160(SHA256(actual contract file addressed
Metadata2 ContractHash 20 by ContractPointer))
Format depends on value of ContractType. Padded
ContractTypeData2 12 with zeros.

We next need to create and broadcast two transactions using the Bitcoin protocol. The first is an ‘issuance’
transaction where the token is created (i.e. the metadata is populated and signed by the oracle). The
transaction is for a nominal sum that needs to be paid back to the oracle. This is so that the redeem script is
exposed in the transaction that spends it. Without this step the redeem script is hashed so the metadata is
not visible. With this step the redeem script is exposed in the input script. The ‘issuance’ transaction is
shown in Table 4 and Table 5.

Table 4: ‘Issuance’ transaction where the token is created

T1 Transaction-ID
Version number Version number
1 Number of inputs
<oracle’s previous unspent transaction> Prev Trans Output
IDX-00 Prev Trans Output index
Script length Script length
OP_0 <oracle’s signature> <redeem script> ScriptSig
Sequence number Sequence number
1 Number of outputs
0.01 BTC Output value
Output script length Output script length
OP_HASH160 <hash of redeem script> OP_EQUAL Output script
LockTime LockTime

Page 6 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd

WP0156
 Software Signing on the Blockchain

Table 5: Locking script for ‘issuance’ transaction

OP_1 <oracle’s public key> <Metadata1> <Metadata2> OP_3 Redeem script

OP_CHECKMULTISIG

The second transaction is a 1-of-4 multisignature pay to script hash (P2SH) transaction, from Bob to Alice or
the oracle, as shown in Table 6. The transaction is for a nominal sum.

Table 6: 1-of-4 multisignature P2SH transaction

T2 Transaction-ID
Version number Version number
1 Number of inputs
T1 Prev Trans Output
IDX-00 Prev Trans Output index
Script length Script length
OP_0 <oracle’s signature> <redeem script> ScriptSig
Sequence number Sequence number
1 Number of outputs
0.01 BTC Output value
Output script length Output script length
OP_HASH160 <hash of redeem script> OP_EQUAL Output script
LockTime LockTime

The locking script includes Alice’s public key and the oracle’s public key, either of which may be used for
redemption, and is shown in Table 7.

Table 7: Locking script for 1-of-4 multisignature P2SH transaction

OP_1 <Alice’s public key> <oracle’s public key> <Metadata1> <Metadata2> Redeem script
OP_4 OP_CHECKMULTISIG

If the pre-installation procedure is completed successfully, Alice then downloads the software itself, again,
ideally via TLS. Many computer programs need to be installed before they are ready for execution, so we
consider both installation and execution in turn.

Page 7 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd

WP0156
 Software Signing on the Blockchain

Installation Process
One of the major innovations of this invention is that the software is encrypted and comes with a ‘boot’
program. The downloadable file, which has been digitally signed, consists of a header and a body. The header
contains a hash of the body of the software and ContractHash, whilst the body contains the encrypted
executable. Browsers come preconfigured with a list of trusted digital certificates and their public keys.
The installation process proceeds as follows:
1) checks the public key derived from the licence;
2) verifies its integrity by taking a hash of its non-header content (the encrypted executable);
3) compares this hash with the software’s hash stored in the header;
4) compares this hash with that stored in the DHT; and if steps 1–4 are successful
5) decrypts itself and
6) installs.
Note that the self-verification steps performed above also act as an internal anti-tampering method that
prevents hacking, because the program cannot be modified against the manufacturer’s wishes without being
detected. If this fails, another attempt is made to download the software, via a URL stored as a field in the
DHT. Otherwise, the installation package ensures that the minimum system requirements are met, and, if
necessary, checks for the existence of existing versions of the software. If all is well, the software is activated.
When a new version of the software is released, Bob’s server updates the DHT accordingly. Each time the
software is executed, it polls the DHT to check whether a new version of the software is available. When a
new version of the software becomes available, this may be available for free download under the terms and
conditions of the existing licence. Alternatively, it may be an upgrade that the customer must pay for. In the
latter case, Alice would have the option of paying for an upgrade, or continuing to use the previous version
of the software.
The original contract can stay intact and only additional subcontracts handle version upgrades.
The original software installation could request an activation key, such that subsequently the software can
only be run after an activation key has been entered correctly. Again, nCrypt’s ‘Secret value distribution’
white paper (WP0042) could be used to generate a deterministic activation key.

Execution Process
The idea is that as long as the above transaction remains unspent (in Bitcoin terminology, an Unspent
Transaction Output (UTXO)), the software licence remains valid, and the program may be executed. The
oracle would always be in a position to revoke the licence by spending the transaction, as in Table 8. Whilst
Alice is also in a position to cancel the licence by spending the transaction. Either at regular time intervals,
or each time it is run, the software automatically polls the blockchain to check that the transaction is unspent,
i.e. the licence is valid. The header contains ContractHash, which is used to scan the UTXO list to find a match
in metadata2. If found, the oracle can retrieve the ContractPointer from metadata1 to locate the DHT, and
picks out the relevant record using the ContractHash as the look-up key.

Page 8 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd

WP0156
 Software Signing on the Blockchain

Table 8: The oracle revokes the licence

T3 Transaction-ID
Version number Version number
1 Number of inputs
T2 Prev Trans Output
IDX-00 Prev Trans Output index
Script length Script length
<Sig-Oracle> <T2 redeemScript> ScriptSig
Sequence number Sequence number
1 Number of outputs
0.01 BTC Output value
Output script length Output script length
OP_DUP OP_HASH160 <PubK-oracle hash> OP_EQUALVERIFY OP_CHECKSIG Output script
LockTime

If the transaction is unspent, the software can be run. If not, Alice is connected to Bob’s server via the DHT,
and given the opportunity to pay to renew the licence. If she declines, the software remains unlicenced, and,
automatically, may revert to adware, demoware, crippleware, trialware, donationware, nagware, freemium
or become inoperable. If she accepts, she would be instructed to pay the requested fee. Again, this may be
done by any normal means. Meanwhile, again, Bob has updated the DHT with the new version of the
software. And so on.
The use of the blockchain or the DHT, of course, assumes that the consumer has access to the Internet. The
software vendor, at their discretion, may offer a period of grace, so that the user has a certain number of
days use of the software, perhaps with nag screens requesting Internet access, before, say, functionality is
compromised. The software could also access the date locally, to check for an expiry date, etc.
If the licence is due to expire on a given date, the contract transaction is formulated such that it is spendable
by the oracle’s signature, and another transaction is formulated with a locktime set to the expiry date,
automatically paying the output from transaction T2 back to the oracle.
Or the license may require payments on a regular basis (e.g. monthly or annually) or be designed to run only
at certain times. In each case, the software must be able to poll the DHT in addition to the Bitcoin network,
and act accordingly, e.g. request a payment. It is also possible to have the software’s ability to run conditional
on other external conditions, in which case the software can poll an oracle. If a regional lockout (geographical
activation restriction) is required, Alice’s IP address can be hashed and used to create another field in the
DHT.
There is also the option of usage tracking, where an oracle signs a message every time the software is used.
A usage log can be derived by storing every instance of the software checking itself against the master.

Page 9 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd

WP0156
 Software Signing on the Blockchain

Version Control
nCrypt’s ‘Secret value distribution’ white paper (WP0042) describes a method to utilise a private key for the
generation of deterministic sub-keys. A master private key can be ‘salted’ with the software version number
to obtain sub private keys. So if software is upgraded to a new version the contract remains the same and
the version number may be used to derive a new public key.

Page 10 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd

WP0156