| Contents | |
|---|---|
 Fractal Secured Blockchain |
Blockchains secured internally without the need for decentralised networks |
| Cannot Trust Legacy Architecture |
Legacy database security relies on digital fortress security |
| Provenance Example |
Growing demand for Trust Platforms |
| Decentralised Blockchain Nonviable |
Significant distributed blockchain costs and risks |
Fractal Secured Blockchain
Delivery of data immutability and trust solves a wide range of problems, including client data integrity and product provenance tracking.
Recent solutions involve decentralised blockchains that have high associated costs and risks.
Blockchains can be secured internally without the need for decentralised networks of mining servers. This can be achieved by fractal locking the start and end of the blockchain.
Portalz Trust implements our Quantum Proof Security technology, creating 'secure blockchain loops' at the core of its DNA Enterprise Foundation.
Portalz Trust brings unique-per-record immutability to data contained in Portalz DNA, locking records with Quantum Proof Security and implementing a revolutionary hierarchy of invisible morphed keys.
The resulting security cannot be penetrated without authorisation by an attacker, including the database administrator!
That same security infrastructure maintains a Quantum Secured Backup for each record, able to detect unauthorised changes, reporting the breach and automatically restore the authorised record.
This awesome capability is delivered seamlessly and automatically to every data store configured in Portalz DNA.
No Trust in Legacy Architecture
Databases allow any operator or process with database access to change, delete or insert any data anywhere in the database.
Typically there is no way to tell when or if data has been changed without comparing to a restored backup, a slow and expensive exercise.
While some databases may have implemented change tracking, this can typically be circumvented by an attacker. While an attacker can execute SQL statements that can delete or alter entire tables, these would be quickly detected. Small unauthorised changes can have the greatest negative impact.
Provenance Example
Demand for Trust Platforms to guarantee product and process provenance is increasing.
A Trust Application:
- Uses data record for each product being tracked
- Defines a set of stages or processes that the product must complete
- Provides for different operators for each stage or process
- Delivers certification of each product for all stakeholders
- Monitors costs of certification stages or processes
- Increases the value of the certified product
- Manages and tracks shipments of certified products
Consumers relying on the integrity of the Trust Platform will need proof that it has not been accessed by unauthorised agents and that its data has not been modified
Unauthorised change of product data can skip stages or processes,
change weight, quality, value, category etc, undermining trust and integrity.
How can the provider and owner of a Trust Platform guarantee that no unauthorised changes have been made, when conventional databases can be so easily and undetectably changed?
Decentralised Blockchain Not Viable
Blockchain has become a buzzword since the launch of Bitcoin, and designers of Provenance Platforms have been working to bring blockchain's immutable properties to databases.
It is important to know that Blockchain is not really the core security of Bitcoin, it is the thousands of servers that vote on the blockchain ledger contents that underpin its immutability. Blockchain itself is simply a hash sequence of values that allow you to determine if any changes happened in the history. The vote on the 'correct' hash sequence is still prone to a well known 51% vote vulnerability.
So in order to access decentralised blockchain immutability engineers require a large number of voting servers. Typically they solve this by using an existing decentralised blockchain token and its server network. This solution has a price:
- Reliance on a third party server network
- Transaction fees charged by the miners for each validation
- Sensitive data is exposed to outside agents and competitors
Once such a token network is created it must integrate with your database.
Integration must be performed with every table in the database that requires trust guarantee. It can be argued that all of the tables of a trust platform require integration.
Decentralised Blockchain integration is a significant overhead and expense and exacerbates legacy database problems.
Ultimately certification must be made on the Blockchain as database integration can be tampered with.
Decentralised Blockchain is not a viable solution to data trust.
