privacy and self-sovereign identity

[synctext]

draft thesis direction

Investigate the revealing of privacy-sensitive attributes of your identity. Should be usable even in the sensitive medical domain with electronic patient files.

First step, find related work in this area (irma, zero-knowledge, zkSNARKs)

For next meeting: gather all general docs, weforum Djuri his thesis, etc. in .PDF form.

[synctext]

Progress meeting minutes:

• Accountability on access implemented
• Validation of entries implemented
• no long-lived identities yet for doctor or patient
• possible inclusion of blockchain baby architecture picture
• draw.io or xfig
• 6. MediTrail prototype global overview / implementation / architecture and implementation
• idea behind "Proof of Elapsed Time consensus" focus of this sprint
  • 1 node is elected to extend the blockchain
  • unique blockchain for each medical patient file
  • random rounds to process pending transaction
  • buffer in node contain the pending transaction, then committed to the blockchain
  • unclear to me what the buffering and commitment-delay offers
• "For the purpose of performance evaluation we added a consensus algorithm to our prototype. This consensus mechanism is not designed to add features or business functionality. It is added purely as an enabler for determining the cost of consensus in a concrete use-case such as medical patient file access auditing."
• possible outcome: snail-slow

[AngelaBarrio]

Activities:

• attached private key to user
• conducted experiments
• improved thesis draft thesis-9-dec.pdf

[synctext]

Meeting minutes:

• 24 pages for first 4 chapters

• Chapter 2 research statement

• 1. Accountability on access: knowing who has accessed the file;
     • 1. The medical record system must provide the patient with accountability mechanisms.
     • 2. The medical record system must provide the patient with evidence regarding permissions history for auditing purposes.
     • 3. The medical record system must provide the patient with evidence of security breaches.
• 2. Validation of EMR entries by both the health care provider and the patient.

• Section 2.4 Requirements:

  • 1. Accountability on access: Every access to an entry in the EMR system is recorded. The log contains information on the name of the user who accessed the file, the name of the file itself, and the timestamp of the event.
  • 2. Validation of entries: A user should be able to sign an entry with a secure digital signature. The digital signatures should be verifiable by anyone in the system.

• Section 5.1 "From requirements to use cases", no link to above research questions

• "The system that is being designed in this master thesis is a prototype" strange defensive wording

• POET: "For a permissioned blockchain, it is a secure and efficient algorithm" mention unlimited identity creation and cheating at the lottery. Mention commitment scheme. Magic Intel silicon can't be the magic solution (e.g. tamper-proof).

• Section "5.2 Blockchains", selecting blockchain technology

• Section "5.4 Digital signature algorithm", encryption implementation

• A block contains it's own hash? "6. Hash of this block"

• FIGURE 6.4: Screenshot of the my logs page (btw never referenced in text)

  • Shows 4 message types without documentation
  • Genesis_block, upload_notification, signature_request, file_access_notification
  • 5th: signature_placement

• Pseudocode is tricky (strict: all variables in italic, defined, and used); for instance, undefined SigningBlock. Magic variable "

• single linked list, so no backwards traversal without (documented) index

• Section 7 lacks intro sentence

• 7.1.1: please integrate these 2 lists

• 7.4 Speed of MediTrail features; performance analysis

• Fig 7.2: not scientific to draw a line through 4 data-points! Plus line smoothing is considered bad practice.

• "Distance to latest signing block" please conduct experiments with larger files; upto 1000.

• 7.5.3 Discussion of file access performance, please integrate into single experiment section

• debugging of sleep time problem.

• without consensus performance should be easily 10k blocks per second

[AngelaBarrio]

New thesis draft, processed feedback from last time. thesis-7-jan.pdf

[synctext]

Review notes:

• where is the open source repository?

• thesis is "file oriented" and not 'any digital information' contained within a digital patient database.

• Section 5.3.1, "this high resilience may not be fully needed." perhaps replace with something more technical, like, this solution to the double spending problem in an anonymous network is highly inefficient and not appropriate in our medical context.

• 5.5 Monitoring access to files; please reduce this section or make it more scientific by introducing an "5.5 event-based architecture" where evens can be remotely placed signatures, blockchain block creations, or file access. Void of all expensive continuous polling. 5.3.4 Proof of Elapsed Time; "it is a secure and efficient algorithm" hard claim without citations or mathematical proof! Please explain this simple 'sleep-and-wake-up' algorithm and compare it to leader election in Byzantine Fault Tolerant Systems and Nakamoto consensus.

