Karthik Sai
Learners Blog

Learners Blog

Blockchain-Based Biometric & Tamper-Proof Audit KYC System

Blockchain-Based Biometric & Tamper-Proof Audit KYC System

Karthik Sai's photo
Karthik Sai
·Feb 28, 2022·

30 min read

Table of contents

Blockchain-Based Biometric & Tamper-Proof Audit System


For the last few years, the world has been concerned about the security and privacy of the data that is being shared with the companies. A layperson cannot know precisely how companies use this data and is distributed amongst other institutions. Moreover, this is exceptionally true when it is related to a person's Biometrics, and people would like to know to whom, where, and why they gave access to their Biometrics. There is not truly any transparent way for an individual to obtain that information. The article will try to confront this issue in a novel approach using Blockchain. Furthermore, it also talks about Biometrics and security in detail.


The concept "Blockchain" has become widespread and is recognized as one of the most disruptive technology in decades. The Blockchain is a decentralized, peer-to-peer, immutable, and distributed cryptographic ledger to manage and transfer the value of digital assets throughout the world. The distributed ledgers encompass transactions recorded and maintained in chronological order that are bundled together to form a block. Through a cryptographic hashing method, each block is chained to its preceding block, forming Blockchain. Chained meaning that each block would point to its previous block by storing its hash.


Blockchain is made on top of a P2P system. Each peer in the network is represented as a node and has a full copy of the Blockchain, granting reliability and availability. A single entity does not manage a Blockchain. Instead, it is managed by all nodes in the network through some consensus mechanism. The nodes in a Blockchain can be a full node and a light node. A light node takes the help of the full nodes to maintain and validate the Blockchain. The full nodes will keep the complete copy of the Blockchain, validate the transactions' integrity, and support the light nodes. Some full nodes in the network are responsible for bundling the transactions forming a block. These nodes offer computational resources and time required to perform the cryptographic hashing mechanism and are awarded some fee from each transaction in the block they created. Each Blockchain has different aliases to refer to these nodes depending on the cryptographic hashing method. Once a transaction or data is recorded in the Blockchain, it is nearly impossible to change it, providing immutability. For an entity to tamper with the data, it needs to control the majority of the nodes, meaning at least 51%, to get that change accepted in the Blockchain. Moreover, achieving this task requires substantial computational power and time, which is improbable to acquire. This mechanism heightens the security of the Blockchain and makes it tamper-proof.

Due to the advantages and enhanced security, privacy and trust, many platforms came into existence to develop applications based on Blockchain. One of the most popular and widely used applications of this technology is cryptocurrencies(electronic payment systems). Bitcoin is the first electronic payment system based on Blockchain and is acknowledged as a breakthrough in fault-tolerant distributed computing.


The Bitcoin Blockchain implements a proof-of-work cryptographic hashing mechanism to validate the integrity of the Blockchain. The nodes responsible for creating(or mining) the blocks are termed miners, and the process is called mining. This process is further discussed in detail in the coming chapters. Soon after the launch of Bitcoin, many platforms came into existence that were developed on top of Blockchain, such as Ethereum, Ripple, Quorum, Hyperledger-fabric, etc. Ethereum is one of the most extensively used platforms to develop decentralized applications and was used in this article.

Ethereum is an open-source, public, blockchain-based distributed computing and operating system with smart contract functionality. Ether is the platform's native cryptocurrency, and it is the second-highest in the market capitalization after Bitcoin. Ether(ETH) is used as a fee for every transaction and will be awarded to the mining nodes as compensation for computations performed and can also be transferred between platform accounts. Ethereum provides a decentralized Turing-complete virtual machine, the Ethereum Virtual Machine (EVM), which can execute scripts using an international network of public nodes. The transaction fee mechanism Gas is used to mitigate spam and allocate resources on the network. Smart contracts are applications that run specifically as programmed without any feasibility of downtime, fraud, or third-party interference. These apps run on a custom-built blockchain, an enormously powerful shared global infrastructure that can move value around and represent property ownership. The smart contract enables developers to create decentralized applications without a middleman or counterparty risk. Using the Ethereum and smart contracts, the article has established a way for an individual to attain information of his/her Biometrics access log transparently.

