DEMOS WHAT CAN IT HELP WITH CORONA

This is a personal website showing what we can or could do with IT means to support the fighting of the COVID crisis. For the time being it concentrates on vaccination and testing certificates and on contact tracing and how these elements work or should work together. There is a special emphasis on services cross Europe including the aspects of data protection (GDPR) as well as the very different situations as concerns the health sector. This is of prime importance as the health sector is part of the public sector in some Member States and more or less fully privatized in other Member States. (Just considering that medical data belong to the patient in Austria while being in the domain of doctors in Germany this already shows that a common view is not easy.) All these aspects are added the fact that a pandemic gives reason for exceptions and specific powers which are not in place in normal medical situations.

SOME PRINCIPLES Under the assumption that IT support for COVID is extending to many sectors and that some of the aspects will stay with our society for quite a while it is important that there are agreed principles for such support. As we see with related medical products (masks, vaccine...) the temptation to make money with fraudulent products and processes this underpins that clear, transparent principles are baseline for trust and security. Not observing trust and security leads to the situation where the population does not accept and follow. IT can be a great help with implementing of transparent principles:  No entity shall be able to trace usage or other data unless defined in law. Performance and cost is used as an argument that cloud is the only way to efficiently cope with the situation especially on an European scale. At the same time major cloud providers are situated or legally responsible to states outside the EU. Therefore untraceability is probably the most important aspect as data in this context might be even illegally sold.  All data that leaves the user's device shall be encrypted end-to-end. Such encryption shall be performed with a state of the art strong crypto mechanism where the keys are never generated or seen by third parties. While this principle limits the processing at third parties like with cloud providers it seems to be inevitable. This fact is also underpinned by the fact that users cannot see whether attacks like Meltdown and Sceptre and the derived ones are properly avoided. With cloud it has to be assumed that for sheer monetary reasons there is a lot of grey zones.  The user shall be in the position to know and to control what data are stored and communicated at any point in time. Unless the user gets full control he or she will not accept or at least assume that there are unwanted or illegal communications.  All relevant data shall be secured (signed). To make absolutely sure that data is not accidently altered and that the source and modification of data becomes evident electronic signature is key. This is also the main aspect that allows offline use and use without third party proofs/verifications..  Storing and communication of data shall be kept to the absolute minimum. This includes the amount and the time. Also it should be made sure that data cannot be used or communicated without the user's consent (e.g. self-incrimination in case of captured devices).

PROOF OF EVENT Events like having undergone an infection, being vaccinated, having a negative COVID test might be used as prerequisite in private and business situations. Such events might be treated different in different situations (sometimes a negative test might be OK if it is up to 5 days old; in other situations 48 hours might be the maximum ...). It is obviously in the interest of the person in question to show such proof in a secure and convenient way. At the same time, we have to be honest and see that such measures are perceived as overhead for all parties involved! This means that any short-cut the system allows will also be taken. (e.g. if you ask a negative test or vaccination be presented when you enter a restaurant and in case you separate the verification of the person through an id-card from the presentation of the document the verification of the person will in many cases be done very sloppy or not at all.) Convenience first: we have to follow this principle to keep all players on board. the following picture gives a rough outline: In case there is no confirmed picture availabel the process can be exatly the same as this fact is recognized at the verifyer. Such process (involving a static QR with a static key and a server holding the encrpted information (without the ability to decrypt the information) could also be used in a paper based fall-back for those not using an APP (there would be no difference at the receiver's side): A simple proof of concept can be found here - obvioud tasks like signing and verification are not fully integrated. This PoC comes also with a very simple "Test-document" and a "passport foto" to view the PoC. To demonstrate "without signed picture" can be used as "picture". To check such QR click here. Checking could also be done by just using a standard QR-Reader - however this would allow the presenter to use a fake url in the QR-Code! One cannot assume that the verifier makes the effort of making sure this "shortcut" is not taken. APP In this context a very simple APP (for Android) to present such documents is available at this LINK To demonstrate integration with databases this APP gets the document and the associated picture over the internet from a fixed address. In a real situation retreiving both the document and the picture in a correct way woul be subject to eID and both would be electronically signed to allow verification and information would be added to ensure both belonging together. Documeent and picture are communicated as datURL which would allow to include the required additional information (a random identifier which proofs both belonging to the same person and electronic signature).

In case you have a question please send an email to: reinhard.posch@a.sit.at. I will try my best to answer.