Credit:
Thinkstock
As I mentioned in my most recent post, solutions for legal non-repudiation are critical for organizations — and biometrics are an ideal solution for data provenance. Specifically, biometric authentication can be used to satisfy compliance with regulations such as the Payment Services Directive II (PSD2) consent requirements, which are critical for privacy, data provenance and non-repudiation.
Currently, if you consent to a payment using “what you see is what you sign” (WYSIWYS) features via push notifications on a mobile device, a text record of that transaction is logged on the server. But a simple text log entry is insufficient for non-repudiation. Proof is required that it was indeed a specific user that approved a given payment. A biometric digital signature of the transaction within the associated log entry solves the non-repudiation problem by associating the transaction details with a user.
But while biometric transaction signing is leaps and bounds better than using passwords or tokens, even that isn’t a foolproof method: without anti-tampering mechanisms, the log can still be corrupted. The digital signature prevents tampering with individual entries, but entries could be falsified by deleting existing entries or adding counterfeit summaries. That means some of the scenarios I outlined previously that could be headed off by using biometric authentication — a trader denying responsibility for a bad transaction; redirecting funds through a falsified account — could nevertheless be covered up if the perpetrator accessed and rewrote the transaction on the log.
[ Docker, Amazon, TensorFlow, Windows 10, and more: See InfoWorld’s 2017 Technology of the Year Award winners. | Cut to the key news and issues in cutting-edge enterprise technology with the InfoWorld Daily newsletter. ]
A log is an append-only diary of all transactions summaries for all users. Typically, logs are kept in log files on a server. Each log entry is a transaction summary that contains the following information: a transaction ID, signature, user ID, date, time, operation, amount, beneficiary, accounts, and any approval identities. Most anti-tampering mechanisms prevent tampering by making any attempts to corrupt the log evident to an external audit. But there’s a quickly emerging solution that more and more enterprises are starting look at to protect their log: Blockchains.
Blockchain solutions provide strong tamper-evident protections for transaction logging. Permissioned mutual distributed ledgers (PMDLs: that is, blockchains) such as Ethereum and Hyperledger, are incredibly well-suited for tamper-evident transaction logging because blockchains enforce the integrity of the chain of transactions in their very structure. Each block in a chain is assigned a block identifier that is the hash result of the data payload, the block ID of the previous block, and the proof-of-work nonce. The data payload contains one or more transactions (of all types). Any attempt to tamper with the contents of any block on a chain will result in incorrect hash of the block contents, invalidate the block’s ID, and thus “break the chain” since the succeeding block’s previous pointer will be incorrect. (An excellent illustration of blockchain technologies can be found here.)
Blockchain solutions also provide the transparency necessary to prevent wholesale falsification of the entire chain. While the nonce proof-of-work helps prevent overnight falsification of a chain, a publically accessible chain guarantees that a chain is not counterfeit since it is not under the sovereign control of a single authority. Public blockchains are stored in a decentralized fashion, across thousands of nodes globally, operated by independent entities. At any time, past or present, a block on the chain can be validated for a given date and time.
Blockchain solutions are not fast, but transaction logging is not a real-time requirement. In some cases, it may take upwards of 10 minutes to several hours for a transaction to appear in a block on a given chain. As an append-only record, a log entry can “eventually” appear on a given blockchain. Some chains offer service level agreements (SLAs) and other guarantees, but most require retry mechanisms if initial attempts to append a transaction fail. In addition, many have associated costs with transactions that need to be considered when high volumes of log entries are expected.
Blockchains, such as the Bitcoin chain, have a reputation of being used for illicit purposes such as drug trafficking. The pseudoanonymity provided by blockchain technologies attracts such use and will continue to challenge legal and policy experts. Blockchains are like our public roads: they are used by all types of people for good and bad purposes, but they provide an invaluable conduit for public as well as private commerce, culture and communications.
Logs have been primarily used for troubleshooting or monitoring, but upcoming regulations add new auditing requirements to log analysis. Enterprises need to rethink the traditional role of transaction logs, their associated storage, and analysis. Typically, logs have been kept on the server in files and compressed archive formats. They have been kept in SQL databases or NoSQL document stores. Theses storage schemes, however, are insufficient for non-repudiation, vulnerable to tampering and lack transparency. For complete, end-to-end certainty, and legal non-repudiation, tamper-evident and auditable transparency — you simply can’t beat the blockchain and biometrics pairing.
This article is published as part of the IDG Contributor Network. Want to Join?