Evolution of Biometric for web server-based applications.

Right from the advent of the internet for use with laymen, the methods of authentication and authorization included a simple username and password for almost all the websites. Followed by that most of the websites adopted certificate-based authentication. A public key is issued to the user, it will be used during the sign in to identify the user on the server. It is an application of asymmetric cryptography. Eventually, with the standardisation of JSON format for almost all web services, token-based authentication became popular. Once a user logs in with a username and password, the server sends a unique token to each user. Subsequent server access is done with this token. Similarly, cookies were also used. This was the de-facto for a long time.

In the 21st century, mobile phones have become a part of life and most of the tasks can be easily accomplished with the ease of fingertips. Even the crucial ones like payments and bank transfers are being carried out with the help of smartphones these days. So, smartphones are one of the portals to access web services. Smartphone security has become very crucial as it involves dealing with crucial financial services. So along with simple authentication multi-factor and two-factor authentication has been added to enhance the authentication security.

In multi-factor authentication, a user has to provide two or more factors to identify himself. Along with the user name and password, he needs to enter a One Time Passcode (OTP) or Time-based One Time Passcode (TOTP). The OTP’s are sent to the user phone numbers or emails that were submitted while registering. Additionally, it can also be answers to the personal questions that were taken at the time of registration. All the above measures were good enough assuming the device is being used by the same person. If the device is being used by another person or it is somehow cloned, then it would be a problematic situation. Initially, passcodes, PIN’s and app locks were used to mitigate the issue to some extent. But with the rapid incline in smartphone hardware development, access to the biometrics of the user has become a usable option. Native SDK’s has been provided by the OEM’s and programmers can use them as per their requirements in a sophisticated and flexible manner.

Face Unlock was one of the primitive biometric mechanics in mobile phones. It uses the camera to register the user’s face and have a binary version of it. For every important feature access or security crucial applications, the face unlock feature verifies the identity of the user. But as it takes just the 2d image of the user, it can be easily spoofed by a photograph of the user. In order to overcome this issue, fingerprint scanners were introduced in the mobile phone. Since everyone has a unique fingerprint it is very very difficult to clone or duplicate it. In this way, the security of mobile phones and subsequent access to critical data of users has been evolved.

Advantages of using biometric over traditional authentication methods.

  • Passcodes can be lost easily.
  • One time passcodes are sent to mobile or email. Advanced SIM cloning mechanisms nullify the OTP security. If the email used was breached then all the apps linked to that email are indirectly affected.
  • Just asking the user to submit a fingerprint is much more convenient than remembering passwords and inputting them.
  • It’s much faster than typing a password.
  • It is nearly impossible to spoof biometrics.
  • The biometrics database is kept highly secure.
  • They directly authenticate the person instead of a virtual account. Simply put it uniquely identifies an individual
  • As the entire activity is strictly logged, accountability is highly maintained and auditing will be accurate and simple.
  • Easy to integrate into almost any device in a secure manner.

Ethereum Blockchain

Ethereum is a public, open-source Blockchain that enables the creation of financial, entertainment applications called Decentralized Applications, dApps through a smart contract. A smart contract is a code that governs the logic of a specific transaction or a function. To implement smart contracts, Ethereum has its native programming language called Solidity. Solidity is a high-level, object-oriented, curly-bracket language and will target the Ethereum Virtual Machine(EVM). To use the dApps, the users need to pay some fees known as gas fees, and it depends upon the computational power required. These fees are paid in Ethereum's native cryptocurrency called Ether(ETH). Ethereum is known as the "world's programmable Blockchain" and serves as a marketplace for diversified, decentralized apps that are trusted and safe from fraud or theft. Ethereum is wildly entertained for applications that automate the direct interactions between peers or promote coordinated collective action over a network.

Ethereum Virtual Machine(EVM)

As mentioned before, Ethereum allows developers to create applications or specific operations with any level of complexity instead of giving a predefined set of functions such as Bitcoin transactions in Bitcoin Blockchain. Ethereum, in a way, suggests a set of protocols that define a platform for the creation and implementation of decentralized applications. At its essence is the Ethereum Virtual Machine(EVM), which can perform any algorithmic code of any level of complexity. EVM is Turing Complete, a system competent for executing any logical step of a computational function. The decentralized Applications - dApps that can be developed through a programming language such as Solidity modelled after languages like Javascript and Python will run on the EVM.

Ethereum, like any Blockchain, includes a peer-to-peer network protocol. The Ethereum Blockchain database is managed by several nodes connected to the network. Every node in the network runs the EVM and executes the exact sequence of instructions. On account of this, Ethereum is often described reminiscently as a "world computer." This extensive parallelization of computing across the whole Ethereum network is instrumental in maintaining consensus across the Blockchain. Decentralized consensus gives Ethereum the utmost levels of fault tolerance, guarantees zero downtime, and makes data stored on the blockchain immutable. EVM essentially executes a code collection with some methods and data(refers to state) called smart contracts.

Smart Contract

A "smart contract" is a piece of code or a program that runs on the Ethereum Blockchain. It can define rules, instructions similar to a standard contract and automatically implement them through code. It resides at an address created while deploying on Ethereum Blockchain, implying that smart contracts are a type of account on Ethereum. They can have balance and can conduct transactions across the network. However, individual users do not regulate them. Instead, they run as programmed from the moment they are deployed. Any other accounts on Ethereum can interact with a smart contract through some methods defined on the smart contract. A smart contract cannot be deleted by default, and the interactions with them are immutable as it lives on the Blockchain.


A smart contract cannot be directly deployed onto the Blockchain as it is written in high-level programming languages like Solidity. It needs to be compiled into a bytecode executable on the EVM and will be deployed on the Blockchain. When a smart contract is compiled, it gives bytecode and ABI. As mentioned beforehand, the bytecode will be deployed on the Blockchain, and it returns an address called contract address through which the data and functions defined on the smart contract can be accessed. However, interacting with the smart contract with only the bytecode and the contract address is extremely difficult as it is impossible to comprehend the functionality of a smart contract. Hence, ABI, expanded as Application Binary Interface, plays a crucial role in understanding a smart contract's functionality. ABI is a javascript formatted object(JSON) that describes the different methods and data available on the smart contract like parameters, name of methods, return values, payability, and state-transition functions. If any account on Ethereum requires interaction or requests a function on the smart contract, it utilizes ABI to hash the method and create an EVM bytecode to invoke the function or method.

However, for every execution of a statement or instruction on the smart contract or, more specifically, on the EVM, as the EVM executes a smart contract, there needs to be a fee paid by the user account invoking the smart contract. There needs to be a fee paid for every transaction on Ethereum. For the smart contract deployment, a fee is required to be paid as it is technically a transaction. Essentially, a fee needs to be paid if that particular action demands a state change on Ethereum. This fee is called Gas.

Gas Fee

Gas indicates the unit that estimates the amount of computational effort is required to run a transaction or a specific transaction on the Ethereum network. As each transaction needs computational resources to execute, it demands a fee. Gas refers to the fee that needs to be spent to execute a transaction successfully.

Gas fees are paid in Ethereum's native currency, Ether(ETH). Gas prices are denoted in gwei, which is a denomination of ETH. Each gwei is equal to 10-9 ETH. The term "gwei" refers to "Giga-Wei" and is equal to 1,000,000,000 Wei, where Wei is the smallest unit of ETH. Prior to the Ethereum London Upgrade, the transaction fee was calculated based on the per-unit gas price and gas limit. Gas limit is the amount of computing work needed to execute a certain operation. For example, to transfer ETH, the gas limit is 21,000 units. Any gas limit less than 21,000 will result in failure. Gas price is the value that a user account is willing to pay per unit of gas limit. The gas price is dependent on the network traffic, and it determines how fast the transaction will be mined or confirmed. The higher the gas price, the faster the transaction will be confirmed. So assuming that the current network gas price is 200 gwei, then for an ETH transfer transaction, the transaction fee is.

