Interface specification between Self-Sovereign Identity and passport-level authentication #74
Comments
qstokkink
changed the title
EC25519 Key generationEC25519 key generation in IPv8 is handled by PythonFirst install the import libnacl.dual
key = libnacl.dual.DualSecret()
serialized = self.key.sk + self.key.seedThis key can then be loaded again as follows: import libnacl
import libnacl.dual
crypt, seed = serialized[:libnacl.crypto_box_SECRETKEYBYTES], \
serialized[libnacl.crypto_box_SECRETKEYBYTES :
libnacl.crypto_box_SECRETKEYBYTES + libnacl.crypto_sign_SEEDBYTES]
key = libnacl.dual.DualSecret(crypt, seed)Java (Android)For Android, the Note that for intercompatibility with Python we use the concatenation of the short (32-byte) key representation of the secret and signing key. Concretely the serialized key is then as follows: The dual key then has a total length of 64 bytes. |
IPv8 Attestation REST APIIPv8 has two major REST interfaces: one for attribute attestation and one for attribute verification. SetupIPv8 requires several third party libraries, make sure that these dependencies are satisfied as described in https://github.com/Tribler/py-ipv8/blob/master/README.md . Once you have the dependencies installed, create a new working directory. In this directory, copy the files from this gist: https://gist.github.com/qstokkink/5c9feb674f9d5e315872a1529f2da433 You should now have two files in your new working directory: Lastly in the working directory fetch the IPv8 repository, using git clone https://github.com/Tribler/py-ipv8.git pyipv8Or, you can download the code from https://github.com/Tribler/py-ipv8 and save it into a folder called The setup step is now complete. Note: this guide was made using commit b722384. As IPv8 is continuously receiving updates this guide may no longer be valid for newer commits. Running the exampleThe example is made for python main.pyIf you also have Python 3 installed you can explicitly run This will start the demo. This demo will create an attestation and attest to it using a 1024-bit key (mapped onto a 1048576-bit space), this is incredible overkill but it slows down the application enough that it is easy to follow. You should see something like this appear in your terminal window (this example is using DHT over the internet, finding others may take some time): What does the output meanThe output of running [HTTP-GET] http://localhost:8086/attestation?type=peers This REST call retrieves the other peers the user knows. For instance, in the group of user 1, 2 and 3: user 1 would report [1, 2]. The result is a (JSON) list of identifiers by which to reference these peers. They are actually the SHA-1 hashes of the public keys. [HTTP-POST] http://localhost:8086/attestation?attribute_name=QR&type=request&mid=5Oc2uB/9haXoQmrNlYSqNxDUppY%3D This REST call instructs IPv8 to perform a request for attestation to another peer with the identifier specified by mid for the attribute called QR. [HTTP-GET] http://localhost:8087/attestation?type=outstanding This REST call retrieves the requests for attestation which have been received by this user. Note that another peer has sent us one of these requests using the previously mentioned type=request call. The result is a (JSON) list of 2-tuples (formally a list of lists in JSON) consisting of the identifier of the request issuer and the requested attribute. This REST call should be called when the attester decides to attest to the value of the requester. The call is targeted to a specific peer identifier mid, for a specific attribute name attribute_name and some binary value attribute_value. [HTTP-GET] http://localhost:8086/attestation?type=attributes&mid=5Oc2uB/9haXoQmrNlYSqNxDUppY%3D The last REST call shows the output of a succesful attestation of an attribute. If an attribute shows up here it is added both to the blockchain and the local claim database. |
|
The above interface can also be captured in a set of Java interfaces, for clarity. This would lead to the following two files: AttestorInterface.java import java.util.List;
public interface AttestorInterface{
static class AttestationRequest{
private final String identifier;
private final String attributeName;
public AttestationRequest(String identifier, String attributeName){
this.identifier = identifier;
this.attributeName = attributeName;
}
public String getIdentifier(){
return this.identifier;
}
public String getAttributeName(){
return this.attributeName;
}
}
public List<AttestorInterface.AttestationRequest> getAttestationRequests();
public void sendAttestation(String identifier, String attributeName, String attributeValue);
}AttesteeInterface.java import java.util.List;
public interface AttesteeInterface{
static class Attribute{
private final String name;
private final String hash;
public Attribute(String name, String hash){
this.name = name;
this.hash = hash;
}
public String getName(){
return this.name;
}
public String getHash(){
return this.hash;
}
}
public List<String> getPeerIdentifiers();
public void requestAttestation(String identifier, String attributeName);
public List<AttesteeInterface.Attribute> getMyAttributes();
} |
|
The actual implementations of the attestor and attestee interfaces can be found here: These can be approached through the AttestationInterface class. The (current) master branch is now almost completely without any GUI. |
|
You can find an updated script with verification here. Output for the latter script will look something like this, you can see a $ python main.py
Initializing peers
[HTTP-GET] http://localhost:8086/attestation?type=peers
Known peers: ["Odl1gQkOFh/8pOVgA/qm/kT5BpY="]
[HTTP-GET] http://localhost:8086/attestation?type=attributes&mid=Odl1gQkOFh/8pOVgA/qm/kT5BpY=
[[u'QR', u'rkVwqwPOWiSG+Mw4pUKBbxOy2W0=']]
[HTTP-POST] http://localhost:8086/attestation?attribute_values=YmluYXJ5ZGF0YQ%3D%3D&type=verify&mid=Odl1gQkOFh/8pOVgA/qm/kT5BpY=&attribute_hash=rkVwqwPOWiSG%2BMw4pUKBbxOy2W0%3D
[HTTP-GET] http://localhost:8086/attestation?type=verification_output
Verifications: {u'rkVwqwPOWiSG+Mw4pUKBbxOy2W0=': [[u'YmluYXJ5ZGF0YQ==', 0.9999847412109375]]}Furthermore, you can find demo-specific documentation here: The full-on server script: |
qstokkink
added
the
priority: low
|
The final polished-up POC server code can be found on this Gist: This server acts as the attesting counterparty for apps. |
|
Fundamental question after discussion with @TimSpeelman about the integrity of the smartphone. We can assume the client is fully in the hands of the adversary. Can we really protect against deep-fakes for face recognition or Android emulator detectors? A simplistic binary blob will not protect you against tampering in the client. |
We specifically do not solve this in our client. We just provide the means for building identity. We depend upon third parties, with years of experience, to provide strong unfakeable biometric authentication. |
M.V.P. IDEMIA Interface
This document will entail the interface specifications for the onboarding procedure between the TU Delft IPv8 Blockchain solution (IPv8) and the IDEMIA biometry platform, from IPv8’s point of view. The Public Key based claim is the preferred solution from an ideological “the user is in control” perspective.
Context
This work defines the communication standard between 2 stand-alone apps. We provide an open standard for multiple biometric vendors, this is the key factor for large-scale adoption. As such and for security, the applications should be isolated as much as possible. Therefore any authentication app can talk to the IPv8 app. Alternative identity management apps such as Soverin or uPort can also use this neutral interface definition. This specification is specifically crafted to protect against man-in-the-middle attacks on the phone of a user. To deal with the isolation we need secure bi-directional authentication between apps. A simple REST api is used to communicate. For external communication QR-codes must be used.
There are two keypairs:
Onboarding claim: Public Key based
The onboarding claim has the following format in IPv8:
Use-case
At the municipality:
At the verifier (store/airport/business/etc.):
Required interface IDEMIA -> IPv8
Required interface IPv8 -> IDEMIA
Onboarding claim: IDEMIA identifier based
The onboarding claim has the following format in IPv8:
Use-case
At the municipality:
At the verifier (store/airport/business/etc.):
Required interface IPv8 -> IDEMIA
The text was updated successfully, but these errors were encountered: