Ethereum Usecase: Identity Management (Take 2)

Identity verification is one of the hottest usecases for the blockchain. I already wrote on this topic few months ago with the idea of a fictive government binding hashed identity data to citizen’s ethereum address.

Recently, I ran into ShoCard, a mobile app which is able to locally store user’s identities (driver’s license, passport, tickets, credits cards, online accounts, …) on the mobile phone and seal this data by putting the hashes via the BlockCypher API on the blockchain. Furthermore, institutions, like banks for instance, can verify user’s identities and store this fact on blockchain too, effectively confirming that the sealed id record is correct.

I did the experiment of implementing ShoCard’s concept on the Ethereum blockchain. A very interesting point is that we only need one simple contract for the implementation of the concept. It simply binds a hash value to an address:

contract DataSeal {
address owner;
uint256 dataHash;
function DataSeal(uint256 _dataHash) {
owner = msg.sender;
dataHash = _dataHash;
}
}

First, for every user’s identity record of the form

idRecord = {idData_1, ..., idData_n, randomValue} 

we create in Ethereum a DataSeal instance storing idRecord‘s hash value.

idRecordSeal = new DataSeal(<idRecord hash>)

From now on, idRecord can not be modified without breaking idRecordSeal.

If we want to prove to X that our idRecord has been sealed by us, we will send to X the idRecordSeal address and idRecord signed with the private key of the Ethereum account used to instantiate idRecordSeal. Having this informaton, X can verify that idRecord matches the hash value in idRecordSeal contract and that the signature matches its owner.

So far, we have the proof that idRecord was created and sealed by us, but we have no proof yet that idRecord matches our real identity as documented on our id card. For instance, we could steal the id card from someone else and  seal it on the blockchain. In order to make the idRecord trustworthy, we need a trustworthy witness verifying our idRecord and committing the proof to the blockchain.

The most direct witness for this proof would be the public authority issuing the id cards to the citizens. The next best instance, could be a commonly accepted institution like the mailing company (see POSTIDENT solution of Deutsche Post AG) or a bank.

If the user has been successfully authenticated, the witness will produce

witnessRecord = {idRecordSeal, secretKey}

and create a new instance of the DataSeal contract with the hash of it:

witnessRecordSeal = new DataSeal(<witnessRecord hash>)

Finally the witness shares the following record with the user:

{witnessPublicAddress, witnessRecordSeal, secretKey}

Assuming that X is trusting W, and that we already were authenticated by W, we can pass to X

  1. the witness data {witnessPublicAddress, witnessRecordSeal, secretKey}
  2. our idRecord signed with the corresponding private key
  3. our idRecordSeal address

Now X, can check that idRecord hasn’t been modified, that we’re the owner of the record and it’s blockchain seal, and that we already were successfully authenticated by W. If X trusts W, then he doesn’t need any further verification of our identity and he can do business with us.

The concept is universal and it works with any kind of document. There are also usecases where no witness is needed at all. For instance I can seal my credit card data like this:

creditCardDataSeal = new DataSeal(<hashed credit card data>)

Every time I purchase something, I also sign my purchase with my Ethereum private key and the merchant can verify that credit card data is in my ownership. So even if someone steals my credit card, he won’t be able to purchase something with it, because the thief can not prove he’s the owner of the credit card.

Ethereum Usecase: Online Identitätsprüfung

Die Identitätsprüfung des Kunden bei Onlinegeschäften ist in der Regel ein Prozess, der mehrere Tage in Anspruch nimmt. Die Identifizierung wird zum großen Teil über das PostIdent Verfahren abgewickelt, das von dem Kunden verlangt zur Postfiliale zu fahren, um sich vor Ort identifizieren zu lassen. Die schnellste (mir bekannte) Onlineidentifizierungsmethode bietet idnow, das z.B. von Number26 bei der Kontoeröffnung benutzt wird. Dabei wird in einem Video-Chat die Identität des Kunden überprüft. Der Prozess nimmt etwa 5 Minuten in Anspruch und ist mit gängigen Smartphones durchführbar.

Was wäre aber, wenn man den Identitfikationsprozess noch schneller und mit noch weniger Intermediären durchführen könnte? Das Zauberwort heißt Ethereum.

Der große Anspruch von Ethereum ist es einen offen zugägnlichen Welt-Computer zu schaffen, der in der Lage ist die Programme, die er ausführt und den Laufzeitzustand, der sich aus der Ausführung dieser Programme ergibt, in eine Blockchain so zu verpacken, dass es keine Möglichkeit gibt die Programme oder deren Laufzeitzustand zu verfälschen.

Jeder Benutzer und jedes Programm in Ethereum haben eine oder mehrere öffentlich bekannte Adressen. Zusätzlich zu der öffentlichen Adresse hat jeder Benutzer einen privaten (geheimen) Schlüssel mit dem er Transaktionen in Ethereum signieren kann.

Welche Möglichkeiten würden sich ergeben, wenn die Behörde bei der Ausstellung eines neuen Personalausweises für alle Ausweisdaten (Name, Vorname, Geburtsdatum, Adresse, …), einen Hash-Wert berechnen und in einem öffentlich zugänglichen Identitätsverzeichnis an die Ethereum-Adresse des Kartenbesitzers binden würde?

In Ethereum kann man so ein Identitätsverzeichnis mit wenigen Codezeilen durch den folgenden Contract abbilden:

contract IdentityRegistry {
    address owner; // Der Besitzerer der Registry (die Behörde)
    string name;   // Der Name der Registry
    
    // Abbildung von Ethereum Adresse
    // zu dem Hash-Wert der Personalausweisdaten
    mapping(address => uint256) idHashes;  
    
    // der Konstruktor wird einmalig beim Anlegen des Contracts ausgeführt
    function IdentityRegistry(string _name) {
        owner = msg.sender;   // hier merken wir uns den Contract-Ersteller als Besitzer
        name = _name;         // den Namen der Registry setzen
    }
    
    // Liefert den Namen der Registry, verändert nicht den Zustand
    function getName() constant returns (string) {
        return name;
    }
    
    // Beschreibt wie der Hash-Wert für die Daten gebildet wird
    // Alle Informationen werden durch "/" getrennt, hintereinander abgelegt
    // Es wird SHA-1 Hashwert der Zeichenkette berechnet
    function getIdHashFormat() constant returns (string) {
        return "sha-1(NAME/GIVENNAMES/DATEOFBIRTH/PLACEOFBIRTH/NATIONALIY/ADDRESS1/ADDRESS2/ADDRESS3)";
    }
    
    // Diese Methode kann nur von dem Besitzer (Bürgeramt) aufgerufen werden.
    // das "throw" rollt die Transaktion zurück, wenn die Transaktion
    // nicht vom Besitzer der Registry (Bürgeramt) aufgerufen wurde.
    // Die Funktion bindet den Hash-Wert an die Ethereum Adresse des Ausweisbesitzers
    function registerIdHash(address who, uint256 hash) {
        if(owner != msg.sender) throw;
        idHashes[who] = hash;
    }
    
    // Wird vom Gegenüber (z.b. Bank) aufgerufen, um den Hash-Wert einer
    // Ethereum Adresse zu überprüfen
    function verifyIdentity(address who, uint256 hash)
    constant returns(bool) {
        return idHashes[who] == hash;
    }
    
    // Falls keine der oben definierten Methoden aufgerufen wurde,
    // sorgt diese Funktion, dass die Transaktion zurückgerollt wird.
    function() {
        throw;
    }
}

Beantrag beispielsweise Max Mustermann, geboren am 01.01.1990 aus Musterstrasse 12, Musterhausen den Ausweis, berechnet das Amt zunächst den Hash-Wert aus allen oben genannten Daten, z.B.:

