Thesis: self-sovereign identity (SSI)

[synctext]

Current status:

• Full-time for 11 November onwards (first courses)
• ToDo: formulate Cum Laude scientific idea
• Re-usage of Superapp infrastructure with IPv8
• cooperation with ministry
• tamper-proof hardware: https://www.bunniestudios.com/blog/?p=5921
• Ask Stephan Wong faculty member for his Computer Engineering expertise?
• Idea: Build and trail a secure identity wallet with Passport and Euro contents
• Idea: use OpenTitan silicon root-of-trust
• idea: import quantum randomness through the open GPIO pins, latest science (too immature tech)
• Too hardware focused (e.g. Firmware flashing and OS compile debugging?
• Also involve the TBM people for the legally valid signature on behalf of a legal entity?
• Deadline: 1 Dec 2020 have a Problem Description in 1 page
• Deadline graduation: current rules Tuesday 31 Aug 2021 graduation (this has not changed)
• ToDo: Sicco check of cybersecurity assignment

[synctext]

Open crypto hardware wallet Trezor ColdCardWallet

[qstokkink]

If you're into crypto: another fun, open and very difficult problem in the space of Self-Sovereign Identities is that of credential revocation. You can get a taste of the problem space in these papers: paper1, paper2. You'll have to make sure revocation data propagates decentrally and that the revocation lists/sets are anonymized.

[synctext]

Are we interleaving requirement analysis and prototyping? Sounds like the good thing todo in this unexplored field. Hardware expertise level: no soldering iron, custom firmware-only. Discussed "Member States"+EC co-author objective.

EU digital ID scheme for online transactions across Europe

An EU digital ID scheme (EUid) will:
  - make it safer and easier to use online services anywhere in Europe
    (e.g. enrolling in a foreign university, opening a bank account, accessing public services)
  - give people more control over their personal data and privacy while respecting user anonymity.
Type of act:    Proposal for a regulation

[InvictusRMC]

Sicco's assignment request:

• Short assignment description (1-2 A4), including:
  • Research area
  • Knowledge gap
  • Research questions

[synctext]

Today is the first thesis day! Goal: determine direction in 3 weeks. Draft problem description. Firmware project or algorithm work? Related work on SSI: https://repository.tudelft.nl/islandora/object/uuid%3A200f1df0-adda-47a1-894c-baf54133035a plus obviously prior thesis from our Lab: https://repository.tudelft.nl/islandora/object/uuid%3Aaab1f3ff-da54-47f7-8998-847cb78322c8

[InvictusRMC]

Initial thesis ideas: Thesis_Ideas-2.pdf

WIP proposal: Thesis_Proposal.pdf

[synctext]

Currently have a few possible directions:

• International Deployment, European-ID the Commission will soon propose a secure European e-identity., speech by Head of European Commission, Ursula Herself
• Identity Theft (private key compromise) {related idea: open API for biometrics}
• "industrial-strength SSI implementation". Native Kotlin of IPv8 zero-knowledge proof and from-scratch interaction model / GUI design. Go beyond prior trail with real users and high-end publication (IEEE Magazine level). Possible link to biometrics, like this work from Twente startup

Understand prior work

• 2682 our SSI insight from 2016.

• https://github.com/Tribler/tribler/issues/4461#issuecomment-516336463 Speelman thesis with BSN crypto idea
• Nijmegen

[qstokkink]

If you plan on investigating revocation, you may also want to take note of this recent MSc thesis (from the crypto group) regarding a credential revocation scheme: http://resolver.tudelft.nl/uuid:871e17aa-a023-461f-88b1-80d83c21de92

[InvictusRMC]

I have written the following Thesis proposal with the Industry-Strength SSI in mind. I plan to submit this to Sicco.

Thesis_Proposal_V2.pdf

[synctext]

Nice! Seems ready for submission to Sicco. Minor comments:

realised, there is still much to gain.

Still much left to investigate.

(4) interoperability is another key challenge. This needs to be an open standard and have an open reference implementation. But somehow the Spanish wallet provider needs to be able to talk fluently to Polish verifiable claim providers. So, a German/Dutch international SSI trail would be a key milestone to achieve.

The main knowledge gap currently existing in the research area of SSI is the gap between the theoretical frameworks and the practicality of an implementation of these theoretical frameworks.

The main knowledge gap currently existing in the research area of SSI is the gap between the theoretical frameworks and the feasibility these theories. For instance, strict processing latency requirements on mobile devices. Governments would be reluctant to ask many of the European Union citizens to upgrade their phones. Governance requirements by nation-states, complexity, communication overhead, and fault-tolerance are other gaps.

we can derive the following sub-questions that can be used to substantiate an answer to this research question

Too generic. We know prior work, functional requirements and its limits. This deviates from what is really needed. As scientists we can ignore the eIDAS and GDPR legal constraints somewhat. The next stage in the maturing of the SSI theoretical concepts is to go beyond mock-up trails. We need to devise the most simple as possible SSI architecture which integrates the following required elements in a technology neutral manner:

• A wallet to store verifiable claims
• open API towards any commercial vendor of biometric authentication technology (DONE)
• open API towards any secure hardware token with challenge-response protocol to minimise side-channel leakage.
• Compatible with major deployed smartphone Operating Systems (Android,iPhone)
• No vendor lock-in, fully patent-free or from friendlies such as "Bundesdruckerei.
• Integrate a "trusted registry" of entities for which claims are accepted

[InvictusRMC]

Great feedback. I've updated the research questions and added a minor section on interoperability. The research questions could still use a little refinement, however, are sufficient for the assignment description submission in my opinion.

Thesis_Proposal.pdf

---

Update: Stjepan called it "more than enough".

[InvictusRMC]

Update:

• Got (almost) everything in order for BZK:
  • Will (most likely) be attending meeting next monday on their next plans for SSI.
  • Got access to their systems so I can freely communicate within BZK.
• Identified around 25 articles/whitepapers/theses to read:
  • Still have 19 to go through
• Finished Q1 courses (still had an oral & project to complete):
  • Still waiting on a single grade
  • However, Cum Laude average is secure

[synctext]

https://graz.pure.elsevier.com/en/publications/revocable-and-offline-verifiable-self-sovereign-identities

[InvictusRMC]

Had a great talk with @qstokkink. Got an introduction to the Python code and pointers to interesting authors and what literature to stay away from.

Also my literature list for now (will be growing after the pointers from Quinten):

CLICK ME

-  Stokkink, Q., Epema, D., & Pouwelse, J. (2020). A Truly Self-Sovereign Identity SystemarXiv preprint arXiv:2007.00415. -  Dong, C., Wang, Z., Chen, S., & Xiang, Y. (2020). BBM: A Blockchain-Based Model for Open Banking via Self-sovereign Identity. In International Conference on Blockchain (pp. 61–75). -  Stokkink, Q., & Pouwelse, J. (2018). Deployment of a blockchain-based self-sovereign identity. In 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData) (pp. 1336–1342). -  Zwitter, A., Gstrein, O., & Yap, E. (2020). Digital Identity and the Blockchain: Universal Identity Management and the Concept of the “Self-Sovereign” Individual Frontiers in Blockchain, 3. -  Van Bruggen, C.. (2020). Forward-looking consistency inAttribute-Based Credentials. -  Ferdous, M., Chowdhury, F., & Alassafi, M. (2019). In search of self-sovereign identity leveraging blockchain technology IEEE Access, 7, 103059–103079. -  Tobin, A., & Reed, D. (2016). The inevitable rise of self-sovereign identity The Sovrin Foundation, 29(2016). -  Cameron, K. (2005). The laws of identity Microsoft Corp, 5, 8–11. -  Allen, C.. (2016). The Path to Self-Sovereign Identity. -  Mühle, A., Grüner, A., Gayvoronskaya, T., & Meinel, C.. (2018). A survey on essential components of a self-sovereign identity. -  Zhou, T., Li, X., & Zhao, H. (2019). EverSSDI: Blockchain-based framework for verification, authorisation and recovery of self-sovereign identity using smart contractsInternational Journal of Computer Applications in Technology, 60(3), 281–295. -  Coelho, P., Z'uquete, A., & Gomes, H. (2018). Federation of Attribute Providers for User Self-Sovereign Identity Journal of Information Systems Engineering & Management, 3(4). -  Helmy, N.. (2020). Overview of Decentralized Identity Standards. -  Der, U., Jähnichen, S., & Sürmeli, J. (2017). Self-sovereign identity - opportunities and challenges for the digital revolutionar Xiv preprint arXiv:1712.01767. -  Wang, F., & De Filippi, P. (2020). Self-Sovereign Identity in a Globalized World: Credentials-Based Identity Systems as a Driver for Economic InclusionFrontiers in Blockchain, 2, 28. -  Othman, A., & Callahan, J. (2018). The Horcrux Protocol: A Method for Decentralized Biometric-based Self-sovereign Identity. In Proceedings of the International Joint Conference on Neural Networks. Institute of Electrical and Electronics Engineers Inc.. -  Speelman, T. (2020). Self-Sovereign Identity: Proving Power over Legal Entities. (Master Thesis, TU Delft). -  Baars, D. (2016). Towards self-sovereign identity using blockchain technology. (Master Thesis, UTwente) - Otte, P., de Vos, M., & Pouwelse, J. (2020). TrustChain: A Sybil-resistant scalable blockchain. Future Generation Computer Systems, 107, 770-780. - Abraham, A., Hörandner, F., Omolola, O., & Ramacher, S. (2019, December). Privacy-Preserving eID Derivation for Self-Sovereign Identity Systems. In International Conference on Information and Communications Security (pp. 307-323). Springer, Cham.

[InvictusRMC]

Some updates:

• Proposal cleared by both Sicco and Stjepan.
• Cybsec has a requirement that I have to attend some presentations (will be taken care of by me).
• Currently still reading papers, hope to be done by end of week. Currently summarizing them for my own convenience and have used relevent literature to draft a properties/requirements and problem statement/background section.
• Have some nifty ideas we can discuss tomorrow (regarding a revocation method that can be performed relatively offline - atleast, requires less interactivity).
• Updated literature list.
• Next steps:
  • Want to start implementing some code end of month.

Here is my very (!) rough draft. Thought I'd include it for completeness sake.

[synctext]

Lots of lost or stolen ID documents: 900 documents per day Note that we use Tor-like stack to offer proper privacy when using your digital identity at passport-grade level. Now we could also utilise our distributed technology for secure dynamic data exchange. Multiple times per day the government could publish revoked (lost/stolen) passports in their channel. A channel is a collection of signed data blobs, each blob is a swarm (sort of P2P RSS feed which can scale without bounds) (DDos protected, like attack on mijnoverheid.nl).

Quinten advise: just start; translated? : dive into Superapp stack with Kotlin IPv8

[InvictusRMC]

I have made a design on how the Hybrid-Revocation Model could work:

Also a design how it can be integrated in the regular verification flow:

[InvictusRMC]

Update

• Designed diagrams for workflows
• Finished reading for now (related work section is still WIP)
• Started porting the current SSI code of py-ipv8 to Kotlin (nearing 1000 LoC)
  • Primary focus:
  • Wallet Community (Self-imposed deadline: this month)
  • Secondary focus:
  • Identity Community (Self-imposed deadline: this month)
  • Plans after above tasks are completed:
  • Formalize own additions
  • Implement

[synctext]

• what are the field trail key requirements?
• what is the core API of the ISSIF, the eID of Europe?
  • present claim
  • verify claim
  • store claim
  • what is the feature outcome of January sprint?
• side-channel leakage, our Tor-like proxies are out of scope
• Current analysis: complexity of a 5-person field trail seem manageable
• Bachelor thesis by @kkostadinov99 student who did prior IPv8 Python on Android work
  • On 18 April when 4th quarter starts he will be provided an operational skeleton ID app
  • Ready for feature extension and testing on 25 people (possible bsc thesis focus)
• offline-first support as a key selling point of this msc thesis
  • makes the revocation framework shine
  • goes beyond all other related work (Microsoft,IBM, DID-fans in general)
• incremental: end of this month your first Superapp pull request and addition to the .APK
• Future superapp sprint ideas: existing code for wallet for Bitcoins, scan of QR code of friend in social network, and Digital Euro storage. Think about a generic API based on the offline-first verifiable claim paradigm.

[InvictusRMC]

Update:

• Continuing with engineering:
  • Attestation community almost done.
  • Wallet community should only be a few days work after that.
• Have everything running in an Android app in first week of February.
• Still need to have a meeting with André about ESSIF requirements.
• Within BZK: will be having communication with Tim, Pim, and Quinten for international SSI tracks from EU.

[synctext]

• Focus on must-have features of attestation and wallet. Integration is future sprints
  • Most work inside: https://github.com/Tribler/kotlin-ipv8 not superapp
  • Zero-knowledge proof in Kotlin, not a showstopper
• @tim-w credentials for "Trustchain Superapp" currently on Android Play Store, obtain live crash reports.
  • Pull request and take over Superapp project / repo?
• Split the "Basic Digital Identity" from the SSI service that operate above it. DBI is the low-level key creation, life-long core attestations, and nothing else.
• Q4 (April) usability bsc thesis study will start. Requires 18-yo and 72-yo citizens to work with your app!
• In future we want to be able to add social-relevant attestations
  • from this Covid E-Nose machine or blood sampling {tests without :skull: scraping}
  • Around Delft or Den Haag with BIG
  • integrate with BIG certificate of medical doctor, electronic signature
• cardinal objective: end-to-end software test with QR-code as input

[InvictusRMC]

Progress Update

• AttestationCommunity functioning
  • Squished a ton of bugs (Tip to self: Kotlin docs are not always correct)
  • Did a huge number of tests:
  • Core crypto classes now have tests (which also pass)
  • Manual more e2e-like testing
  • Skipped the irmaexact attestation algorithm --> is also not fully implemented in Py-IPv8
  • Still have to implement pengbaorange (not much work, builds on Bonehexact which is 100% implemented)
• In order to prove that AttestationCommunity is functioning:
  • Built a concept GUI app on Android which shows the request of attestation signing and the storage of verifiable claims
  • Built a concept CLI app which shows the verify claim flow (this will also end up in the Android app, ofcourse)
  • Code base is now in Kotlin-IPv8 (as the Superapp is a bit bloated, this has faster development time)
  • Ensured that the code is functioning in the Superapp, so should be a matter of ctrl+c ctrl+v to get it up and running
    • Unfortunate side effect: dependency "hell" breaks Blockchain Engineering "Luxery Communism" project --> will fix this later on.
• Unfortunately, a lot of time went into seting up the Android app (tip to self: JDK8 source cannot be compiled with JDK11)
  • Ofcourse, this is a one time thing
• My next steps (this week):
  • Finish IdentityCommunity
  • This community adds identity management
  • Complexity-wise, this code will take far less time
  • Goal: up and running this week
  • Add pengboarange algorithm: tomorrow
• Next steps (sprint):
  • Formalise offline-first design requirements
  • Android engineering time:
  • Implement IdentityCommunity in Android
  • QR support
  • Keep everything quite simple, focus on functionality (in Android)
• EBSI/ESSIF link

[synctext]

• 2 March 2021: possible real trail with EuroTokens, Digital Basic Identity and 18+ attestations.
• Making solid progress, towards MvP: "18+ icon" in superapp (e.g. 'scan 18+ authority')
• please keep everything running, MusicDAO has real users
• international trail, live usage, and international co-authors becoming realistic (EBSI/ESSIF)
• Political developments: "visiebrief digitale identiteit" by our secretary of state.

[InvictusRMC]

Progress update:

• Implemented Peng & Bao ZKP:
  • Verification and attestation fully working
• Fixed active verification for Boneh algorithm
• Implemented Trusted Authority Manager for IPv8
  • Stores the hash of the public key of authorities
  • Saved to database
• Extended attestation flow to incorporate signature:
  • Performed over metadata and serialized attestation
  • Allows for verification with Trusted Authorities
• Working on Android demo.

[InvictusRMC]

• Corona test app from the government. (https://github.com/minvws/nl-covid19-coronatester-ctcl-core)
• app-debug.zip
  • [x] TODO: Verify it does not break other installations

[synctext]

• We have a screen and 18+ icon! :
• Getting ready for 2 March or later trail with real digital :money_mouth_face: Euros and real age verification
• related work for broader perspective: scalability and private key storage are: "Why blockchain is not yet working"
• related work, Europe is forming real-time data portability if identity is solved, https://www.eff.org/deeplinks/2020/12/eus-digital-markets-act-there-lot-room-improvement

[synctext]

Related work by Evernym from Sovrin which uses central identity resolver architecture. Big 54MByte .APK on Android. "Connect.Me also includes an integration with the identity verification company Onfido." "Using Connect.Me, individuals can:

• Form private, pairwise cryptographic connections with other entities in the Sovrin ecosystem
• Gather digital credentials
• Present digital proofs of part or all of your credentials, privately and securely
• Store (and restore from) a backup of your digital wallet wherever you want
• Answer secure messages from any connection you have" All central IBM server infrastructure: "The core credential exchange technology that powers Connect.Me is being adopted on a global scale, via Hyperledger Indy, Hyperledger Ursa, and most recently, Hyperledger Aries." Looks good! :gem: :

Quick review..Nice and polished app, but totally unclear why I want this. Offers no compelling features. That is actually a general problem for any stand-alone wallet. 'Empty vessel problem'. You can't do anything without recognition by the state or convincing your friends to join. Bootstrapping without a killer usage is probably impossible :thinking:. Do we need a wallet as universal Android background service? (beyond CredentialsClient object) Credential store which can be controlled by user, if they dive into settings. Clearly this "empty vessel" approach is flawed for mass uptake. Background-wallet paradigm: a identity wallet is never exposed to the user, it is always bundled with the app for opening a bank account, app for buying a house or app for government services.

Full walk-through:

(click for more details)

[InvictusRMC]

The basic functionality for the demo is done! ssi-debug-apk-v0.1.zip The app can be used as follows:

The home screen

The home screen shows a QR code of your public key. This can be scanned using the scanner to add this key to your trusted authorities. Secondly, the screen shows your attestations (currently only the Peng & Bao attestation). You can press on any of the attestations to display the QR code. This looks as follows:

This QR code can also be scanned using the scanner.

The scanner

The scanner has two functionalities: it can scan attestations and public keys. When scanning an attestation, the user is prompted the following:

If the user chooses to verify, the attestation is verified locally through the signature of the signee.

The results in one of the following results:

When scanning a public key, the user is prompted by the following and can add a new trusted authority:

Users screen

On the users screen, attestations can be requested. When pressing on a valid peer, a prompt opens for an attribute name:

On the other client's end, the following prompt launched for entering a value (for now only numerical for the 18 plus check):

A Peng Bao attestation is subsequently send to the requesting party and added to his wallet. This can then be presented and scanned as explained prior.

[InvictusRMC]

Update:

APK (file size too big for direct upload): https://1drv.ms/u/s!AiR7NDwNQapx_BXQ6nHMspyUGo0e?e=J5TB1t

• App redesign + features:
  • U.I. has now more actions through FABs
  • QR code generation is faster
  • Ability to delete attestations & authorities
  • Ability to request attestation through QR code
  • User is prompted for intent when scanning public key QR code:
  • Add as authority
  • Request attestation from peer with said public key
• Kotlin-IPv8 merged in Master
• Super-app PR open
• Had contact with Wessel Blokzijl

[qstokkink]

Just had a quick glance at your source code: you may want to look into porting the CommunicationManager for a clean programmatic pseudonym management API, instead of accessing all of the primitives and database data directly. This class also includes rendezvous logic so you can find your counterparty on the Internet if more than 30 people join your community.

Side note: this is how we map user interactions to the CommunicationManager in Python.

[InvictusRMC]

Just had a quick glance at your source code: you may want to look into porting the CommunicationManager for a clean programmatic pseudonym management API, instead of accessing all of the primitives and database data directly. This class also includes rendezvous logic so you can find your counterparty on the Internet if more than 30 people join your community.

Side note: this is how we map user interactions to the CommunicationManager in Python.

Thanks for the pointers, @qstokkink! The communication manager was definitely on my TODO list, however, I made the decision that, merely, the WalletCommunity is sufficient for the upcoming field trial of ~15 people.

This class also includes rendezvous logic so you can find your counterparty on the Internet if more than 30 people join your community.

This I did not know and was something that already crossed my mind. This will definitely be necessary, I will port these. Thanks!

[InvictusRMC]

I just made a release for the 18 plus SSI app for the field trial this Thursday. Download link.

The dashboard only contains two apps:

Plus, I changed the icon background color for distinguishability:

[InvictusRMC]

Nifty functionality: got attestation requesting and signing (and also the QR local verification) fully functional "offline" through Bluetooth! It's a bit slower, due to lower MTU, and unstable, but it does work.

[InvictusRMC]

Progress update:

• Implemented CommunicationManager & IdentityCommunity:

  • As mentioned by Quinten, includes rendezvous logic in order to locate peers when the IdentityCommunity grows too large.
  • Works by creating new channels, which basically function as sub-communities. Special rendezvous tokens allows other peers to discover these new channels when interacting with a client within such a channel.

• Implementing REST API in Kotlin:

  • Similarly to the REST functionality in Python, this allows clients to interact with each other via the HTTP protocol.
  • Allows for an accessible interface as the functionality underneath becomes basically a black bocks obscured by the GET/POST requests. Should be finished this week.
  • RESP API simplifies ESSIF interoperability.
  • Example ESSIF:
    Example ESSIF ID

  {
  "@context": [
  "https://www.w3.org/2018/credentials/v1",
  "https://essif.europa.eu/schemas/vc/2019/v1",
  "https://essif.europa.eu/schemas/eidas/2019/v1"],
  "id": "did:ebsi-eth:00000001/credentials/1872",
  "type": ["VerifiableCredential", "EssifVerifiableID"],
  "issuer": "did:ebsi-eth:00000001",
  "issuanceDate": "2019-06-22T14:11:44Z",
  "credentialSubject": {
  "id": "did:ebsi-eth:00000002",
  "currentFamilyName": "Franz",
  "currentGivenName": "Hinterberger",
  "dateOfBirth": "1999-03-22T00:00:00Z",
  "placeOfBirth": "Salzburg, Austria"
  },
  "proof": [ {
  "type": "EcdsaSecp256k1Signature2019",
  "created": "2019-06-22T14:11:44Z",
  "proofPurpose": "assertionMethod",
  "verificationMethod": "did:ebsi-eth:00000001#key-1",
  "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
  sITJX1CxPCT8yAV-TvkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-Wuc"
  } ]
  }

  • REST API talks in JSON format --> perfect for making SSI on IPv8 compatible with ESSIF on EBSI.
  • Example IPv8 (from Python docs):
    Example IPv8

  $ curl http://localhost:14411/identity/pseudonym1/outstanding/verifications
  {"requests": [{"peer": "TGliTmFDTFBLOg/rrouc7qXT1ZKxHFvzxb4IVRYDPdbN4n7eFFuaT385YNW4aoh3Mruv+hSjbssLYmps+jlh9rb250LYD7gEH20=", "attribute_name": "my_attribute"}
  $ curl -X PUT -H "Content-Type: application/json" -d '{"name":"my_attribute"}' "http://localhost:14411/identity/pseudonym1/allow/TGliTmFDTFBLOg%2Frrouc7qXT1ZKxHFvzxb4IVRYDPdbN4n7eFFuaT385YNW4aoh3Mruv%2BhSjbssLYmps%2Bjlh9rb250LYD7gEH20%3D"
  {"success": true}        

• Will be working on SSI blogpost for RvIG: general SSI information, albeit can be useful as practice for thesis.

[synctext]

Keeping track of developments

• SSI Toolbox for NL with IRMA integration (Pim Otte, Tim Speelman)
• European SSI has open documentation
• International trail, industry-grade (secondary issues: loss recovery, revocation, theft locking, standardisation :3rd_place_medal:)
• Dream goal: co-authors from Sweden (?security grounded in law of physics, PUF?) and German with NL 8-page paper
• End of our walled garden with high-efficiency (Implementation REST API in Kotlin).
• ToDo: Simple revocation, subscribe to datadump of million of revoked EU IDs, Libtorrent for scale, warning about .mdblob complexitiy ?
• ToDo2: March, April, May, June? rough roadmap

[qstokkink]

In case you care about IRMA: I recently fixed the script that pulls BRP attributes from the Nijmegen IRMA server. I'm not sure if I'd recommend supporting this, as you need to go through a DigiD portal.. but it works again.

[InvictusRMC]

Progress update:

• Implemented greedy revocation:
  • New GossipCommunity
  • Peers send each other periodically PreviewPayloads:
  • Contain key-value pairs of known public key hashes and latest revocation versions
  • Receiving peers can send back an UpdateRequestPayload:
  • UpdateRequestPayloads: Contain key-value pairs of requested updates and the lowest version the requesting peer knows.
  • Receiving peer sends back UpdateChunkPayloads:
  • UpdateChunkPayloads:
  • The revocations belonging to each key-value pair of public key hash and version are fragmented into a stream of UDP packets and reconstructed at the requesting client's end
  • The stream of UDP packets thus belong to a single version and public key hash --> minimizes impact in case of packet loss (firstly implemented by sending all updates in a single stream --> 100% loss in case 1 packet was lost)
  • The availability issue:
  • Most favorably, we want revocations to be known all across the network
  • This led to the design choice of making all peers propagate all revoked signatures
  • Peers can only verify signatures of the revocations in case the public key is known to them:
    • Public key is not sent along (aids privacy + reduces network usage)
  • Peers thus insert revocations without checking in case the public key belonging to the hash is not known to them, else they firstly validate the signature.
  • Possible issue: spammers can insert random revocations into clients databases, solutions:
    • Clients block spammers (make the issue resolve itself)
    • Send along public keys to verify revocations (does not really solve the issue as we do not necessarily know to whom the public key belongs, just makes it a bit harder as a spammer requires multiple keys)
    • Do not insert revocations of unknown authorities (leads to lower availability, although, greatly reduces storage overhead and network usage).
  • The "greediness":
  • Clients request all versions they do not know from possibly multiple peers at once:
    • Updates it already learned in the time between requesting and receiving are ignored
  • The rough edges of this design:
  • Concurrency constraint: updates are ignored in case the previous version is not known: fixed in eventually consistent fashion: i.e., the next PreviewPayload will give the client another chance at gaining the packages in order. This choice was made as otherwise clients have to request missing versions instead of simply sending their last known versions.
  • In case a client requests version x, however, the other party meanwhile learned of versions [x+1, x+y] , the other party also sends these along as it has no true notion of the requested versions (requesting party only sends their lowest known version along). The receiving party now drops any of the versions newer than x as it did not request these --> countermeasure against possible misuse of sending more data than a client requested.

[synctext]

• What is the claim to novelty? (international trail, scalable revocation or both? "Proven scalable identity revocation")
  • Deadline for trail: make contact in April or too late
• Stable code for 8 April presentation on App Store
• Bulk data sharing using Libtorrent works in MusicDAO
• State-of-the-art? Revocation, IDEMIX https://doi.org/10.1109/EuroSP.2017.13
• ToDo: scientific thesis text with design of revocation?

Month	Task
April	Core research and draft text article/thesis
May	Scientific results beyond state-of-the-art
June	Polish thesis + article
July	Done

Every time an App or website asks us to create a new digital identity or to easily log
on via a big platform, we have no idea what happens to our data in reality.
That is why the Commission will soon propose a secure European e-identity. 
One that we trust and that any citizen can use anywhere in Europe to do anything from
paying your taxes to renting a bicycle. A technology where we can control ourselves what
data and how data is used.
                               - State of the Union Address by President von der Leyen

https://ec.europa.eu/commission/presscorner/detail/en/SPEECH_20_1655

[InvictusRMC]

Another paper by Sovrin on revocation: https://sovrin.org/wp-content/uploads/AnonCred-RWC.pdf

[InvictusRMC]

Just had an idea for the secondary issue of loss recovery:

• Main issue: private key recovery --> Use Shamir's Secret Sharing with trusted persons (e.g. x close friends or even your local government). Next, we can use this private key recovery mechanism in two ways:
  1. First method:
     • (1) Periodically encrypt serialized wallet contents with private key as encryption key and (2) store on an external storage solution (e.g. some cloud storage provider).
     • Use recovered private key to decrypt and restore encrypted wallet backup.
     • (Wallet is stored encrypted as this gives some guarantees on confidentiality and integrity).
  2. Second method:
     • (1) Use recovered private key in challenge mechanism to prove ownership over attestations and (2) make each authority resend the attestations (trivial solution).

[qstokkink]

You could check out the results of #3245 and #3246. Both groups used Shamir shares for recovery.

[synctext]

WEF authors to contact: https://www.weforum.org/agenda/2021/04/trust-is-fraying-how-trust-anchors-could-help-gtgs/

[InvictusRMC]

Update Progress

• Code base:

  • PRs open for 18 days
  • Extensive (manual) e2e testing for CommunicationManager:
  • Implements rendezvous logic:
    • Allows peers to create a subcommunity (second instance of a Community) on runtime
    • --> No more visibility issues
    • Works via a special code a client can generate themselves and distribute via other means.

• Revocation:

  • Not developed further since last meeting, but
  • Khovratovich & Jason (2017) state three methodologies for revocation specifically for SSI:
    1. Signature Lists (Nakanishi et al., 2009). Paper on revoking keys, where keys of non-revoked members are fetched.
    2. Cryptographic accumulators (Camenisch et al., 2009). Hashes all valid credentials to a single (accumulated) value. A client uses a witness to prove that the accumulator comprises their identity. Solution requires interactivity with issuer and witnesses.
    3. Forward revocation lists (Verheul, 2016). Issuer generates revocation entries, client present non-revocation proof. A verifier tests this proof against every entry.

• Possible novelty in revocation:

  • Distributed: most (all?) of the solutions do not use other clients as relay stations for revoked signatures. Gossip can be a novelty.
  • Usage of bloom filters for speed optimization. My current solution uses a revocation list of the hashes of revoked signatures. Bloom filters are extremely efficient datastructures which help us say with certainty that a signature is not revoked. In case the bloom filter reports that there might be a match, then we can perform the O(n) search. This O(n) search can also be optimized by using a smart search algorithm (e.g Heapsort worst case O(n log n).
  • There are some papers on bloom filters and revocation. (Did not yet dive in):
  • (https://ieeexplore.ieee.org/abstract/document/7192615)
  • (https://ieeexplore.ieee.org/abstract/document/5719271)
  • (https://ieeexplore.ieee.org/abstract/document/8288287)

• Article:

  • Started working on article. ~(4-5 pages now, possibly too in-depth, but fragments can be used for the thesis itself)
  • What results to discuss in article?
  • Article_Draft_19-04-21.pdf

• For bonus, I've written the first version of the SSI blog:

  • DRAFT_SSI_Blog_10_4_2021.pdf

[synctext]

• Science in thesis? ?Distributed and practical revocation systems for passport-grade identity.. (non-interactive, QR-code only, bulk-broadcast, offline relay gossip, challenged network, IoT low-bandwidth, etc.)
• revoked passport ID, side-channel leakage of sensitive information? Full public info?
• Practical:
  • runtime beyond Big O notation
  • speed improvement with and without Bloom filters
  • storage requirements in real MBytes for realistic country-wide deployment scenarios
  • performance evaluation on numerous real Android devices?
• Related work - credentials and web-of-trust: Trust over IP foundation
  • All related work is central, see Idemix, Sovrin, etc.
• ToDo: write design?
• Thesis what makes it more then "YARC: Yet-Another-Revocation Scheme"?
  • Realistic trail and use-case - the real 18+ trail and photo
  • Realistic Von Der Leyen trail: QR-code to login to platform, without revealing anything

[InvictusRMC]

Progress update:

• App (new logic implemented):
  • [x] Ability to set special rendezvous token
  • [x] Ability to request attestation whilst locating the other peer through rendezvous token
  • [x] Requests screen in order answer to attestation and verification requests
  • [x] Ability to sign and verify small (!) images --> can be used for ID pictures, idea to write something about this in thesis/article
  • [x] UI component to see verification output
  • [x] UI component to revoke signatures
• Writing:
  • Started writing on design of revocation, becoming more clear that fully distributed (offline usable) revocation has not been done yet
• SSI design:
  • Working on attestation presentation logic for "Von Der Leyen" trail
  • Significantly improved signature scheme for offline validation:
    • Value is only sent once on AttestationCommunity-level (sent back through the attestation chunk payloads)
    • Incorporated into raw byte stream which is encrypted --> confidentiality should be enforced
    • Value is no longer present in AttestationCommunity-level metadata, only in IdentityCommunity-level, meaning that the value cannot be read out on verification-time, and, thus, does not necessarily has to be disclosed when sending the raw attestation (i.e., the AttestationCommunity attestation).
    • Both parties reconstruct the metadata containing the value, as the value itself is stored in the wallet
    • Signatures are validated (offline) using the chain of signatures on IdentityCommunity level, hence, we reuse IdentityCommunity-level signatures, as opposed to creating new ones.
  • Significantly improved QR code presentation (for offline attestation verification):
    • Less vulnerable to replay attack --> timestamped challenge is used which is only valid for an amount decided upon by the requested peer.
    • Ability to split large attestation into two QR codes
    • QR generation way quicker
• BZK:
  • Next week presentation on SSI & my thesis
  • SSI blog almost finished
• TU:
  • Helped Martijn with BSc students

Self reflection:

• Not too happy with progress over past two weeks
• App development can be sluggish and feels not too relevant for endgoal at times
• Need to focus more on writing ~10 pages thesis, ~4 pages article. Feel I need to work a lot more on this.

Proposed roadmap (next two weeks):

• [x] Be done with app this week (including "Von Der Leyen" presentation logic)
• [ ] Revocation mechanism "beyond state of art" analysis/comparison
  • Have this written down in both article and thesis

[synctext]

• Why is your thesis work novel? Design of revocation algorithm. Unique approach: as decentral as possible.
• more scientific terms, not secondary something. Secure communication primitive
• How different is your unique code from standard TLS?
• A nounce is not a token
• The Big Picture: decentral economy with master students
• Can your work be presented at upcoming European Cybersecurity Agency event?
  • https://www.enisa.europa.eu/events#b_start=0
  • scan QR code that does something. However: it always needs to work. Paper passport robustness.
• ToDo: start your scientific article. Starting point: design
• determine upper bound of tps, single gateway. no maximum tps determined yet of gateway (no block validation, just 1 transaction block transfer)

[InvictusRMC]

"Von Der Leyen"-Trial (Although name is revealed, 18 plus also works)

https://user-images.githubusercontent.com/22516119/117710216-28c24180-b1d2-11eb-8554-5eec57ab38e6.mp4

[InvictusRMC]

Progress

• Finished app:
  • Revocation logic implemented and functional
  • Presentation logic & answers to request for specific attributes ("Von Der Leyen"-Trial, see video in previous comment)
• Revocation functional:
  • Did analysis on convergence time (written down in Thesis)
  • Did analysis on impact of Bloom filters (written down in Article, should probably be moved to Thesis as a whole)
  • Working on runtime analysis graphs (bottleneck: only max ~10 clients before CPU is capped)
• Writing:
  • Have written more in-depth about design:
  • Explained protocol in terms of attestation signing and verification
  • Explained revocation
  • Extensive convergence time analysis
• Next steps:
  • Finish article this week/begin next week
  • Continue writing thesis
  • Investigate usage of accumulators versus hashes for Revocation
• General remarks:
  • Presentation on my Thesis at BZK on the 7th
  • Two PRs open
  • More happy with progress, but still require a lot of work on writing.
  • Need to plan in Thesis defence.

DRAFT_Thesis_27-05-2021.pdf DRAFT_Article_27-05-2021.pdf

[synctext]

• How does your identity framework differ from FIDO2, OpenID, SAML? Demo?
• mental note: always keep private keys external from untrusted phones from untrusted supply chain and untrusted OS. 1st-phase as external crypto key storage using microSDcard; easy interface into unsecure Android devices. Air-gapped challenge response via MicroSD. See supplier and here
• 2005 was the year that SSI was defined, possibly this gets too little credit for the depth it has.
• Hype your novelty: Zero-interaction, zero-centrality, failure-proof revocation architecture (+ requirements from tamper-proof storage layer & gossip relays; censorship-free message forwarding; single honest node eventual discovery?)
• Theoretical performance bound for revocations?
• Table of known revocation algorithms with [REF], YEAR, SSI-compatible? plus 1-line description.
• Cross-border revocation trail? (Student writes testing plan :-) {invites, task description, revoke, measure, graph, storyline} {revoking test floods, 4 test scenario buttons}

[InvictusRMC]

With thanks to Andre:

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM%3A2021%3A281%3AFIN&qid=1622704576563