=> Transaction fee = Gas Limit * gas price per unit

=> Transaction fee = 21,000 * 200

=> Transaction fee = 4,200,000 gwei or 0.0042 ETH

So, to transfer 1 ETH from account A to account B, account A must have at least 1.0042 ETH. In that, 1 ETH will be credited to account B, and 0.0042 ETH will be paid to the miner as a transaction fee.

After Ethereum London Upgrade

This upgrade was done on August 5th, 2021. This upgrade was achieved to ensure transacting on Ethereum is more predictable by improving Ethereum's transaction fee mechanism. The prominent advantages that came by this change involve better transaction fee estimation, faster transaction inclusion, and balancing the ETH issuance by burning a portion of transaction fees. With this upgrade, now every block will have a base fee, and each transaction must include the base fee and also expected to add a priority fee, as the base fee will be burnt from the total transaction fees. The priority fee is also known as a tip and will compensate miners for executing and transmitting the transactions in blocks.

So based on the above-said statements, the total transaction fees will be calculated as given below.

=> Transaction fee = Gas limit * (Base fee + Tip)

For a transfer of 1 ETH from account A to account B, the required gas limit is 21,000 units, and assuming the base fee is 100 gwei and account A user adds a tip or priority fee of 10 gwei. So, the transaction fee will be as follows.

=> Transaction fee = 21,000 * (100 + 10)

=> Transaction fee = 2,310,000 gwei or 0.00231 ETH

=> Base fee = 21,000 * 100 = 2,100,000 gwei or 0.0021 ETH

=> Priority fee(Tip) = 21,000 * 10 = 210,000 gwei or 0.00021 ETH

Based on this, account A must have at least 1.00231 ETH to successfully execute the ETH transfer to account B. From the total transaction fees, the base fee of 0.0021 ETH will be burned, and the remaining fee, which is the tip, will be given to the miner.

Additionally, account A can also set a max fee for the transaction. The difference between the max fee and the actual transaction fee is refunded to account A after the transaction is executed.

=> refund = max fee - (base fee + priority fee)

In this way, account A user can set a maximum amount to pay for the transaction to execute successfully and not worry about paying more than the required base fee.

Base Fee

The London Upgrade also introduced variable-size blocks to Ethereum before it was fixed-size blocks. The fixed-size blocks operate at total capacity in times of high network demand, which results in high waiting for a transaction to get included in a block and hence leading to a bad user experience. But now, with the variable-size blocks, there is a target block size of 15 million gas for each block but, the total size of the block can increase or decrease depending on the network and can go up to 30 million gas(2x of target size). Through this, an equilibrium block size of 15 million gas on average can be achieved by setting the base fee proportional to the difference between current block size and target block size. Meaning, if the block size is greater than the target block size, the base fee will be increased for the following block. Similarly, the base fee will be decreased if the block size is less than the target block size.

For a transaction to be included in a block, it must have a gas price per unit at least equal to the base fee of the block. The base fee of a block is independent of the current and is determined by the previous blocks, which makes the transaction fees more predictable. The base fee that is collected from the transactions will be burned when the block is mined.

If the previous block exceeds the target block size, then the current block base fee will be increased by a maximum of 12.5%.


Priority Fee (Tips)

Before the upgrade, all the transaction fees will be received by the miner. But with the London upgrade, the base fee from the transaction fee will be burned, and to incentivize the miners to mine a transaction, a priority fee or tip can be set in the transaction for the miners to receive it. So by setting a higher priority fee or tip, the faster, the transaction will be executed or mined.

Max Fee

The users can set the maximum amount that they are willing to pay as fees for a transaction to be executed successfully. This is an optional parameter and is called maxFeePerGas. The max fee must be greater than the sum of the base fee and the priority fee. And the difference between the max fee and the actual transaction fee will be refunded to the transaction sender.

Know Your Customer - KYC

It is abbreviated as know your customer or know your client. It is a sort of verification process that enables companies, organizations, and financial institutions to know, assess and verify their customers. Usually, it is used to verify the identity and address of the client. It is also a regulatory and legal requirement in most countries. It involves a review of financial activities, estimating and assessing the risk factors in order to reduce the risk of money laundering, and other forms of illicit financial activities. Institutions can be assured that their services cannot be misused if they can vet their customers.

The KYC is a complex process that involves the collection of documents that show proof of identity (in most cases they are Government-issued IDs), establishing and verifying customer identity, and screening the information against political exposure, criminal lists, and unreliable customers lists.


The importance of KYC norms in organizations helps establish trust in a customer, allowing the business organizations to understand the nature of customer activities. Additionally, it provides protection from fraud and losses. It is a one-time process. It could be either online or offline based verifications or a mixture of both. It can include cross-checking their current address and verifying the authorized signatories. Extracting detailed information about customers protects and is beneficial to both parties. KYC procedures help in developing a strong trust in a business relationship and give an organization insight into the types of customer activities. Some of the details of customer identification include Full Legal Name, Date of birth, Current Address, Previous Investment Experience, Investment Preferences, Customer Assets & Income. The gathered information must be verified within a reasonable timeframe. Preferably it should be a couple of days.

Verifying the customer background once is not enough for long-term trust. As soon as the KYC is successfully verified the customer is on-boarded into the organization. This doesn’t end here, there should be ongoing monitoring of the customer activities and should be continuously monitored for any abnormal behaviours. It could be keeping an eye on financial transactions and accounts with a focus on whether the user is crossing the thresholds that were deduced during the risk assessment process. Some of the factors include sudden spikes in activities, unusual activities in other countries, etc... The intensity of monitoring usually depends on the risk management strategy. In the last decade, it is very clearly evident that a person’s online identity isn’t always what it looks to be. Data breaches, identity theft, phishing schemes, money laundering and other cyber-digital scams have created havoc on organizations. So KYC became the need of the hour for financial institutions.

Disruptive technologies for online identity verification are critical because KYC could potentially be a hurdle to the onboarding process of customers. Delayed waiting times frustrate the customers who always expect quick and easy procedures. Research by Signicat surveyed that close to 50% of banking customers in the European Continent haven’t signed up for fresh financial services as the process was too tedious. So, the challenge that every business organization faces is how to have a proper balance of KYC, fast decision making, and finally an efficient process that promises a positive experience for customers.

Types of Biometrics

Optical Fingerprint scanner: A specific area of the screen is embedded with an optical prism. When the finger is placed on a particular area, the optical image is stored in the device memory. In subsequent attempts, the new image is compared with the one stored in the device memory. If it exists then the authentication succeeds, else it fails.

Capacitive Fingerprint Scanner: When the finger comes in contact with the scanner area, the ridges ( bumped areas of the finger) alters the electric charge that was previously present on the scanner. So the charge depends on the ridges of each person and the structure of them is identified by the scanner and stored in the digital form.

Since this one is based on the capacitor array present in the scanner area, it cannot be spoofed by pictures as in Optical Scanners. Albeit, this does come with the drawback that it cannot work with wet fingers, since the ridges structure is distorted by the presence of moisture.

Ultrasonic Fingerprint Scanner: Ultrasonic fingerprint sensors use sound waves to store and verify a fingerprint. Ultrasonic beams are fired onto the reader surface and the waves that hit the ridges returns back earlier than the one that hit the grooves. Based on this renounced sound waves pattern a digital profile of the fingerprint is saved onto the device. When the fingerprint is placed on the scanner the pattern is matched with the ones already stored on the device. As of today, this is the most secure scanner available for public use.

Iris Scanners: The working principle of these types of scanners is invisible Infrared waves of light. The light is projected into the irises and picks up the unique pattern present inside the iris of the human eye. After scanning unnecessary features like eyelids and eyelashes are filtered out. A 512 bytes code (IRIS Code) is the output of the whole process that will be stored in the device. Samsung was one of the first manufacturers to use Iris biometrics on the smartphone.

