Online Store
Mar 13

DLT Access Control System

DLT Access Control System

Distributive Ledger Technology V2Distributive Ledger Technology V2 scaled

Abstract

  • The idea is to build new generation hardware for access control systems using digital signing contactless cards or next-generation NFC enabled mobile phones with a secure element and distributive ledger system. This system does not need a central server, backup systems, and IT personnel. Users will use contactless cards or mobile phones for accessing secure premises, opening doors.
  •  This kind of system can be used with existing standard PKI infrastructure, which will allow users to use the same cards provided by its government or certificate authority.

Technology Requirements
Users will use NFC cards or NFC enabled mobile phones with security elements, in following text NFC client, for interaction with NFC readers, make security authentication, and store data to distributed ledger system in following text DLS:

  • NFC clients need to have PKI infrastructure and secure elements. The secure element will have generated, unreadable, private keys, and public keys with the appropriate certificates.
  • NFC Access Control Reader needs to have PKI infrastructure also. Reader devices will have stored certificates to test the chain of trust of a card that is being used. Readers will be nodes in DLS as a part of a distributed database.
  • SAM Module is a security element and part of the reader device. It is used to check NFC client signatures and mostly important to digitally sign events that happened and prevent future altering of that block of data.
  • Distributed Ledger System. All our readers will have the possibility to communicate with each other. Every reader stores digitally signed blocks (RaderID, NFC Client ID, and actual time), chain it with the previous block, and digitally sign this change with a Consensus of 50%+1 readers.

How System Works

  • When you put an NFC client next to the reader, it reads the certificate from it. The certificate is further checked offline. With received certificate access control starts testing a chain of trust with the CA certificate and Root Certificate stored in the SAM Module. If a certificate test passes, the SAM module generates a true random data challenge and sends it back to an NFC client. NFC Clients digitally sign this random data and return it to the access control. SAM module checks the digital signature of received data with a public key provided in the card’s certificate. If this test passes, the access control device approves access to NFC Client.
    SAM module now digitally signs this event including time information and stores this information in device memory. This is how we form our event blocks.
  • Depending on the settings after a specific time, all new blocks are broadcasted to other devices as an updated proposal including the current device digital certificate. Other devices receive this information, check the validity of the certificate, then check the digital signature of blocks, and if it is valid they start broadcasting results. If more than 50% of results are correct then all devices-nodes accept this change. 
  • Setup transactions are provided for the purpose of setting access policy for each individual reader (access point) or any group of the readers. Setup transactions can be created using the setup transaction creator tool which can be a desktop or mobile application as well as a dedicated device. It is essential that the setup transaction is signed by the private key which resides in the NFC tag and its public key pair is included in the chain of trust maintained by the PKI (public key infrastructure) of the BlockChain access control system.

Technology that Digital Logic has today:

DL Signer Card:

/dl-signer-card-30m48cr/

Digital Signing Algorithms:

RSA, ECDSA
µFR Classic CS – NFC reader with SAM module
/nfc-rfid-reader-sdk/products/ufr-classic-cs/

Rich Digital Signing API:

/code/digital_signature_sdk

CA Certificate Store:

http://ca.d-logic.com/
The device that we need to develop in the product timeline:

  • Access Control Device with special firmware that can check certificates offline, authenticate card control devices like electronic door lock, alarms, etc. Access Control Device needs to have LAN access, wifi, and ethernet. The device needs to have DLT support.

The firmware that we need to develop in the product timeline:

  • Access Control Device.
  • NFC Reader firmware modifications.

Mobile Applications that we need to develop in the product timeline:

  • Android and iOS mobile application for authentication to our NFC Access Control System.

Software that we need to develop in the product timeline:

  • Setup transaction creator tool
  • Web reports

Timelines:

  • Access control hardware can be developed in 2 months.
  • Access control firmware can be developed in 4 months in parallel to access control hardware design.
  • After development, access control hardware and firmware need 3 months of testing in a real environment. In our company, we will cover 16 doors for the test.
  • Android and iOS apps can be developed in parallel with the rest of the processes in 2 months.
  • Web application with basic reports can be finished in 4 months.

Total development time from 8-12 months.