e-Health Platform End 2 End encryption

Basic Objective end-to-end encryption (ETEE) should allow actors in the healthcare sector to exchange electronic messages on open networks without any individual other than the sender and the final recipient being able to see the contents (confidentiality aspect) and with the guarantee that the encrypted content was not changed since it was sent (integrity aspect) thus, the encrypted content of the electronic messages cannot be decrypted or changed by intervening agencies such as the eHealth-platform or an organisation responsible for temporary storage of the messages

Functional Requirements the end-to-end encryption system must allow for end-to-end encryption of electronic messages if the recipient of the message is known at the time of the encryption end-to-end encryption of electronic messages if the recipient of the message is not known at the time of the encryption encryption of electronic messages during temporary storage so that only those who created them can decrypt them the system must be able to be used by all healthcare actors in Belgium for as many applications as possible without the need for agreements with each partner or the application of specific standards

Symmetrical keys Asymmetrical keys Hashes Digital signatures Cryptography Symmetrical keys Asymmetrical keys Hashes Digital signatures Encryption

Symmetric Key the key used for encryption is the same as that used for decryption Typically used in case of an unknown recipient: the key is generated by the eHealth-platform, made available to the sender and kept by the eHealth platform linked with a unique number for the encrypted electronic message the encrypted electronic message is NEVER saved in the sphere of influence of the eHealth-platform the final competent recipient of the encrypted message demonstrates its decryption right and receives the key to decrypt the message in question from the eHealth-platform is used when the recipient is not known by the sender at the time of encryption or for temporary encrypted storage of electronic messages

Symmetric keys: best for encryption Efficient implementations in hard/software Much better performance than asymmetric keys, good for encrypting large files Difficult key distribution: for each partner one key

Asymmetric key the key used for encryption is different from the one used for decryption Typically used in case of a known recipient (the recipient is known by the sender at the time of encryption): each actor generates a key pair under its sole control what is encrypted with one key of the key pair can only be decrypted with the other key of the same key pair one key of the key pair is saved in a public databank and the other is securely saved by the owner

Asymmetric key: best for integrity and authentication Private key has to be protected Public key may be published Asymmetric encryption is not efficient -> best used to encrypt small things (e.g. a hash, a symmetric key) Can be used to distribute symmetric keys

Asymmetric key: usage

Hash function One way function Generates output of fixed length, independent of size of input One can not recalculate original input based on its hash Input changes one bit => output (hash) changes too Based on a hash, a file can be uniquely identified H(M)

Digital Signature public private public Data base RSA RSA HASH HASH Document Smart Card public private public Document HASH Document RSA HASH HASH RSA Digital Signature Digital Signature Internet Intranet

File Encryption Decryption Encrypted Public RSA-Key Private RSA-Key encrypted Session Key Encrypted Decryption AES decrypted Document AES Document &%/()=?* H3456+# ## >>%### -:,)=?Ӥ$ RSA Decryption Session Key Private RSA-Key of Receiver Random Generator Session Key Public Key directory RSA Public RSA-Key of Receiver File Encryption Aim: to encrypt a file for one or more specific recipients. The sender wants to be sure that only the recipient can decrypt the message. The sender's computer generates a random symmetrical key (according to a certain algorithm and with a certain key length). This is used to encrypt the file. The symmetrical key is then encrypted with the recipient's public key. If there are several recipients, this symmetrical key is encrypted separately for each recipient. The encrypted file and the encrypted symmetrical key are sent to the recipient. As the recipient is the only individual that has access to its private key, he/she can decrypt the encrypted symmetrical key that provides the symmetrical key. This symmetrical key can then be used to decrypt the file.

E2EE known receiver

Certificate Request

ETK Request

ETEE message: triple wrapped

Sender Side actions

Receiver Side Actions

Diagram of Symmetrical En/Decryption Key Management / Depot Symmetric key Encrypted with public key of user 1 Encrypted with public key of user 2 Symmetric key 2 sends key 5 receives key User 1 Originator 1 asks for key User 2 Recipient 4 justifies right to obtain key 4 justifies right to obtain message 3 sends encrypted message Encrypted with public key of Message depot 5 receives message Encrypted with public key of User 2 Message encrypted with symmetric key Messages Depot Message encrypted with symmetric key Message encrypted with symmetric key

Detailed Services for asymmetrical encryption and decryption system is available and validated by COSIC consists of a software library with corresponding documentation (cookbook) that can be integrated into the software packs of actors in the healthcare sector, making it possible to securely generate key pairs locally securely store the private key of the key pair locally store the public key of the key pair in a public databank on the eHealth- platform via a webservice search for the recipient's public key via a webservice in the public databank on the eHealth-platform and encrypt the electronic message decrypt a received encrypted message with one's own private key for all of this, also place the necessary digital signatures and use and verify the validity of the associated certificates

Detailed Services for symmetrical encryption and decryption system is under development and probably available by end 2009 will be presented to COSIC for validation consists of a webservice with associated documentation that can be called up from the eHealth-platform to obtain a symmetrical key for encryption of a specific electronic message a webservice with associated documentation that can be called up from the eHealth-platform to obtain a symmetrical key for decryption of a specific electronic message a software library with corresponding documentation that can be integrated into the software packs of actors in the healthcare sector, making it possible to encrypt the electronic message with the symmetrical key decrypt the electronic message with the symmetrical key for all of this, also place the necessary digital signatures and use and verify the validity of the associated certificates

Deliverables already available the following documentation and components of the ETEE environment are already available on the portal of the eHealth-platform an "architecture document" with a description of the conceptual and technical components of the overall system a "cookbook" that presents the documentation regarding encryption standards and protocols recommended by the eHealth-platform and the procedure to obtain "authentication certificates" the "technical specifications" of those components already available specific for the encryption of messages sent the application to generate key pairs and to obtain encryption certificates the databank where the public keys can be stored and searched for, accessible via documented webservices the application/utility/source code for encryption and decryption