search

Tribler / py-ipv8

Python implementation of Tribler's IPv8 p2p-networking layer
GNU Lesser General Public License v3.0
231 stars 47 forks source link

the made-in-Holland SSI toolkit #328

Closed synctext closed 4 years ago

synctext commented 6 years ago

Principle: deployment driven, continuous delivery. The Code Demo is the progress report.

Architectural and roadmap principles:

Sprint period: 1 week or 1 quarter?

Divide the work into parallel stream (however, never break compatibility) with different objectives:

Open Question: how to integrate and progress together? federation (one aspect, API alignment?) versus competition (overlap, full-stack)

Platform and programming language choice:

Avoid in first iterations:

franken01 commented 6 years ago

Ps, ikv nick szabo, kijk eens naar het haviltex arrest (naar de geest van of de regel van het contract)

----Origineel Bericht---- Van : notifications@github.com Datum : 12/10/2018 17:28 Aan : py-ipv8@noreply.github.com Cc : leonard.franken@hetnet.nl, assign@noreply.github.com Onderwerp : Re: [Tribler/py-ipv8] Way-of-Working: the made-in-Holland SSI (#328)

Assigned #328 to @franken01.

-- You are receiving this because you were assigned. Reply to this email directly or view it on GitHub: https://github.com/Tribler/py-ipv8/issues/328#event-1901042960

synctext commented 6 years ago

Divide the work into parallel stream (however, never break compatibility). Reason: currently no solution combines biometric authentication, maturity, and proven-in-deployment.

We seek to avoid fragmenting our efforts, ensure that lessons in any stream can be applied in others and parallel streams are architectural compatible. We need to define some commonality. This should be minimalistic, no undue strain on parallel innovations. Perhaps we reduce the constrains the most by only defining the minimal at the lower level in the architecture: the attestation. For instance: 

+--------+---------------------------------+----------------------+----------------+
| Number |           Description           |         Type         |  Size (bytes)  |
+--------+---------------------------------+----------------------+----------------+
|    0   |   Public Key in Binary Format   | Unsigned Short Array |        n       |
+--------+---------------------------------+----------------------+----------------+
|    1   | Global Time (Lamport Timestamp) |  Unsigned Long Long  |        8       |
+--------+---------------------------------+----------------------+----------------+
|    2   |       Attestation Metadata      |   Char Array (Raw)   |     33 + m     |
+--------+---------------------------------+----------------------+----------------+
|        |             *Total:*            |                      |   64 + n + m   |
+--------+---------------------------------+----------------------+----------------+

With zero-knowledge proof and multi-signature attestation looking, for instance, like this: attestation

synctext commented 6 years ago
synctext commented 5 years ago

Today it was decided that we will not try to find the killer app of an SSI or drive deployment. We will deploy and facilitate an open innovation ecosystem. This will include a fully functional open source SSI app on the Google Play store. Current draft name "regie op gegevens". Brainstorm of possible functionality in Toolbox:

Screenshots of current operational prototypes: trustchain_android__signature_requests_and_mailbox image image screenshot_20180123-115803 image image image image image image Photo donated to the Public Domain. No copyrights claimed. overlay_android_manual_test__jan2018

synctext commented 5 years ago

Key use-case for SSI is verifiable claims with legal certainty. Non verifiable information about verifiable reality is the default for birth certificates, bank notes, diplomas, etc.

The legal framework is eIDAS within the EU. eIDAS usage at level "high" requires possible usage of "photo or biometric identification evidence recognised by the Member State". This regulation has a soft-inclusion link to an ISO standard: " the definitions and concepts in ISO/IEC 29115 should be taken into the utmost account when establishing the specifications and procedures set out in this implementing act". International Standard ISO/IEC DIS 29115 , free download copy instead of paying for EU rules. This eIDAS from 2015 also builds upon the 2014 rules. The rules are broad and also cover "Binding between the electronic identification means of natural and legal persons".

ISO/IEC 29115 includes: Level of assurance 4 (LoA4), "very high". This ISO standard states that LoA4 must make "use of tamper-resistant hardware devices for the storage of all secret or private cryptographic keys". There is prior work on open source, open hardware tamper-resilient storage of credential. At Delft University we devised the first "patent-free PUF" device: Tribler/tribler#3064.

Other work includes "destroy-upon-opening", the costly ORWL device. Mostly positive review: "ORWL PC: The most secure home computer ever". image. Plus a critical review.

Systemic flaw in level "high" eIDAS is the lack of audit-ability, transparency and tampering detection. We propose level "maximum": with additional end-to-end security integrity guarantees. Level "maximum" provides a tamper-proof access and audit trail for all data access actions, system monitoring actions, system maintenance actions, and all other operations. At no point in time will data be exposed to unknown operations, unknown access by unknown software or unknown hardware. Every action and behavior of the system must be able to independently reproduced, verified and audited by every participant in the ecosystem.

synctext commented 5 years ago

Security of biometrics. Confirmed that fake face has been used for identity theft and multi-million Euro fraud. Fake French minister in a silicone mask who stole millions

andredekok commented 5 years ago

Ja dit is echt big business

Op do 20 jun. 2019 1:30 p.m. schreef Johan Pouwelse < notifications@github.com>:

Security of biometrics. Confirmed that fake face has been used for identity theft and multi-million Euro fraud. Fake French minister in a silicone mask who stole millions https://www.bbc.co.uk/news/world-europe-48510027

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/Tribler/py-ipv8/issues/328?email_source=notifications&email_token=AKQ5ER332PUNFFMPDS6STGTP3NS5BA5CNFSM4F3GWYBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYFEK5Q#issuecomment-503989622, or mute the thread https://github.com/notifications/unsubscribe-auth/AKQ5ER62ATBWRPPQKPR2CO3P3NS5BANCNFSM4F3GWYBA .

synctext commented 5 years ago

@davila9210 of Rabobank has done an interesting writeup on a self-sovereign identity demo, "universal ledger agent". image image

qstokkink commented 5 years ago

With the merge of #541, we will have the ability to import BRP data from the Nijmegen IRMA server.

anim_loginirma

We use:

  1. The usual DigiD login mechanism of Nijmegen (through https://services.nijmegen.nl/irma/issue).
  2. Read the QR code from the HTTPS session automatically and close the browser window (for mobile use, the user would have to manually scan the QR code).
  3. Communicate with the IRMA foundation keyshare server for a temporary account (this is necessary - otherwise the Nijmegen server will not sign).
  4. Get the "idemix" signature over our data from the Nijmegen server.
  5. Form the proof structure around our own data, deviating slightly from the original IRMA protocol. Our change consists of not storing the actual attribute values on the device. Instead, we only prove that (1) we have seen the attribute values and (2) know the secret value used for issuance.

The output of this enrollment wrapper can then be interpreted by our TrustChain identity and used for future proving of the exposed BRP data. Concretely you have the option of including any of the following 4 TrustChain attributes:

andredekok commented 5 years ago

Mooie prestatie

Op wo 31 jul. 2019 9:30 a.m. schreef Quinten Stokkink < notifications@github.com>:

With the merge of #541 https://github.com/Tribler/py-ipv8/pull/541, we will have the ability to import BRP data from the Nijmegen IRMA server.

[image: anim_loginirma] https://user-images.githubusercontent.com/3630389/62194981-44e94b80-b37b-11e9-82f2-f79d6342f180.gif

We use:

  1. The usual DigiD login mechanism of Nijmegen (through https://services.nijmegen.nl/irma/issue).
  2. Read the QR code from the HTTPS session automatically and close the browser window (for mobile use, the user would have to manually scan the QR code).
  3. Communicate with the IRMA foundation keyshare server for a temporary account (this is necessary - otherwise the Nijmegen server will not sign).
  4. Get the "idemix" signature over our data from the Nijmegen server.
  5. Form the proof structure around our own data, deviating slightly from the original IRMA protocol. Our change consists of not storing the actual attribute values on the device. Instead, we only prove that (1) we have seen the attribute values and (2) know the secret value used for issuance.

The output of this enrollment wrapper can then be interpreted by our TrustChain identity and used for future proving of the exposed BRP data. Concretely you have the option of including any of the following 4 TrustChain attributes:

  • bsn
  • ageLimits (older than 12, 16, 18, 21, 65)
  • personalData (initials, firstnames, prefix, familyname, surname, fullname, dateofbirth, gender, nationality)
  • address (street, houseNumber, zipcode, municipality, city)

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/Tribler/py-ipv8/issues/328?email_source=notifications&email_token=AKQ5ER4W5MFAR573OQUNSUDQCFERFA5CNFSM4F3GWYBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3GQEPY#issuecomment-516751935, or mute the thread https://github.com/notifications/unsubscribe-auth/AKQ5ER2L6AKKWSF4UYMAHF3QCFERFANCNFSM4F3GWYBA .

synctext commented 4 years ago

Related work: Trust over IP with solid group discussions.

synctext commented 4 years ago

With the field trail of SSI: https://github.com/Tribler/tribler/issues/4461 we've made another solid step forward. Closing this general issue.