blockchain for health

[synctext]

The outcome of our first brainstorm session within the medical domain: Disclaimer: this is just a starting point for discussion and discover flaws in our simplistic thinking.

The goal is to see if we can formulate a realistic field trial as a very light-weight attempt to learn-by-doing. The above system architecture depicts the most simple use-case involving 1 person from each stakeholder. 80% of the above technology pieces have already been created in other projects by the Tribler team. But never used in this context. Integration and applying domain expertise is expected to take the majority of time.

This trial brings key innovations to the healtcare sector:

• self-sovereign identities and digital signatures
• personal medical records
• straight-through processing of electronic business transactions

The key enabling technology is the blockchain, which makes the trust of the government portable (e.g. legally-valid electronic signatures). Many economic sectors have already transitioned beyond batch processing and week-long delays within backoffices with manual checks of paper-based information. This trial consists of digital trusted information flows between strongly authenticated parties. By using encrypted information flows on our scalable blockchain datastructure we achieve tamper-proof record keeping. For authentication we aim to integrate in due time with eIDAS high compliant mechanisms. We have an operational prototype as an alternative for the UZI-pas, using our patent-free software-based PUF; using physics as a foundation for security. Where possible we should use the message and protocol specifications approach of the MedMij organisation (see in Dutch only). Their system architecture is based technologies like Oauth and TLS (central-server based). This will cause cause problems with a self-sovereign approach. For instance De PKI-O-certificaten dienen aangeschaft te worden bij een vertrouwensdienstverlener, zoals Logius.

Our work is based on the pioneering work of HIE of one. This volunteer-driven (e.g. @shihjay2) initiative realized the state-of-the-art in the field by connecting uport, OpenID, HIE authorisation server, and a electronic health record system. Their mobile app can login to several dozen hospitals and retrieve medical records. whitepaper Our approach is not as sexy as MIT proposals. We propose to first apply approaches with established effectiveness discovered 20-ish years ago, before trying experimental and unproven technology. Whitepapers from MIT (not peer reviewed scientific publications) propose to solve the data, privacy, and security in healthcare using multiparty crypto tricks. We have some experience there. In prior work from we fully implemented and evaluated the efficiency of additively homomorphic encryption, namely the Paillier cryptosystem. This stuff is not yet ready to leave the lab.

As an initial step to obtain participation and feedback, the 4 students of TUDelft will implement a first demo in coming weeks. This demo will measure the willingness of various parties to explore options and conduct a field trial. Background information: Prof.dr. Wouter van Solinge has done pioneering work at UMC Utrecht with personal eHealth apps (in dutch only).

We have initial participation of RvIG, the identity provider in our Kingdom.

[synctext]

First concrete step:

• possible goal: attestation of birth (official doctor attestation, claim of parent and doctor; genesis baby block)
• add support for attestations in Trustchain app
• find libs such as https://github.com/scipr-lab/libsnark and https://github.com/bbuenz/BulletProofLib
• how to handle UX of well known trusted public keys of municipalities (QR scan? +add to trusted keys address book)
• integrate BSN claim and government certificate proof
• possible addition: Dutch passport NFC scan
• possible addition: OpenFace based authentication and datasets

[synctext]

Clear roadmap for coming 2 weeks:

• make the trustchain app maintainable - big refactor to make it long-term viable
• Core features; re-usable building blocks for any blockchain app:
  • trustchain: scalable blockchain on Android
  • android-to-android overlay: no PC needed (carrier-grade NAT testbed? 10GB sim?)
  • IPv8 attestations: zero-knowledge proofs, claims and attestations using BulletProofLib
  • scan of government-issued identity proofs using NFC
  • features as a library that works, code coverage, docs and solid unit tests
• update Trustchain on App Store, continuous integration, just put it live...
• Future possibilities:
  • money: bitcoin wallet, banks, paypal, etc.
  • photo and document scans with electronic signature
  • decentral market, trade anything
  • biometrics Marvel - Face Recognition With Android & OpenCV and our own open source fingerprint lib Fingerblox

[shihjay2]

