How to Achieve Crypto-Secure Data Management

March 3, 2021 | 4 minute read
Maria Colgan
Distinguished Product Manager
Text Size 100%:

The primary focus of conventional data security technologies like passwords, firewalls, and data encryption is to keep criminals out of your company and your data stores.
But what protects your data, especially your essential assets (contracts, property titles, account statements, etc.), from being modified or even deleted by folks who gain access to your systems legitimately or illegitimately (hackers)?

Crypto-Secure Data Management

This is where Blockchain can help. Layering Blockchain technologies on top of conventional data security features provides an extra level of protection that prevents illicit modifications or deletes of data.

 

What is Blockchain?

When we think of Blockchain, many of us instantly think of decentralized peer to peer apps that only permit consensus-based data changes. However, adopting these apps requires new development methodologies, speciality data stores and potentially new business practices, which is complicated and expensive!

But, if we take a closer look at Blockchain technologies, we see four critical components; immutability, cryptographic digests, cryptographic signatures, and distributed systems. Each part works to protect against a different aspect of illicit data changes performed using legitimate user credentials or by hackers.

Integrating these Blockchain technologies into the Oracle Database brings the critical security benefits of Blockchain to mainstream applications with minimal or no changes required. Providing the full functionality of the world’s leading database on crypto-protected data.

Blockchain the Oracle Database

In the video below, Juan Loaiza explains how Oracle implemented Blockchain technologies in the Oracle Database and how you can use them to protect your essential business data.

How Blockchain technologies work in the Oracle Database

To protect against illicit data changes made by rogue insiders or malicious actors using insiders' credentials, Oracle has introduced Immutable tables (insert-only tables) in Oracle Database 21c (21.3) and Oracle Database 19c (19.11).

Immutable tables

With an Immutable table, it is possible to insert new data, but existing data cannot be changed or deleted by anyone using the database, even the database administrators (SYSDBA). It is also impossible to change an immutable table's definition or convert it to an updatable table. However, an Immutable table appears like any other table in the database from an application's point of view. It can store both relational data and JSON documents, and it can be indexed and partitioned or used as the basis of a view.

Blockchain tables

To protect against illicit changes made by hackers, Oracle has introduced Blockchain tables. Blockchain tables are immutable tables that organize rows into several chains. Each row, except the first row in the chain, is chained to the previous row via a cryptographic digest or hash. The hash is automatically calculated on insert based on that row's data and the hash value of the previous row in the chain. Timestamps are also recorded for each row on insertion.

Any modification to data in a Blockchain table breaks the cryptographic chain because the hash value of the row will change.

You can verify the contents of a blockchain table have not been modified since they were inserted using the DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWS procedure.

End-User Data Signing

Even with Immutable or Blockchain tables, data can be falsely inserted in an end user's name by someone using stolen credentials. To address this vulnerability, Oracle allows end-users to cryptographically sign the data they insert using their private key that is never passed to the database. Each end-user registers a digital certificate containing their public key with this database. This digital certificate allows the database to validate the end-users signature when new data is inserted. Even if a hacker manages to steal a valid set of credentials without the private key, the signature on the newly inserted data won't match and will therefore not be accepted.

It's also possible for end-users to ensure the database has received their changes by requesting Oracle countersign the newly inserted data. Oracle returns a crypto-receipt to the user, ensuring nothing on the mid-tier can filter specific data to prevent it from being recorded.

Distribution of Cryptographic Digest

Even with cryptographically chained rows, sophisticated cyber-criminals or authorities could illicitly change data via a large-scale cover-up, where the entire database is replaced. To detect such a cover-up, Oracle enables schema owners to sign and distribute the cryptographic digest for a blockchain table periodically.

Remember, the digest can’t be used to infer the data in the table, but authorized users can use it to validate the chain and confirm their newly inserted data is present. The crypto-digest can be posted to an independent public store or blockchain, like Ethereum or sent out by email or made available via a REST API.

A cover-up can easily be detected by comparing the previously published digests to the current table content. Also, distributing them publicly across multiple independent services prevents an authority or cyber-attacker from deleting all the separate copies.

Getting Started With Blockchain

Both Immutable and Blockchain tables are free features of the Oracle Database. No additional licenses or software is needed to take advantage of these new table types, which are completely transparent to all new and existing applications.

Also, note Oracle has backported Immutable tables and Blockchain tables to Oracle Database 19c (19.11 and 19.10, respectively).

For more information on Blockchain, check out the Oracle Blockchain blog, Oracle Blockchain LiveLabs or the Oracle Blockchain documentation.

Maria Colgan

Distinguished Product Manager

Maria Colgan is a distinguished product manager at Oracle Corporation and has been with the company since version 7.3 was released in 1996. Maria’s core responsibility is creating material and lectures on the Oracle Database and the best practices for incorporating it into your environments. She is also responsible for getting the feedback from our customers and partners incorporated into future releases of the product
Prior to this role; she was the product manager for Oracle Database In-Memory and the Oracle Database query optimizer.  Maria is the primary author of the SQLMaria blog https://sqlmaria.com and a contributing author to the Oracle Optimizer blog http://blogs.oracle.com/optimizer


Previous Post

Automatically Scaling Exadata Cloud Service Based on Workload (Part 1)

Bob Thome | 7 min read

Next Post


[IDC] The Blockchain Innovations in Oracle Database

Guest Author | 3 min read