Invention for Identity verification with blockchain technology

Invented by Mehran Shakeri, SAP SE

The SAP SE invention works as follows

Systems and methods that use blockchain technology to securely identify parties to a communication. This could be done by receiving a request for a communication connection between a first and second entity in a telephone environment, and then writing a first digital identification associated with the first entity at a first block in an immutable sequence of blocks. If the first entity is recognized as trusted, the method can be used. These blocks can be linked according to a cryptographic relationship. In response to the identification of the second entity as untrustworthy, a second digital identity may be attached to the second block.

Background for Identity verification with blockchain technology

Information security technologies are available to help protect data stored in storage systems. These technologies can also be used to protect the storage system’s vulnerabilities from attackers and prevent unauthorized access. An attacker can still gain access to protected information regardless of the effectiveness of security technology. This could be done by pretending to be an authority person, or establishing trust with an authorized user. An attacker might pretend to be a representative from a company or service provider to get sensitive information such as passwords or credit card numbers.

For the purposes of summary, certain aspects, benefits, and novel features are described herein. These advantages are not necessarily possible in every embodiment. The disclosed subject matter can be implemented or performed in a way that optimizes one advantage, group of advantages, or all the advantages suggested or taught herein.

Some implementations of the disclosed subject material provide systems and methods for using blockchain technology to securely identify parties to a communication. This could include receiving a request for a communication connection between a first and second entity in a telephone environment, and then writing a first digital identification associated with the first entity into a first block in an immutable sequence of blocks. In response to determining whether the first entity can be identified as a trusted entity, the method might also involve writing a first digital ID associated with the first entity onto a data block in an immutable series of blocks. These blocks can be associated according to a cryptographic relationship.

If the trustworthiness of the second entity is not established, a second digital identity may be attached to the second entity. A request may be made to the first entity to verify that it is trustworthy. Endorsing the second entity with a second data block is the first way for the first entity to verify trustworthiness. Endorsing could be digitally signing the second identity with the private key of first digital entity.

The accompanying drawings and description below detail one or more variants of the subject matter. The claims and the drawings will also reveal other features and benefits of the subject matter. However, the disclosed subject matter does not limit itself to any one embodiment.

The following contains detailed information to give a complete description of different embodiments. Some embodiments can be done without the specific details, or with variations in detail. Some features may be described in less detail than others to not obscure the other. It is not necessary to consider the importance or novelty of each element or feature in isolation.

Caller identification mechanisms might be available to determine the identity of a caller. These mechanisms can be implemented via a central system that is typically owned by a telecom company. It manages calls, controls user registration, assigns phone numbers, and provides caller identification features. These systems can be costly and require a lot of overhead to register authorized users. Inconveniently, the only way to verify the identity of a caller is through the central system, which may have very few authentication points. There are no external checks or balances.

Calling system 110 can communicate over a network 130 or a direct communication channel to access data or register data on blockchain system 140, or access services provided to them by a receiving systems 120. Block chain system 140 can be implemented on an independent computing platform or local to, remote from, or embedded in one of the computing systems 110, 120, depending on how it is implemented. To service one or more telephony requests or communications via network 130, a server system 122 can be installed on receiving system 120. Network 130 can be implemented via a wide-area or local network (e.g. the Internet).

Receiving and server systems 120 and 122 can be implemented in a distributed or centralized computing environment (e.g. cloud-based), as dedicated resources, or as virtual machines that share processing or storage resources. Execution, implementation, and instantiation software 124 or related features and components over server system 122 may also create a special purpose machine that provides remote client systems such as software 110 and software 112 with access to a variety data and services, including managing a secure communication environment that can be used to authenticate an unidentified person using calling system 110.

In accordance to one or more implementations the provided services by special purpose machine 124 may include providing a caller using software 112 or calling system 110 with a communication environment such as the one illustrated in FIG. 2. An unidentified party U can be identified as trustworthy by a series events that involve the communication of a trusted person T with a block-chain system 140. One example is that call receiver party E could trust U through the authentication of U’s identity based on endorsements by trusted parties T.

The verification and authentication process, according to one aspect, can be automated in secure environments such that processes involving identification and endorsement may be implemented using Asymmetric Cryptography, for instance. E’s identity may be represented as a public key. The endorsement could be in the form a digital signature that is applied to the public keys. Blockchain system 140 may manage data related to endorsements and identities. This may include a collection of digital records that are consecutively linked and verifiable and shared under the immutable ledger. Additional functionalities can be added to certain embodiments to verify signatures or prepare endorsements.

