The foundational technologies underlying Bitcoin are a secure, distributed transaction ledger, timestamp server and proof of work algorithm implemented as a blockchain ledger. As Satoshi put it his seminal paper, these make it “computationally impractical for an attacker to change if honest nodes control a majority of CPU power” on the Bitcoin network. While Satioshi didn’t invent blockchain technology, his implementation has proven particularly robust and led many technologists to see blockchain as a solution to all manner of problems.
Sadly for the blockchain evangelists, enterprise successes have been elusive. Indeed, as is regularly pointed out here, blockchain often looks like a technology in search of a problem. Such cynicism is understandable, but unfortunate since blockchain includes several security technologies that can improve conventional databases and transactional applications. Oracle sees the potential and has embraced blockchain technology via several features added to its ubiquitous database to provide what it calls crypto-secure data management.
Security for after barbarians breach the gate
In making the case for Oracle’s blockchain-based security technology, Juan Loaiza, the company’s EVP of Mission-Critical Database Technologies, notes that conventional data security techniques like passwords, role-based access controls (RBAC), data encryption and network firewalls are designed to prevent unauthorized actors from reading data. Unfortunately, these methods are powerless to stop insiders or attackers that have acquired employee credentials from retrieving, modifying or deleting sensitive information such as financial or legal records, customer and employee personally identifiable information (PII), business transactions or intellectual property.
Oracle introduced blockchain tables for its eponymous database at OOW 2019 as a way to make existing databases tamper-resistant. It recently expanded blockchain features in Oracle 21c that it now markets as a four-pronged approach to cryptographically-secure data. The key capabilities and associated Oracle features are:
- Immutability (Immutable tables)
- Tamper resistance (cryptographic digests)
- Authentication and change attestation (cryptographic signatures)
- Illicit change detection (distributed digests)
Similar features form the foundation of most blockchain systems and cryptocurrencies, however, integrating them into Oracle provides enterprise systems blockchain-class data protection without requiring significant changes to existing applications.
Tamper-proof tables
Many types of financial, government and logistics data serve as a permanent record of transactions, events or decisions that should not be altered, only updated. Oracle protects against such tampering via immutable and blockchain tables. Immutable tables prevent existing data from being changed or deleted by anyone, even database administrators. Specifically, immutable tables block the following actions:
- Updating or deleting rows
- Changing table definitions
- Changing the table’s status from immutable to updatable or vice-versa
- Modifying table metadata in the database dictionary
Attackers could still try to exploit an unknown Oracle or OS vulnerability and bypasses immutability controls to directly manipulate an immutable database. Blockchain tables expose such post hoc modifications by adding a cryptographic hash to each table entry that cannot be forged. As the name suggests, Blockchain tables chain rows in sequence by using a SHA-512 cryptographic hash of the row contents plus (for all but the first row of a table) the hash value of the previous row. Thus, any attempt to modify existing data or insert (rather than append) a row) will break the hash validation of all subsequent rows.
Validating data authenticity
While immutability and blockchain-ing data thwart tampering, they don’t address attackers adding bogus data under a stolen identity or prevent a group of conspirators from replacing the entire database. Oracle hinders unauthorized data additions by allowing users to cryptographically sign inserted data using public-private key cryptography and digital certificates. Users sign new data with a private key and since the database system validates signed entries against the user’s certificate, attackers that have only stolen a user’s login credentials, but not their private key, can’t add data with a valid signature.
Immutability, blockchain and data signing stymie the vast majority of data modification shenanigans, but they can’t prevent Enron-style fraud by determined insiders. For example, conspirators with the right access rights might decide to replace an entire blockchain database with a phony replica. Such coordinated assaults are impossible to prevent without a Bitcoin-like peer-to-peer system, but Oracle can expose them by automatically distributing a cryptographic digest to trusted external repositories. Since the digest is a one-way hash that doesn’t mathematically allow inferring the starting data from the hashed result, publishing the digest (as public blockchains and cryptocurrencies do) doesn’t compromise database security. For example, a digest might be sent via email to an audit firm, published to an independent cloud store using REST APIs or added to a public Ethereum network. Coordinated rip-and-replace database attacks can easily be spotted by comparing the current contents to previously published digests.
As mentioned, entirely preventing illicit database-bypass changes requires a Bitcoin-like distributed blockchain that replicates a database to independent third parties that must reach consensus for every change. Most consensus algorithms entail solving the Byzantine Generals Problem using either a proof-of-work (PoW) (used by Bitcoin) or proof-of-stake (PoS) algorithm (used by BitShares and others, with Ethereum moving to this mechanism). Such systems have proven resistant to coordinate 51-percent attacks, but as Loaiza pointed out in explaining Oracle’s blockchain technology, distributed consensus in a peer-to-peer system doesn’t mesh with existing business processes and relationships. He adds, “Overall, peer-to-peer provides very effective illicit change prevention, but at the expense of significant complexity for mainstream use-cases.”
Both immutable and blockchain tables are core Oracle 21c features and have been backported to 19.11 and 19.10, respectively.
My take
Blockchain and related crypto features are an example of Oracle’s single-database strategy I detailed an earlier column in which it adds new data types and capabilities within the familiar RDMS construct. Oracle illustrates the value of this all-in-one approach by repackaging features like immutability, blockchain tables, data signing and distributed hashes as security enhancements with broad applicability. While the label “crypto-secure data management” doesn’t roll off the tongue, it’s a reasonable way of categorizing these additions to core database functionality within Oracle’s broader set of security features designed to keep attackers from accessing a database. However, once they’ve breached the castle walls, cryptography and blockchain can limit the damage.