sha1("MUSTERMANN/MAX/01.01.1990/MUSTERHAUSEN/DEUTSCH/MUSTERHAUSEN/MUSTERSTRASSE 12") = 1417400950720517943593210833135938663929334829119

Dieser Hash-Wert wird anschliessend vom Amt im Identitätsverzeichnis an Maxs öffentliche Ethereum-Adresse (0xDBEc37…) gebunden, z.B.:

identityRegistry.registerIdHash(
    0xDBEc371775c57f59fDA5BBa2c9FC8876968F34E3, 
    1417400950720517943593210833135938663929334829119)

Hierbei ist es wichtig anzumerken, dass aus dem Hash-Wert der Daten keine Rückschlüsse auf die Daten selbst gezogen werden können.

Möchte Max ein Konto bei der Musterbank eröffnen, könnte er nun über ein Onlineformular der Musterbank seine persönlichen Daten eingeben und zusätzlich seine öffentliche Ethereum-Adresse senden. Mit diesen Informationen kann die Musterbank bereits überprüfen, ob der Datensatz korrekt ist. Genauso wie das Bürgeramt, berechnet die Musterbank den Hash-Wert und vergleicht diesen mit dem Hash-Wert aus dem Identitätsverzeichnis des Bürgeramts. Z.B.:

bool res = identityRegistry.verifyIdentity(
    0xDBEc371775c57f59fDA5BBa2c9FC8876968F34E3,
    1417400950720517943593210833135938663929334829119)

Damit ist überprüft, ob der Datensatz valide ist, aber noch nicht ob Max auch der tatsächliche Absender der Information ist. Um auch das zu überprüfen, instantiiert die Musterbank einen weiteren Contract auf Ethereum und wartet darauf, dass Max mit seinem privaten (geheimen) Schlüssel die Bestätigungsmethode aus dem Contract aufruft und damit beweist, dass er tatsächlich der Besitzer des Ethereum Kontos mit der öffentlichen Adresse 0xDBEc37… ist. Der Contract sieht wie folgt aus:

contract IdentityConfirmation {
    address createdBy;    // Ersteller des Contracts (Musterbank)
    address who;          // Wer soll sich identifizieren (Max)
    bool confirmed;       // wurde die Identität bestätigt?
    
    // dieses Event wird verschickt,
    // wenn Max die Funktion "confirm" aufruft
    event IdentityConfirmed(address who);
    
    function IdentityConfirmation(address _who) {
        who = _who;
        createdBy = msg.sender;
        confirmed = false;
    }
    
    // wenn die Methode von Max aufgerufen wird, d.h.,
    // der Aufruf mit dem privaten Schlüssel von Max signiert wurde
    // bekommt die Musterbank die Bestätigung über
    // die erfolgreiche Authentifizierung
    function confirm() {
        if(who == msg.sender) {
            confirmed = true;
            IdentityConfirmed(msg.sender);    
            suicide(createdBy);
        }
    }
    
    function() {
        throw;
    }
}

Anbei der gesamte Vorgang zusammengefasst in einem Sequenzdiagramm:

Sequence Diagram

Weitere Überlegungen

Das vorgestellte Konzept ist eine grobe Skizze. Ein produktives System bräuchte noch weitere Feature wie z.B Aktualisierung / Sperrung / Entsperrung des Eintrags im Umzugsfall oder beim Verlust des privaten Schlüssels bzw. beim Ablauf des Ausweises.

Falls die Behörden nicht die Blockchain-Technologie adaptieren sollten, kann man sich auch folgende Alternativen vorstellen:

  • Es existiert ein Intermediär vergleichbar zu idnow, der den Aufbau des Identitätsverzeichnisses übernimmt und den Dienst gegen Gebühr anbietet.
  • Das Identitätsverzeichnis wird innerhalb des Konsortiums/Verbands aufgebaut und benutzt.

Schließlich wäre noch zu untersuchen, ob man mit dem privaten Ethereum Schlüssel außerhalb von Ethereum Daten signieren kann (public/private-key Verfahren). Das würde den zweiten Contract überflüssig machen.