Apple’s Face ID: It is another breakthrough in mobile biometrics. It is a combination of depth cameras, sensors, neural engines and IR blasters. It is said that the face id one of the most efficient and fool proof biometric available on any smartphone. The camera captures the face and a dot projector shoots invisible infrared dots onto the face and combing both a mathematical modal of the face is created by passing the data through a trained data model. All of this happens in real-time. Partly, this is possible with the high processing and compute capabilities of the mobile processors available today.

There are much more advanced biometric systems like DNA Fingerprint, Hand Geometry, Voice & Walking Pattern Detection which are out of the scope of this chapter.

Hashing algorithms and applications

A cryptographic hash function takes an input of any length and outputs a fixed-length bit array. For a given hash function the output is always the same irrespective of the input data length. The output is called hash value or hash or message digest.


As illustrated in Fig the input can be a file, string, byte array etc… and it can be of any size including an empty file or string. When it’s passed through a hash function the output is always of the same length and is deterministic. Various hashing algorithms have different fixed output lengths. SHA 256 algorithm output is 256 bits i.e 32 bytes, and it is encoded in hexadecimal format with 64 characters length. Popular MD5 hash digest algorithms outputs the hash of 128-bit length.

The striking feature of these algorithms is that all of them are one-way. It means we cannot get the input with available output. No matter how many times a piece of data is hashed the output will always be the same. And just with the help of hash, it is nearly impossible to recover the input data. This is also called Pre Image Resistance. It can also be elaborated as, For a known hash value h, it is computationally not feasible to find b in such a way that F(b) = h. Here F is the hashing function. Pictorial representation is given in the below figure.


But there is a catch here, though the hashing provides the pre-image resistance if the input is very small For eg:

  • A specific point of time in a day.
  • One word answers a question.

Because the length is two characters it’s easy to predict the input and takes very little time to find a b such that F(b) = h.

Hash functions also provide second image resistance. It states, if an input i1 and its corresponding hash digest are given, it should be very difficult to find out another input that will give the same digest. It is also called weak collision resistance. A hash algorithm in order to be one way and weak collision-resistant, its digest should be a minimum of 80 bits in length.


Next, we have a collision resistance property. It is computationally highly impossible to find a pair of inputs i1 and i2 in such a way that hash(i1) = hash(i2) holds true. A hash algorithm in order to be collision-resistant, usually its digest length should be a minimum of 128 bits in length.


To summarise, PreImageResistance means, it is difficult to find an input that outputs a certain hash.

SecondPreImageResistance means, it is difficult to find an input that gives the same hash as another certain input.

Collision Resistance means it is difficult to find two inputs that give the same hash.


  • Firstly we have file downloads, most of the sites provide checksum along with the download link. The user can check the file for its integrity by hashing the downloaded file along with the provided checksum.
  • CDN Networks serves a lot of files. So websites requesting the files from CDN are preloaded with the hash of the file required in respective tags. So in such cases, even if the CDN is compromised the malicious files can be prevented from execution.
  • Merkle Trees that are employed in blockchain are a form of hashing mechanisms.

Proposed Approach

Biometrics authentication or Biometrics based access plays a crucial role in high-security sites such as Archives where valuable ancient artifacts are stored, Banks, Military Bases, Prisons, Research centres, etc. There will be some areas in all of the places mentioned above that can only be accessed through the Biometrics of some esteemed personnel. In the current system, even though there will be a log recorded whenever someone tries to access those said areas, and also advanced security measures were taken to protect the logged data, there is still a high possibility that these logs can be manipulated. As a centralized entity, it still manages these.

The Biometrics-based access system is becoming common in many places, such as mobile phones, offices, Universities, etc. Furthermore, as part of the KYC procedures, the organizations are required to do the Biometric verification of their users. This section proposes an implementation of secure KYC and its audit transparently through Ethereum Blockchain. Through this method, the users can constantly audit when, where and for which company, organization, or use case they have submitted their Biometrics for verification. Similarly, companies or organizations can also audit their users’ KYC information securely and transparently.


Proposed Implementation

After evaluating and analyzing, the proposed approach lists the four entities considered in this process, as explained below.


  1. Organizations or companies that require the KYC of the users and need to do Biometric verification as part of the process. Biometric verification can be fingerprint scanning or iris recognition. For the implementation, the stated method considers fingerprint scanning as the required Biometric verification.
  2. Customer or User is an entity who participates in the KYC process and submits his/her Biometrics for verification as required by the Organization.
  3. Smart Contract is an entity in Ethereum Blockchain that handles the business logic and exposes methods and data for the Customer and Organization to interact.
  4. Government is an entity that supervises both Organization and the User and the Smart Contract's deployer. The Government will register each Organization and associate it with a unique public id such as PAN or TAN. In the same manner, each Customer will also be assigned a unique id like Aadhar ID.


When the Government enrols a Customer, the Customer's unique id and the hash of the Customer's fingerprint Scanned will be stored in the smart contract through Map data Structure.

Map Customers = new Map()
Customers.set(customer_unique_id, fingerprint_hash)


Likewise, an Organization will be recorded in the smart contract with the Organization's unique public id assigned by the Government, and the smart contract returns a unique organization id. This data is also stored using Map data structure.

Map Organizations = new Map()
Organizations.set(organization_public_id, sc_organization_id)

While registering with the smart contract, it will check whether the particular Customer or Organization is already mapped or not and will give the appropriate response.

if (Customers.hasKey(customer_unique_id)) return false;
if (Organizations.hasKey(organization_public_id)) return false;

When the Customer has submitted the fingerprint as part of the KYC for an Organization, the hash of the scanned fingerprint, the Customer's unique id, Organization public id, smart contract issued organization id and Latitude plus Longitude Coordinates along with a message will be sent to the smart contract for the verification of Biometric. The message parameter is optional, and an organization can assign to a string expressing some crucial information. Moreover, this is done through a method exposed by the smart contract. The method or function will verify the hash mapped in Customers with the fingerprint hash submitted. If the result is a success, then the smart contract issued organized id, accessible in the smart contract through Organization public id submitted, will be compared with the given one in the method. And if the outcome of the comparison is true, then a log will be created, and a return of true status will be sent. However, if verification or comparison fails in the process, then also a log will be created, and a return of false status will be sent. Whether the Biometric verification result is a success or a failure, a log will be generated with the given data.

The log data stored will have few additional data points along with input data. The log generated will have a serial number, a unique id associated with the current log. It will also have a call status that describes the success or failure of the call, an error code that helps understand why the verification of Biometric failed. For success, the error code can be assigned a value of 1. The smart contract lists all possible error values in an enum data type containing the error message and an error code assigned to it. The timestamp when the method is called is also stored in the log created. So a typical log recorded will look as given below.

Typical Log

Snoinput parameterstimestampcall_statuserror_code

The Serial number generated is mapped with both Customers_log_no and Organizations_log_no to access the recorded logs for an audit easily. Furthermore, the Serial number is pushed into the arrays mapped to the Customer's unique id and Organization's public id. This array map is initialized with an empty array when the Customer or Organization is registered in the smart contract.

Map Customers_log_no_arr = new Map<array>()
Map Organizations_log_no_arr = new Map<array>();
Map Customers_logs = new Map()
Map Organizations_logs = new Map()

Function logData() {
Customers_logs (Sno, “Sno;input_parameters;timestamp;call_status;error_code”)
Organizations_logs (Sno, “Sno;input_parameters;timestamp;call_status;error_code”)
return ;

Possible Error Messages and Codes

Error code Error Message

1 Success

001 Customer Unique Id not found or not registered.

002 Customer fingerprint hash verification failed.

010 Organization was not registered.

020 sc_organization id does not match with the input.


  1. Call Method Biometric_Verification() with input parameters customer_unique_id, fingerprint_hash, organization_public_id, sc_organization_id, lat, lng.
  2. Assign Serial No, timestamp
    1. Sno = unique_random_id
    2. timestamp = current_timestamp
  3. Declare error_code, call_status;
  4. Check for customer_unique_id in Customers Map
    1. IF Customers.hasKey(customer_uniuqe_id)
      1. goto next step
    2. ELSE
      1. Set error_code = 001
      2. Set call_status = false
      3. goto step 11
  5. Check for organization_public_id in Organizations Map.
    1. IF Organizations.hasKey(organization_public_id)
      1. goto next step
    2. ELSE
      1. Set error_code = 001
      2. Set call_status = false
      3. goto last step
  6. Verify the fingerprint hash submitted with the hash registered under customer_uniuqe_id.
    1. IF Customers.get(customer_uniuqe_id) === fingerprint_hash
      1. goto next step
    2. ELSE
      1. Set error_code = 002
      2. Set call_status = false
      3. goto step 11
  7. Compare the sc_organization_id submitted with assigned sc_organization_id for organization_public_id.
    1. IF Organizations.get(organization_public_id) === sc_organization_id
      1. goto next step
    2. ELSE
      1. Set error_code = 020
      2. Set call_status = false
      3. goto last step
  8. Set error_code = 1;
  9. Set call_status = true
  10. goto last step
  11. Logs Data and Return
    1. logData(Sno, ...input_parameters, timestamp, call_status, error_code)
    2. return call_status

This algorithm assures only Government registered Organizations can request Biometric verification and provides a secure Biometric verification process. The algorithm also enables secure and transparent access for the recorded logs.

As mentioned in an earlier section, anything that causes a change in the smart contract data or state will be considered a transaction. Each transaction must pay the execution fees. The fees can be borne by both Organization and Customer or only by Customer or Organization. The organization can offer the amount charged from the user in the form of digital coins or discounts on their platform. Even in the current system, some Organizations charge fees for KYC and give access to more features and benefits to the KYC verified customers.


To access the Biometric logs, a get function call will be made to the smart contract. The method will take the Customer's unique id or Organization's public id and an offset value. The offset value determines the starting index of the logs needed to be retrieved. For performance and efficiency, the smart contract can be set to retrieve 50 or 100 logs at a time. The below algorithm shows a series of steps in which the logs can be accessed for a Customer. Moreover, there is no need to pay any fees as this method does not cause any change of data or state in the smart contract.

Algorithm to get Logs

  1. call getBiometricLogs() with parameters customer_unique_id, offset
  2. Declare customer_log_sno_arr
  3. Initialize customer_logs with an empty array
    1. customer_logs = []
  4. Get Customer's array of log serial nos.
    1. Set customer_log_sno_arr = Customers_log_sno_arr.get(customer_unique_id)
  5. Check customer_arr_log for null
    1. IF customer_arr_log === null
      1. return customer_logs
    2. ELSE
      1. goto next step
  6. Loop customer_log_sno_arr( array of customer log serial no) starting at index offset and get the stored log using mapped Sno.
    1. Assign log = Customers_logs.get(Sno)
    2. customer_logs.push(log)
  7. return customer_logs

So, implementing the said approach assures that the registered Organizations can only do biometric access, and the data or the logs can never be changed or altered. This strategy also ensures that there will be no single point of failure as it resides in the Blockchain. Which also signifies that the data is distributed and decentralized. And finally, the Biometric verification logs can be accessed safely, securely, and transparently.

Conclusion and Future Scope

As elaborated in this chapter, the biometric system of authentication is one of the most secure authentications systems available. Albeit, it has a few flaws that can be exploited, nonetheless with the ground-breaking research in the field of IoT, Authentic Digital Identity, etc…, arriving at solutions to existing flaws is not much far away. Besides, even the blockchain system is evolving and becoming more and more efficient at a very sharp rate. Ethereum blockchain itself is the best example as it allowed programmable logic in a decentralized manner. The Ethereum London upgrade supplements the argument that the layman is highly concerned about decentralization and transparency. With such great improvements, applications like this will become much more prevalent and easily accessible to everyone.

Co Author 🧑🏻‍💻

This article is written in collaboration 🤝🏻 with Mani Chandra Teja

Share this