Thanks for the mention to the HIE of One. Your discussion here is very interesting to us; I'm including Adrian Gropper who works with me on the HIE of One project. We are both happy to assist and to also learn from your discussions how we can leverage self-sovereign identity, blockchain to our goals of improving health information technology, security, and privacy.

[qstokkink]

https://github.com/qstokkink/ipv8-android-app/blob/master/app/src/main/java/org/ipv8/android/restapi/json/AttestationRESTInterface.java

[synctext]

Progress reporting:

• refactor & rewrite protocol buffers now used extensively (prior path SQLite storage, then ProtoBuf, into appToApp, then BEncode, finally UDP sockets)
  • single .proto file not only trustchain, but also appToApp shared between them.

    message TrustChainBlock {
    bytes public_key = 1;
    int32 sequence_number = 2;
    bytes link_public_key = 3;
    int32 link_sequence_number = 4;
    bytes previous_hash = 5;
    bytes signature = 6;
    Transaction transaction = 7;
    google.protobuf.Timestamp insert_time = 8;

• please add transaction_type inside trustchain for role, claim, and other record types.
• important observation: using QR codes gives the self-sovereign citizen the feeling of control over the information flow, wireless communication is too abstract. Same reason that government officials with a "control reflex" prefer QR codes above wireless. (read it, you can steal it; problem of QR codes)
• Bulletprooflib works ! But just Android 8.0 and higher. As we seen yesterday, the Stanford algorithms have acceptable performance for 4-bits, but not for real-world cases. Thus we need Quinten zero-knowledge Python REST API matters probably.
• currently attestations is 1978 technology: signed with private key certificates.
• IPv8 attestations can be used as Python backend, simply send/receive binary claim blobs and True/False tests.
• Android beam is difficult to get working flawlessly, screen lock/unlock is a work-around to discover the Beam partner phone!
• Next sprint tasks:
  • refactor and flawless app-to-app
  • IPv8 attestations
  • app already has import/export tokens/funds (possibly use QR-based attestations)
  • scan of government papers
  • Update Google Play app, not backwards compatible.

[synctext]

Progress to date:

• Trustchain + overlay: .proto Single Protocol Buffer message definition
• 8548 lines of generated code by Protocol Buffers serialising and de-serialising each message into a byte array for UDP messaging.
• TUDelft implementation by @qstokkink of zero-knowledge proof.
• No out-of-sleep feature on Android. dead overlay.
• update on_packet() every second a screen refresh and update message-timeout values on screen.
• design and implement a fault-resilient overlay. make flawless.
  • documented algorithm
  • Add last send message + got last response message
• seen passport scan NFC work! (also crash upon requesting permissions).

Core Network.java code :

        MessageProto.Message.Builder messageBuilder = MessageProto.Message.newBuilder()
                .setSourcePeerId(hashId)
                .setDestinationAddress(ByteString.copyFrom(peer.getAddress().getAddress().getAddress()))
                .setDestinationPort(peer.getAddress().getPort())
                .setPublicKey(ByteString.copyFrom(publicKey.toBytes()))
                .setType(INTRODUCTION_REQUEST_ID)
                .setPayload(MessageProto.Payload.newBuilder().setIntroductionRequest(request));

        sendMessage(messageBuilder.build(), peer);

[synctext]

Status:

• zero-knowledge proof: not yet operational in Java
• timer added for UDP packets
  • please make it easy to understand
  • From / To directionality and simply a counter which jumps to "0".
  • :arrow_left: and :arrow_right:
• claims and attestation in GUI, first version
• usability: back button is silent close (toast: "exiting"); home button is silent in background (toast: "running is background, use back button to exit").
• Next sprints:
  • generic digital signature
  • claim format for photo signature
  • claim format for .PDF file signature
  • sign raw byte block (e.g. file)
  • importance of "blockchain viewer", see blocks of others
  • goal (see above): attestation of birth (official doctor attestation, claim of parent and doctor; genesis baby block)
  • see example attestation IPv8 docs by Dan
  • (bonus) networking stress test
  • code coverage travis and codecov ?
• Notary demo: 1 code on Play.google 2 signature on photo demo, browse 3 QR code with signature transfer 4 passport scan demo

[jonathanraes]

Document signing merged in #26

• allows a file to be sent in a block's transaction field instead of a text message and signed like any otehr block.

• Maximum file size is currently 65kb, limited by the maximum UDP datagram size.

  A new release will be made when #30 is merged.

attest_claims branch contains code for creating and transferring a claim as plain text to an attestee using beam or a QR code.

• Did you also want files to be able to be attached to claims? This would limit the usuability of QR codes as the maximum size transferrable using a QR code is only about 3kilobytes.

[synctext]

Good progress. Tomorrow is demo day.. Is newest version on Google.play? Can you please add a "release version" into the info tab, for instance?

[wkmeijer]

The newest version will be online in a few hours, finalizing the last tests for backwards compatibility now. I'll also come by to update the bootstrap phone.

[wkmeijer]

We did another small release to the play store with some minor fixes:

• added a notice that the app is still running on exit through home button
• fixed bug where all chains were displayed as "my chain"
• fixed bug where peers in chain explorer weren't named correctly
• fixed pop-up loop in ocr scanning when denying permissions

[synctext]

Progress: 15,513 additions and 6,513 deletions in Pull Request. Out of which 9234 is outgenerated from app/src/main/java/nl/tudelft/cs4160/trustchain_android/message/MessageProto.java. Simple Android studio build

Final sprint:

• location of documentation + final reporting : https://readthedocs.org/projects/trustchain-android/
  • include screenshots
  • picture of code coverage
  • chapter performance analysis and maturity of code
• code coverage with graphs/pictures in report .rst format
• integrate blinking lights with the Send and Receive text. Only update every 500ms
• stress test at scale and documented results with actual graphs
  • indicate mobile phone provider, wifi details, phone model
  • 100 nodes per phone, solid network...
  • KByte of traffic in time
  • connection health (lot of incoming traffic while others have little incoming traffic)
  • profiling
• claim and attestation documentation for your implementation
• offline block signing and documentation

[wkmeijer]

The last release is now also available in the play store. Documentation is up to date. Jonathan is finishing creating the performance graphs, so they will be visible on readthedocs tomorrow.

Things that changed since last time:

• Fixes for UI glitches for long usernames
• Update UI response when message is received
• Offline block sending functionality through QR codes and Android Beam
• Stress testing functionality, one phone can now start numerous peers for stress testing
• Connection statistics

All the code is on https://github.com/klikooo/CS4160-trustchain-android for now. The documentation is on http://trustchain.readthedocs.io. This can be moved to the wkmeijer/CS4160-trustchain-android and the trustchain-android.readthedocs tomorrow.

[wkmeijer]

Todo's:

• Signed introduction requests, currently unsigned message with public key, unicode username and ip address
• offline send, user may be confused when the reply step is completed
• sequence number in mutualblock (in inbox) is not displayed correctly
• mychain collapses the directed graph into a list, which is difficult to display. Currently the chain is odered on sequence numbers that occurs first in a block, so it mixes the peer and in the linked peer.
• Passport scan results never leave your device, not stored on any blockchain.
• Can communicate and sign bytes with passport chip.
• 3g/4g connection only works with KPN/Telfort network, T-Mobile (confirmed), Vodafone (confirmed), Tele-2 (confirmed) have a carrier grade nat which blocks incoming connection.

[synctext]

@klikooo implement binary transfer. summer project

• enable generic remote electronic signature of any .PDF file or picture
• the real robust code.
  • Mix C++ lib with Android (https://github.com/arvidn/libutp)
  • The libutp interface is not thread-safe. It was designed for use in a single-threaded asyncronous context
• Micro Transport Protocoll 4 Java
• re-usage of UDP socket, switch from trustchain commands to uTP
  • uTP specifications, make trustchain a unique bit-pattern.
  • multiplexing: any incoming datagram is either trustchain or uTP
  • incoming SYN trigger binary transfers or something?

[qstokkink]

This course work seems to have been completed several years ago. I'll close this issue now.