• "every file that has been uploaded should be downloadable by every user in the system." This formulations sounds very privacy invasive.

• "To create a minimum level of aesthetic appeal" :-)

• 7.4.2 "Unfortunately, performing the same large experiments with the PoET configuration would cost too much time compared to the value of the data."; "no data" entries are unclear. why was this experiment stopped?

• 7.4.3: "Unfortunately, performing the same large experiments with the PoET"; again not a clean experiment.

• The 2 magic parameters determine the PoET performance. Make that more explicit and clear, "which makes sense because the parameters for choosing the sleeping time stay set during the experiments."

• "Using the PoET consensus algorithm with the chosen parameters adds tremendous overhead."; no motivation for magic parameter values.

• Tip for scientific depth. Key to consensus is the expected outcome for an n participant lottery with drawing numbers between (min, max) interval. The expected duration of a consensus round can be expressed mathematically. Good theoretical depth to final chapter.

Future work ideas&brainstorm: run a test network using public datasets like a prescribed medication for all doctors in the UK for a whole year. Emulate all hospitals, doctors, and medication prescription events.

[synctext]

On Security Analysis of Proof-of-Elapsed-Time (PoET). Solid related work for a security analysis. It introduces a likelyhood of being a cheater. The basic idea is to use z-test to check whether a node is generating blocks too fast (winning too frequently in the competition with other nodes for block creation.

[synctext]

No more comments on thesis text and chapter wording. Except usage of Sybil term for cheating in a lottery (7.2.1 Sybil attacks). Advised to make "7.2 Resistance against attacks" a single text paragraph without sub-sub-headings.

Final thesis addition suggestion: link outcome of experimental results with the appropriate theory.

Great additional to theoretical thesis depth (1+ page):

• PoET consensus results: between 5315 ms; 5864 ms
• can be explained with the theory and z-test
• model parameter; between 1 and 10 second for each blockchain round.

[erikvandenakker]

Review notes:

General impression: Extensively introduced topic (good!; clear!); relatively short description of the actual work and its evaluation (but i'm not familiar with the standards in your field, so I'm not the best to judge.

• Small remark: "[TODO: what is a replica??]" I encountered this in your thesis ...
• Suggestion: "Many patients feel that they do not control access to their data, but would like to be able to access the data themselves, look at the history of data access and give or deny access permissions to healthcare providers (World Economic Forum 2012)." While you have developed and tested the required software to make this feasible, I have a feeling it is not tested for the described scenario; to make it more concrete: If I were a patient, I would like to get a comprehensive overview of all my data with annotations who touched what when and when was this agreed upon. How feasible is this given a typical patient (elderly individual first admitted 15 years ago) with a typical amount of medical data (say at least 20 items that are independently tracked)? How long would it take to produce [1] the complete information as presented in 6.4 [2] Do you have suggestions to graphically represent this information?
• 7.4.1 Results have been presented as averages. Why not use boxplots to indicate the variance of the elapsed time? Or is this variance meaningless?
• 7.4.2 "Unfortunately, performing the same large experiments with the PoET configuration would cost too much time compared to the value of the data." Can you explain this?
• "Unfortunately, users cannot verify each other’s signatures." What wold you propose to incorporate this?
• How to deal with re-use of patient data for scientific research or quality aspects? Do these type of accesses get the same 'stamp', is this desirable? And if not, how to deal with this?

I would be happy to discuss more practical aspects when implementing MediTrail in a medical environment such as an academic hospital. Looking forward to hear more!

Cheers,

Erik

[AngelaBarrio]

• I fixed the bug!!! performance is much better now

• Had to re-do almost all experiments due to fixing the bug, but it enabled me to include the experiments that would take too much time previously

• Represented Upload and Read event experiments with box plots

• Implemented some text feedback THESIS-10feb.pdf

• Need to fix the box plots (somehow add right numbers on horizontal axis and converting to ms)

• Code: https://github.com/AngelaBarrio/meditrail

[synctext]

• nice addition to depth of thesis
• FIGURE 7.1: Time needed for adding upload blocks (N=100), no consensus (battle with .xls)
• explain standard deviations and size of boxplot.
• mixing seconds and milliseconds
• expand section 7.5

[AngelaBarrio]

Presentation draft: presentatie.pptx

[synctext]

Thesis FINISHED :clap: