Page 30 - MSDN Magazine, March 2018

Bill’s Private Key
1101010010
Digitally Signed Document Including Encrypted Hash
implementation vary dramatically across blockchain technologies and versions, the basic idea is the same for all of them. For example, as shown in Figure 7, Bill is the owner of a digital asset and uses his private key to initiate a transfer of that digital asset to Susan. Susan’s transaction record uses Bill’s public key to verify his signature. After this, Susan’s public key is used to sign the digital asset, making Susan the new owner. This creates a new transaction record—a new link on the transaction hash chain.
This hash chain of transactions is cryptographically secure and tamper-proof. Any change to Transaction 0 would cause Sig0 to change, and that would require an update to the hash value stored in Transaction 1 and every subsequent transaction on the hash chain.
The transaction objects here are pictured with data. The data contained by each transaction varies for each blockchain imple- mentation, so I’ve abstracted the underlying data for our purposes because the main point to understand is that the hash chain is a cryptographically linked chain of transactions—linked by the hash value of the previous owner’s transaction record. (In crypto- currency blockchains, each transaction object contains a list of digital-currency inputs and outputs, along with metadata, such as a timestamp and optional transaction fee. These cryptocurrency inputs and outputs provide the transaction detail needed to accu- rately model a financial ledger.)
Merkle Trees Some blockchains bundle up transactions using another kind of hash chain: the binary hash chain, or Merkle tree. A complete Merkle tree is referred to as a binary tree structure because it branches twice at each level starting at the root, as shown in Figure 8.
The work in setting up a Merkle tree is to create a series of leaf nodes by computing the SHA-256 hash for the data contained in each transaction object (the Bitcoin blockchain double-hashes each Merkle node; double-hashing can help strengthen the cryptographic value in the hash result should a vulnerability be discovered in the SHA-256 algorithm). The Merkle tree requires an even number of leaf nodes—it’s customary to duplicate the last leaf node if starting with an odd number. Then each pair of leaf nodes is hashed together, producing a new hash value. In Figure 8, Leaf A shows the hash for Transaction A as HA; Leaf B shows the hash for Transaction B as HB and so on. This pattern continues at each tree level until you reach the final root node. The root node’s hash value is the crypto- graphic hash sum of all of the other hash sums in the tree. Any change to the data in any of the leaf nodes causes the recomputed Merkle tree root hash value to change.
Bill’s Word Document
H(W) SHA-256 Hash
1101010010
Enc(H(W))
Encrypted SHA-256 Hash
Bill’s Word Document
Figure 5 Using PKC Along with a Cryptographic Hash to Digitally Sign a Document/Message
The second use case (see Figure 4) is when you want to encrypt a message and demonstrate that it is indeed from you. To do that, you use your private key to create a ciphertext of your document. You then send that ciphertext to someone else. They use your public key to decrypt it. Because only your public key can decrypt that document, the recipient can assume that the document was encrypted by your private key—and unless your private key has been misappropriated, the document came from you.
A third use case employs PKC to prove ownership of a digital asset through a digital-signing process. In this use case (see Figure 5), imagine that Bill has composed a Word document of a legally binding document that he needs to e-mail to Susan. Susan wants to be sure that the copy of the document she receives from Bill is actually from Bill and hasn’t been tampered with en route. Bill first creates a SHA-256 hash of the Word document and records the value as H(W). He next uses his private key to encrypt the document hash, resulting in Enc(H(W)), and then sends the Word document (optionally encrypted) and the Enc(H(W)) value (this is Bill’s digital signature for document W) to Susan.
Susan re-computes the H(W) value from the copy of the Word document she received, then uses Bill’s public key to decrypt the Enc(H(W)) value (see Figure 6). If the hash Susan computed is equal to the decrypted H(W) value, Susan can conclude that Bill signed the document and that the copy she received is exactly the same as the one Bill signed.
Using hashing and PKC, a blockchain maintains a history of dig- ital asset ownership using transactions. Transaction data objects are linked to each other, forming a data structure called a hash chain. The way this works is that each transaction record constitutes the message (m) that’s hashed using function (H) and then signed using the owner’s private key (s). (It’s customary to use “s,” for “secret,” to represent the private
key so as not to confuse it with “p”
for the public key.) This produces
a signature (sig):
Bill’s Public Ke
The document Susan received from Bill
Susan compares the two resulting hash values. If they’re the same, then she can be sure that Bill signed the document and that the document she received is exactly the same as the one Bill signed.
sig = signature(H(m), s) When a digital asset trans- fers from one owner to another, its digital signature is examined, verified, and digitally signed by the new owner, and then regis- tered as a new node on the hash chain. Although the details of the
1101010010
Enc(H(W))
Encrypted SHA-256 Hash
Bill’s Word Document
Susan computes the SHA-256 for Bill’s document
Digitally Signed Document Including Encrypted Hash
1101010010
1101010010
24 msdn magazine
Blockchain
SHA-256
ENCRYPTION
Figure 6 Using PKC Along with a Cryptographic Hash to Verify That a Document/Message was Signed by the Expected Party
y
Susan uses Bill’s public key
to decrypt the hash
Bill sends document and Hash to Susan