Using Software Guard Extensions to Improve Security on Blockchain
Security of sensitive data is a top priority and a major concern of software development today. In this article, Dmitry Lavrenov of Altoros explains how to prevent disclosure of sensitive data in case your machine is compromised and blockchain applications are executed in a trusted environment.
As an example, he explores using Intel Software Guard Extensions (SGX) as part of blockchain solutions built for supply chain and e-voting.
Three types of data to protect
On a daily basis, we deal with three basic states of digital information: data at rest, data in motion, and data in use.
Data at rest refers to the data stored on a device or backup of any form. It’s inactive data that is not currently being transmitted across a network or actively being read or processed. Data at rest is typically in a stable state. A broadly used mechanism for protecting data at rest is encryption.
Data in motion is data that is currently traveling across a network from a local to a cloud storage or from a central mainframe to a remote terminal. To secure this type of data, the HTTP protocol was developed to transfer data from one host to another. Usually, it represents a communication channel between browsers and servers. However, the main problem of the HTTP protocol from a privacy perspective is that it transmits data as a plain text. This means that any intermediate node that the packets pass through can intercept, read, or modify the packets. This is called a man-in-the-middle attack, and it allows an attacker to impersonate websites and sniff on traffic.
Furthermore, there is no control over how data is used by a server. This means that as soon as data leaves the end user’s device, it’s completely visible and modifiable all the way through.
In order to fix this problem, the HTTPS protocol was delivered as a safer alternative. HTTPS establishes an encrypted communication between hosts using the SSL or TLS protocols. SSL is a security technology for establishing communication between two systems. Basically, SSL ensures that data transfer between two hosts remains encrypted and private. TLS is a new version of SSL.
The issue is that the encrypted traffic must be decrypted by a server, and the decrypted data is exposed to all the programs running on a server machine. This is completely beyond the control of the client.
The third basic type of digital information is data in use. It’s data that is being processed by a single or multiple applications. Assume that you are using a laptop for maintaining sensitive data. In case a laptop is compromised, the operating system may catch a malicious process, which can get a higher privilege levels using a vulnerability of the operating system.
Then, the malicious process can, for example, compromise anti-malware software and create a backdoor channel to an adversary. As a result, an operating system and all applications are available to the adversary. It means that the adversary can easily inspect, control, and transfer sensitive data.
What can be done?
A set of security technologies and platforms appeared to address the issues like those described above. Here, we’ll talk about Software Guard Extensions (SGX), a set of security-related instruction code that is built into some of today’s CPUs from Intel. At both a user and an operating system levels, it enables engineers to define private regions of memory called enclaves. The contents of enclaves are protected and can’t be read or saved by any process outside the enclave itself, including processes running at higher privilege levels.
In other words, Intel SGX is a trusted execution environment for applications that isolates a portion of physical memory (an enclave) to protect code and data from unauthorized access or modifications. SGX involves encryption by the CPU of a portion memory. The enclave is decrypted on the fly only within the CPU itself.
Usually, applications must trust an operating system, virtual machines, a BIOS, and a system management mode. Trust relies on software. It means that if your application processes sensitive data, and your software is compromised, then data can be easily accessed by the adversary.
In SGX case, applications must trust only SGX hardware. Trust excludes an operating system, virtual machines, a BIOS, and a system management mode. The code and data in the enclave utilize a threat model in which the enclave is trusted, but no process outside it can be trusted, and these are all treated as potentially hostile.
SGX also provides remote attestation, using which an enclave can attest to a remote trusted entity and establish an authenticated communication channel with it. As part of attestation, an enclave proves its identity that has not been tampered with, and that the identity is running on a genuine platform with Intel SGX enabled.
This way, one can use the following options for sensitive data to prevent unauthorized access or modifications:
- encryption for data at rest
- a TLS/SSL security layer for data in motion
- the Intel SGX technology for data in use
Let’s consider a usual blockchain peer-to-peer network. Nodes store, update, and broadcast a full copy of the ledger that contains transactions blocks. Transactions are submitted by users. After that, nodes get a transaction proposal and validate it. If validation is successful, then a transaction will be added to the ledger.
The ledger stores all transactions, and it means we are dealing with data at rest. If nodes broadcast blocks in the network, then have data in motion. If nodes execute and validate transactions, then it’s data in use.
What about transactions that contain sensitive data? Blockchain-based applications and computing are controlled by a distributed network of multiple machines or nodes. Each node that takes part in validating transactions gets access to the data in clear text. Any root privilege user of the node may easily inspect, control, and transfer sensitive data.
In this case, we need to trust all the nodes that operate with sensitive data. However, it’s difficult to avoid the nodes in the network being compromised.
With SGX, each node can have a secure transaction execution module. Transactions will be executed and validated in an enclave. In addition, the enclave can attest another remote entity that the node can be trusted.
Overall, a user can achieve the following results in terms of privacy, security, and trust:
- keeping transaction information isolated from other participants in the network
- securing and obfuscating keys from malware
- authorizing such off-chain participants as oracles and sensors via remote attestation
The official developer guide sheds more light upon using SGX “to protect select code and data from disclosure or modification.”
Where can be applied?
At the recent blockchain meetup in Zurich, Dmitry Lavrenov of Altoros described two scenarios that can make use of SGX on a blockchain.
Imagine there is a contract C between participants Victor (a supplier) and Peggy (a buyer) that reflects a commitment for a future payment. (In practice, this may include details of the exchange of goods, a purchase order, and shipping information). Details of the contract are available exclusively to Victor and Peggy initially, however, the existence of the contract must be recorded for further use by all the interested parties.
At some point, Victor may choose to disclose the existence of C and some of the details to a specific collection of participants:
F1, …, Fn (factors). Only those participants chosen by Victor may know the information about the contract. Factors must be able to verify that the contract exists, and that Victor is a supplier in the contract, while Peggy is a buyer.
Fi may create bid
Bi for the contract. Details of the bid may be known only to
Fi and Victor, however,
Fi must commit to the bid.
Victor may choose a bid and execute a transfer of ownership of the contract to the participant that generated the bid that was selected. At this point, the winning participant may see all the information about the contract. After handoff, Victor may no longer see changes to the contract or modify it.
This usage helps to identify several functional requirements related to managing access to the information about transactions and participating parties:
- During the bidding process, all information about the identities of the factors must be hidden from the buyer and the other factors.
- Details of a bid must be kept confidential to the seller.
- The identity of the winning factor must be kept confidential from the other factors.
- Factors have the right to view only specific details of contract C that are exposed by the supplier.
- The winning factor gains visibility to all details of contract C, when an ownership is transferred.
Online voting uses electronic means to either aid or take care of casting and counting votes. With the online model, first, the registrar creates a new voting pool. Voters can then cast their vote, which is anonymized and stored in an electronic ballot box. A ballot may contain one or more questions with simple yes/no or multiple choice answers.
After a voting period ends, a voting committee counts and verifies the ballots and announces the tally. E-voting calls for specific requirements across security, integrity, privacy, and transparency.
- Voters require a unique identifier. Voters impersonation must be prevented. Voters can cast ballot only once.
- Casting ballots must be protected in terms of integrity and confidentiality at rest and in motion.
- Casting ballots can only be revealed to an authorized entity (committee / validator) that counts ballots.
- Voters must be able to verify that their ballot has been considered (counted) during validation.
- A validating system must be resistant to misbehaving committee members to ensure that no party can corrupt the voting process and forge the result.
Employing blockchain coupled with Intel SGX, it is possible to meet the above-mentioned requirements for both supply chain and e-voting. Furthermore, by pairing blockchain with Software Guard Extensions, one can implement secure solutions for industries such as insurance, retail, healthcare, banking, real estate, etc.
Want details? Watch the video!
During this session, Dmitry Lavrenov of Altoros explained the topic in detail.
The slides from the recent blockchain meetup in Zurich:
- A Zero-Knowledge Proof: Improving Privacy on a Blockchain
- Securing a Blockchain with a Noninteractive Zero-Knowledge Proof
- Blockchain for Insurance: Less Fraud, Faster Claims, and New Models