Blockchain system 140, in accordance with examples, may be implemented to create a growing list, sequence, or chain of records (i.e. a chain of blockchain blocks or blockchain). A cryptographic calculation may determine the relationship between the blocks of a chain. One block could include, for instance, a cryptographic hash, timestamp and transaction data (e.g. represented by a Merkle tree root haveh). If a set of checks is not met, the blockchain can be made more resilient (e.g., it will be resistant to modifications to data stored in blocks),

Blockchain system 140 could be an open, distributed ledger that can be used to record transactions between multiple parties in an efficient, verifiable, and permanent way. For example, a peer to peer network could manage the blockchain and adhere to a protocol for inter node communication and validation. If data is stored in a block, it may not be modified retroactively. This would require the consensus of 140 peers.

Accordingly, data stored on blockchain system 140 could be protected by distributing authorization mandates or policies to a large group of peers (e.g. computing system) with a high tolerance for failure or corruption. This decentralized approach to authentication and verification of data changes written to the blockchain system 140 may be advantageous because it would require consensus among a limited number of computing peers (e.g., majority) rather than a few authentication points in conventional centralized authentication mechanisms.

One example is blockchain system 140, which can be used to implement a decentralized data collection mechanism and data processing mechanism to enforce trust among users (e.g. receiving party E, unidentified person U) who communicate with one another. Blockchain system 140 can be used to store identity information and to provide that information (e.g. a public key), to a trusted authority to authenticate U’s identity. T may issue a certificate of authority to authenticate U. This certificate is stored in blockchain system 140. E may verify the digital signature using the public key T. Further details are provided herein.

Referring to FIGS. 2. and 3. Digital identity of T (e.g., an individual, trusted organization or entity) can be stored in the blockchain system 140 (S310). An encrypted public key may be used to identify digital identity of T. An asymmetric cryptographic algorithm may generate the encrypted public key. A public key infrastructure (PKI), which is a collection of policies and roles that allows for the creation, distribution, use, storage, management, and revocation of digital certificates, may be used in some implementations. The PKI can be used to associate public keys with the identities of entities (e.g. E, U, and T).

The registration and issuance certificates by certificate authorities (CA) may allow for the association of identities with public keys. The assurance and security requirements may dictate whether the association can be made by an automated method. To ensure valid and correct identification registrations, a registration authority (RA), may be used. They may also accept digital certificate requests and authenticate unidentified persons. FIG. 2 T could be the entity that fulfills the duties of RA, as an example.

U may be identified within each CA based on information about U, such as U’s public keys, in accordance with one or more of its aspects. To provide unique identifying information for U, a third-party validation authority (VA), may be used. Blockchain system 140, in the context of the verification infrastructure, may be used to store verified or verifiable identification information (e.g. public keys) for one or several unidentified parties.

Referring to FIGS. 2. and 3. For U to be endorsed (e.g. U’s public keys) by T, U’s digital identity (e.g. U’s digital identity) can be sent to the blockchain system 140 (S320). U can request T to endorse U’s digital identity (S330). As an example, U’s identity can be authenticated (or verified) by T. This will allow T to determine whether U is trustworthy (S340). T may use T’s private keys to sign U?s public key from records stored in Blockchain System 140. Then, T can verify or authenticate U’s identity by desiring to register the signed public key of U in Blockchain System 140 as a digital signature. If U’s identity has been endorsed by T, parties E that trust T may also trust U (S350). If blockchain 140 doesn’t include the public key U signed by T, authentication fails (S360).

In some cases, T’s private key might be stored in the blockchain system 140 before being used. E can then access the records in blockchain system 140 to obtain T’s secret key. E can verify U’s identity if U registers U?s public keys on the blockchain 140. If T’s private key is used for creating a digital signature of U?s publickey, E can decrypt that digital signature using T?s public secret to verify U?s public Key. One example is that T could be an organization. E could be an employee, and U may be an external entity. E can trust U if the organization, or a proxy acting for it, acts as a certificate authority. This is because U’s public keys are signed onto the blockchain system 140 by a trusted entity (e.g. the organization).

Click here to view the patent on Google Patents.