Implementació d'un esquema criptogràfic per gestionar de forma segura els historials mèdics dels pacients a través d'una xarxa de comunicacions

Texto completo

(1)PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Implementació d'un esquema criptogràfic per gestionar de forma segura els historials mèdics dels pacients a través d'una xarxa de comunicacions. Nom Estudiant: Gerard Farràs i Ballabriga Enginyeria en Informàtica. Nom Consultor: Jordi Castellà-Roca Data Lliurament: 7 de Gener del 2007. 1.

(2) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. 2.

(3) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Dedicatòria i agraïments.. A la Sandra Escolies i Caballol i al Dr. Casserras i Aynés per a haver-me explicat pacientment els conceptes d'un sistema d'informació d'àmbit sanitari.. 3.

(4) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Resum del projecte El projecte consisteix en la implementació d'un esquema criptogràfic per a poder accedir de forma segura a historials mèdics a través d'una xarxa de telecomunicacions. Les noves tecnologies permeten accedir de forma remota a grans volums d'informació utilitzant xarxes de telecomunicacions. Una aplicació molt interessant d'aquest accés remot a dades és el de la informació de tipus sanitari: La història clínica d'un determinat pacient. D'aquesta manera, s'obren noves possibilitats en aquest terreny, com pot ser la telemedicina, amb la possibilitat de realitzar diagnòstics de forma remota (per exemple, que un laboratori pogués introduir els resultats d'una analítica o un especialista radiòleg informés del seu diagnòstic visualitzant només una radiografia) o la compartició d'historials clínics entre centres sanitaris, entre d'altres aplicacions. S'ha de tenir molt en compte però que la història clínica d'un pacient és informació altament sensible, protegida per Llei i que s'ha d'assegurar especialment la seva protecció, i més tenint en compte que aquest informació viatge per xarxes no segures. Entre d'altres, el sistema hauria d'assegurar les propietats de confidencialitat, autenticitat, integritat i no-repudi. El projecte ha de generar un seguit d'aplicacions per a que els usuaris i els metges puguin accedir a través d'una xarxa de comunicacions als historials clínics mantenint sempre els requisits de seguretat comentats anteriorment. Les tecnologies emprades per a la implementació d'aquest PFC seran les següents: • • • • •. Java com a llenguatge de programació. Llibreria en Java IAIK per a la implementació dels protocols criptogràfics. MySQL com a servidor de base de dades. XML com a format per a transmetre les dades. RMI (Java Remote Method Interface) com a mètode per a realitzar les comunicacions.. Paraules clau. Sistemes d'informació sanitari. Hospital Information System (HIS). Historials clínics. Criptografia. Seguretat informàtica. Java. IAIK. Public Key Infrastructure. XML. MySQL. RMI. Nom de l’àrea de PFC. Seguretat informàtica.. 4.


(6) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Índex de continguts Capítol 1. Introducció..........................................................8 Justificació del PFC i context en el qual es desenvolupa.........................9 Objectius del PFC..................................................................................10 Enfocament i mètode seguit.................................................................11 Planificació del projecte........................................................................12 Calendari..............................................................................................13 Productes obtinguts..............................................................................14 Breu descripció dels altres capítols......................................................14. Capítol 2. PKI i IAIK............................................................16 Introducció a PKI...................................................................................17 OpenSSL...............................................................................................17 Procediments per a la generació dels fitxers de la PKI.........................18 Introducció a IAIK..................................................................................20 Passos per a instal·lar IAIK....................................................................20. Capítol 3. Protocols criptogràfics.......................................22 Requisits de seguretat..........................................................................23 Notació emprada en els protocols........................................................23 Autenticació en el sistema....................................................................23 Consulta d'un historial..........................................................................24 Consulta dels pacients assignats a un metge.......................................25 Introducció de dades a l'historial mèdic...............................................27 Diagrama de classes............................................................................29. Capítol 4. Representació de les dades: XML......................31 Introducció............................................................................................32 Definició dels documents en XML.........................................................32. Capítol 5. Comunicació entre agents: RMI.........................36 Introducció........................................................................................... 37 Mètodes accessibles públicament al gestor.........................................37. Capítol 6. Gestor de base de dades..................................39 Introducció............................................................................................40 Descripció de les taules........................................................................40 Diagrama entitat-relació.......................................................................41. 6.

(7) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Capítol 7. Interfície gràfica................................................43 Introducció............................................................................................44 Interfície d'usuari per als clients...........................................................44 Execució del client................................................................................47 Interfície d'usuari per al gestor del sistema..........................................47 Execució del gestor..............................................................................50. Capítol 8: Jocs de proves...................................................51 Introducció............................................................................................52 Generació dels certificats.....................................................................52 Instal·lació i configuració de la base de dades.....................................58 Inserció dels usuaris en la base de dades............................................58 Configuració per a l'execució a través de la màquina virtual de Java...60 Jocs de proves per als protocols criptogràfics.......................................60 Jocs de proves definitiu.........................................................................61. Capítol 9: Valoració econòmica.........................................65 Capítol 10. Conclusions.................................................... 67 Capítol 11. Possible treball futur.......................................70 Glossari de termes............................................................71 Bibliografia i referències...................................................75 Annexos............................................................................78 Annex A. Fitxer de configuració del PKI................................................79 Annex B. Fitxer de configuració de la base de dades...........................84 Annex C. Codi Java per a proves de fases no finals..............................85 Annex D. Relació de fitxers font continguts en la carpeta src/.............98. 7.

(8) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Capítol 1. Introducció.. 8.

(9) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Justificació del PFC i context en el qual es desenvolupa: punt de partida i aportació del PFC. Les noves tecnologies permeten accedir de forma remota a grans volums d'informació utilitzant xarxes de telecomunicacions. Una aplicació molt interessant d'aquest accés remot a dades és el de la informació de tipus sanitari: La història clínica d'un determinat pacient. D'aquesta manera, s'obren noves possibilitats en aquest terreny, com pot ser la telemedicina, amb la possibilitat de realitzar diagnòstics de forma remota (per exemple, que un laboratori pogués introduir els resultats d'una analítica o un metge radiòleg informés del seu diagnòstic visualitzant una radiografia) o la compartició d'historials clínics entre centres sanitaris, entre d'altres aplicacions. D'altra banda, comentar que és la Llei Orgànica de Protecció de Dades de Caràcter Personal (en endavant, LOPD), qui regula la protecció de les dades de caràcter personal i el posterior tractament que pugui fer-se de les mateixes. Aquesta llei defineix el concepte de dada de caràcter personal com a qualsevol informació que concerneixi a una persona física identificada o identificable. És ben clar que les dades sanitàries son dades de caràcter personal i que, per tant, el tractament d'aquestes queda sota la responsabilitat de protecció de la LOPD. La referència a aquest tipus de dades apareix en l'article 7 de la LOPD, dins l'apartat per a tractament de dades de caràcter personal especialment protegits i també en l'article 8. Tot i això, no solament la LOPD regula el tractament de dades de tipus sanitari. La Llei 14/1986 General de Sanitat estableix en el seu article 10.3 el dret del ciutadà a la confidencialitat de les seves dades i en l'article 23 recull la potestat de l'administració sanitària per a crear registres. Aquests registres hauran d'adoptar les mesures tècniques i organitzatives que estableix el Real Decret 994/1999. Definit el concepte de dada de tipus sanitari com a dada relativa a la salut de l'interessat (pacient/persona física titular de les dades) és necessari tenir en compte que aquest tipus de dades només pot ser obtingut quan expressament ho determini la Llei o l'afectat ho consenteixi de manera expressa (article 7 LOPD). Tot i això, les institucions i els centres sanitaris públics i privats podran procedir al tractament d'aquest tipus de dades subjectant-se sempre a la legislació estatal o autonòmica sanitària específica. En quant a la legislació autonòmica existent relativa a les dades sanitàries, destaca la Llei del Parlament Català del 21 de desembre del 2000, sobre els “drets d'informació relatius a la salut i a la autonomia del pacient i a la documentació clínica”. En aquesta llei es recull el dret del pacient a conèixer tota la informació sobre la seva salut i que aquesta informació sigui verídica i comprensible i el dret de tota persona al fet que es respecti la confidencialitat de les dades referents a la seva salut. En el moment de la recollida de les dades, el metge ha de complir amb determinades formalitats informant de forma expressa, precisa i inequívoca al pacient de: ● ● ●. L'existència d'un fitxer, de la finalitat de la recollida de dades i dels destinataris de dita informació. La identitat i direcció del responsable del fitxer. Del caràcter obligatori o facultatiu de les respostes a les preguntes. 9.

(10) PFC – Seguretat en historials clínics ●. Universitat Oberta de Catalunya. I de la possibilitat d'exercitar els drets d'accés, rectificació, cancel·lació i oposició. És a dir, el pacient té dret a accedir a la història clínica i a obtenir una còpia de les dades. Té també dret de rectificació i cancel·lació en el cas que el pacient desitgi que les seves dades siguin rectificades o cancel·lades.. Qualsevol fitxer que contingui dades de salut ha de complir amb les mesures de seguretat de nivell alt (article 20 i ss del Real Decret94/1999), és a dir, a més de complir les mesures de seguretat de nivell bàsic i mitjà (document de seguretat, registre d'incidències, identificació/autenticació, controls d'accés, còpies de seguretat i recuperació, responsable de seguretat, controls d'accés físic), ha de comptar amb un registre d'accessos, és a dir, no tot el personal ha de tenir accés a tot el fitxer, ha de comptar amb un xifrat en les telecomunicacions i efectuar-se auditories, com a mínim, de forma bianual. La Llei ja dona doncs les indicacions que s'haurien d'implementar. A més, en aquest projecte, es tindrà cura de les següents característiques:. •. •. La informació dels historials clínics ha de romandre xifrada i s'ha de transportar també de forma xifrada per a assegurar-nos que es mantindrà sempre la seva “confidencialitat”.. •. La informació que es desa en cada historial clínic ha estat “escrita” per professionals autoritzats, assegurant-nos sempre que aquesta és autèntica.. •. La informació que es desa en cada historial clínic no pot haver estat “modificada” per a cap usuari malintencionat, amb la qual cosa el sistema ha d'assegurar que aquesta roman íntegra. Una vegada un determinat professional ha escrit informació en la història clínica, aquest no ha de poder dir més endavant que no ha estat ell qui l'ha realitzada, amb la qual cosa el sistema garanteix el no-repudi.. Comentar també que actualment ja hi ha en el mercat gran quantitat de programari que implementa sistemes d'informació hospitalària (HIS) però creiem que l'aportació més important d'aquest PFC és el seu intens ús d'eines criptogràfiques. Objectius del PFC. Com ja s'ha comentat anteriorment, el principal objectiu d'aquest projecte de final de carrera és desenvolupar un programari que implementi un sistema de gestió sanitària senzill on els usuaris es puguin connectar de forma remota a un gestor central que contingui tota la informació de forma centralitzada però emprant criptografia de clau pública per a totes les operacions. A continuació, una llista més concreta dels objectius: ●. Implementació de l'esquema criptogràfic amb les operacions següents.  Identificació d'un usuari en el sistema.  Autenticació dels usuaris. 10.

(11) PFC – Seguretat en historials clínics. ● ● ● ●. Universitat Oberta de Catalunya.  Consulta dels historials clínics per part dels usuaris amb permisos.  Consulta dels pacients assignats a un metge.  Inserció de dades a l'historial mèdic d'un determinat pacient. La informació hauria de residir de forma centralitzada, en un servidor de base de dades relacional, com per exemple, MySQL. La comunicació entre els diferents agents es realitzarà a través de missatges en format XML (eXtensible Markup Language). La comunicació entre els diferents agents es realitzarà a través del protocol RMI (Java Remote Method Implementation). S'hauria de de generar almenys 3 interfícies gràfiques per als diferents perfils d'usuari:  Aplicatiu metge: Per a permetre que un metge pugui consultar i modificar l'historial d'un pacient de forma segura.  Aplicatiu pacient: Per a permetre que un usuari pugui consultar el seu (i només el seu) historial.  Gestor central: Aplicatiu amb el repositori amb tots els historials. Des d'aquest aplicatiu, s'haurien de poder donar d'alta en el sistema els pacients i els metges.. Enfocament i mètode seguit. Aquest sistema necessita la interacció dels següents mòduls: ●. L'esquema criptogràfic és la base del projecte. Les classes s'han dissenyat de manera que poguessin ser reutilitzades en qualsevol dels aplicatius.. ●. El format de la informació que es transmet es desa en documents XML per tal de poder efectuar una manipulació senzilla de les dades per a les diferents parts.. ●. Els usuaris del sistema s'han de poder comunicar per xarxa, així que serà necessària una plataforma de comunicació que permeti la transmissió de la documentació clínica en format XML entre el servidor central i les altres parts del sistema, ja siguin, pacients o metges.. ●. La informació que es gestiona s'ha de desar en una base de dades relacional.. ●. Finalment, per a cada perfil d'usuari del sistema es requereix una interfície gràfica per a dur a terme les funcionalitats del sistema.. En resum doncs, el sistema compta amb els mòduls següents: ●. L'esquema criptogràfic.. ●. La representació de les dades en format XML.. ●. La comunicació dels components emprant RMI.. ●. La base de dades MySQL.. ●. La interfície gràfica. 11.

(12) PFC – Seguretat en historials clínics. ●. Universitat Oberta de Catalunya. La documentació.. El mètode que s'ha seguit per a implementar el sistema ha estat el d'anar construint cadascun dels mòduls successivament l'un darrera l'altre efectuant proves unitàries amb cadascun d'ells. Cada mòdul s'integra al següent i es realitzen proves unitàries de nou. Així, el que s'ha fet, pas a pas, és el següent: ●. Definició del protocol criptogràfic.. ●. Implementació dels diferents protocols en un entorn local, incloent l'esquema criptogràfic.. ●. Integració de XML en el mòdul.. ●. Implementació de la comunicació entre components. En aquest pas s'envien documents XML entre els aplicatius de metges i pacients al servidor central a través de tecnologia RMI.. ●. Integració de la base de dades.. ●. Finalment, creació de les interfícies gràfiques per als clients (pacients i metges) i gestors per a poder realitzar amb comoditat totes les operacions implementades.. Comentar que, malgrat que en la interfície gràfica és possible esmerçar-s'hi amb multitud de detalls i que, de fet, és el que s'acaba visualitzant, no ha estat l'objectiu prioritari. Planificació del projecte. El projecte va començar durant el setembre del 2007. La planificació que es va fer és detalla a continuació: Instal·lar IAIK PKI. PAC1. Implementació protocols. openssl objectiu criptografia. setmana 1. disseny. Implementació documents. objectiu XML objectiu RMI. disseny. objectiu model. disseny. objectiu aplicatiu client. disseny. Vista client. objectiu aplicatiu gestor. disseny. Vista gestor Documentacio. objectiu conclusions. disseny. Implementació. test. documentació. PAC 2 setmana 2 setmana 5. Comunicacions Servidor RMI Client base RMI BD servidor Registre usuaris. Implementació. test. documentació. PAC 3 setmana 6 setmana 7. Implementació. test. documentació. PAC 4 setmana 8 setmana 9. Implementació. test. documentació. PAC 5 setmana 10 setmana 11. Implementació. test. documentació. PAC 6 setmana 12 setmana 13. Implementació. test. documentació. PAC 7 setmana 14 setmana 15. test. documentació. PAC 8 setmana 16. 12.

(13) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Calendari Del 19 al 23 de setembre: * Instal·lació de la llibreria IAIK i generació de PKI amb OpenSSL. Del 24 de setembre fins al 21 d'octubre: * Implementació dels protocols criptogràfics. Fases de disseny, implementació, test i documentació. Del 22 d'octubre fins al 4 de novembre: * Implementació dels documents en XML. Fases de disseny, implementació, test i documentació. Del 5 al 18 de novembre: * Implementació dels documents en RMI. Fases de disseny, implementació, test i documentació. Del 19 de novembre al 2 de desembre: * Implementació de la base de dades del servidor. Fases de disseny, implementació, test i documentació. Del 3 al 16 de desembre: * Implementació de la interfície gràfica d'usuari. Fases de disseny, implementació, test i documentació. Del 17 al 30 de desembre: * Implementació de la interfície gràfica per al gestor. Fases de disseny, implementació, test i documentació. Del 31 al 6 de gener: * Redacció final de la documentació. En resum:. 13.

(14) PFC – Seguretat en historials clínics Setmana 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17. dilluns. dimarts. 24 1 8 15 22 29 5 12 19 26 3 10 17 24 31 7. Universitat Oberta de Catalunya. dimecres dijous divendres dissabte diumenge 19 20 21 22 23 25 26 27 28 29 30 2 3 4 5 6 7 9 10 11 12 13 14 16 17 18 19 20 21 23 24 25 26 27 28 30 31 1 2 3 4 6 7 8 9 10 11 13 14 15 16 17 18 20 21 22 23 24 25 27 28 29 30 1 2 4 5 6 7 8 9 11 12 13 14 15 16 18 19 20 21 22 23 25 26 27 28 29 30 1 2 3 4 5 6. setembre octubre. novembre. desembre. gener. Dia festiu Lliurament PFC Trobada inici. Productes obtinguts ●. Programari per als pacients i professionals administratius.. Producte desenvolupat en Java que disposa d'una interfície gràfica per a que tant pacients com professionals sanitaris pugui accedir de forma remota als seus historials clínics seguint els protocols criptogràfics dissenyats. Els professionals sanitaris, a més, han de poder afegir nous apunts en les històries clíniques dels seus pacients així com visualitzar un llistat dels pacients que tenen assignats. ●. Programari per al gestor del sistema.. Producte desenvolupat en Java que actua com a gestor del sistema, fent de pont entre les dades i els clients i validant i efectuant totes les operacions d'aquests. Ha faltat per a desenvolupar en el programari del gestor la possibilitat d'afegir nous pacients/metges en el sistema de forma automatitzada. Breu descripció dels altres capítols de la memòria ●. Capítol 2. PKI i IAIK. Explicació del per què és necessari IAIK, conjuntament amb el seu procés d'instal·lació. També perquè és necessari una PKI i mètode de generació dels certificats via OpenSSL.. ●. Capítol 3. Protocols criptogràfics. Descripció detallada dels protocols criptogràfics implementats.. ●. Capítol 4. Representació de les dades: XML. Descripció dels documents XML que s'han emprat per a efectuar les comunicacions de dades durant l'execució dels protocols criptogràfics.. 14.

(15) PFC – Seguretat en historials clínics ●. Universitat Oberta de Catalunya. Capítol 5. Comunicació entre agents: RMI. Descripció de la comunicació dels diferents components del sistema a través de RMI.. ●. Capítol 6. Gestor de base de dades. Disseny de la base de dades que s'ha emprat per a emmagatzemar les dades del sistema.. ●. Capítol 7. Interfície gràfica. Descripció de les interfícies gràfiques que s'han generat per als aplicatius.. ●. Capítol 8: Jocs de proves. Descripció dels jocs de proves que s'han efectuat per a provar les aplicacions desenvolupades.. ●. Capítol 9. Valoració econòmica. Valoració econòmica aproximada del que s'ha desenvolupat. ●. Capítol 10. Conclusions.. ●. Capítol 11. Possible treball futur.. ●. Glossari de termes.. ●. Bibliografia.. ●. Annexos.. 15.

(16) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Capítol 2. Public Key Infrastructure (PKI) i IAIK.. 16.

(17) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Introducció a PKI.. L'esquema criptogràfic que s'implementa en aquest projecte es basa en criptografia de clau pública i requereix, per als diferents actors (metges, pacients i gestor) un certificat digital i una parella de claus (una de pública i una de privada). Per a la gestió d'aquests certificats, amb les corresponents operacions de generació, revocació i validació dels diferents certificats s'empra el que s'anomena una PKI, que correspon a l'acrònim en anglès de Public Key Infrastructure. Una PKI consta d’una autoritat de certificació (CA o Certification Authority, en anglès) i també d'autoritats de registre (RA o Registry Authority, en anglès). Els passos següents indiquen quin és el procediment habitual per a la generació d'un certificat: ● ● ●. L'usuari en qüestió genera una parella de claus i realitza una petició de certificat a la RA. La RA valida la identitat de l'usuari i envia la petició a la CA. La CA rep la petició de la RA i emet el certificat corresponent.. Si un usuari veu que la clau privada corresponent al seu certificat ha estat compromesa ha de comunicar-ho a la CA. La CA revoca aquell certificat incloent-lo en una llista de certificats revocats. La llista de certificats revocats la notem amb les sigles CRL del terme anglès Certificate Revocation List. A continuació es detallen els passos habituals que s'utilitzen per a verificar la validesa d'un certificat. ● ● ●. Primer, examinar el certificat i saber quina CA l'ha generat. Si la CA és de confiança , seguirem amb el procés de verificació. El següent pas serà assegurar-nos que el certificat continua essent vàlid i no ha estat revocat. Per a esbrinar-ho, és possible fer servir un protocol tipus OCSP per a preguntar-li directament a la CA o descarregar-nos directament la CRL de la CA i cercar si hi ha el certificat en procés de validació.. OpenSSL En aquest projecte s'ha emprat la llibreria open-source gratuïta i de lliure distribució Openssl per a la generació de la PKI. OpenSSL està disponible, a més, en múltiples plataformes (com en Windows, GNU/Linux, entre d'altres). La versió emprada és la openssl-0.9.8b-14. Comentar també que els certificats digitals que s'emeten segueixen l'estàndard X.509. La clau privada i el corresponent certificat s'emmagatzemen en un fitxer segons l'estàndard PKCS12.. 17.

(18) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Procediments per a la generació dels fitxers de la PKI. El projecte implementat, basat en criptografia de clau pública, requereix per a cadascun dels diferents actors del sistema una parella de claus emmagatzemades en un fitxer en format PKCS12. Aquest arxiu conté els elements següents: ● ● ●. Clau pública i clau privada de l'usuari. Certificat de l'usuari emès per l'autoritat de certificació. Certificat amb l’autoritat de certificació.. El primer pas que s'ha seguit en aquest projecte ha estat l’obtenció del certificat de l’autoritat de certificació. Si el sistema es decidís d’implantar en organismes on ja es disposés d’una infraestructura de clau pública (PKI) amb una autoritat de certificació establerta, aquest pas no seria necessari. El guió per a generar el certificat de la autoritat de Certificació és el següent: ●. ●. Pas 1. Generar la parella de claus de la CA amb una longitud de clau de 2048 bits utilitzant el guió de seqüències "generarClaus". Aquest guió generarà un fitxer anomenat CA.key. Pas 2. Generar un certificat autosignat a partir de la parella de claus de la CA. Aquest serà el certificat de la CA i el generarem a través del guió "generaCertificatAutosignat". El nom del certificat generat serà CA.crt .. Amb l'autoritat de certificació CA ja establerta, podem ja crear els certificats per als diferents actors. Per a fer-ho, es seguiran els passos que es descriuen a continuació: ●. Pas 1. Generem una parella de claus per a l'actor (ja sigui metge o pacient) utilitzant el guió de seqüències "generarClaus". En aquest cas, podem establir com a 1024 bits la longitud necessària per a les claus.. ●. Pas 2. Generem una petició de certificat a la CA a partir de les claus generades en el punt anterior utilitzant el guió "generaPeticioCertificat".. ●. Pas 3. L'autoritat de certificació generarà el certificat a través del guió "generaCertificat". Aquest utilitza un fitxer de configuració anomenat “openssl.cnf”.. ●. Pas. 4. Finalment, generem l’arxiu PKCS12 a partir del guió “generaPKCS12” emmagatzemant la parella de claus creades, el certificat i el certificat de la mateixa autoritat de certificació. A continuació, el codi dels guions anteriors, executables en un GNU/Linux sense problemes:. 18.

(19) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. generarClaus.sh #!/bin/bash if [ $# -le 1 ]; then echo "Usage: "$0" <key_file> <key_length>" echo "or" echo "Usage: "$0" <key_file> <key_length> <random_file_length>" exit 1 fi if [ $# -eq 2 ]; then openssl genrsa -des3 -out $1 $2 exit 0 fi echo getting random bytes head -c $3 /dev/random > aleatori echo creating key pair openssl genrsa -des3 -rand aleatori -out $1 $2 exit 0. generaPeticioCertificat.sh generarCertificatAutosignat.sh #!/bin/bash #!/bin/bash if if [[ $# $# -le -le 2 2 ]; ]; then then echo "Usage: "$0" <key_file> <file.csr> <config_file>" echo "Usage: "$0" <key_file> <file.crt> <dies>" exit exit 1 1 fi fi openssl req -new -sha1 -x509 -key $1 -out $2 -days $3 openssl req -new -sha1 -config $3 -key $1 -out $2 exit 0 exit 0. generaCertificat.sh #!/bin/bash if [ $# -le 2 ]; then echo "Usage: "$0" <file.csr> <file.crt> <config_file>" echo "or" echo "Usage: "$0" <file.csr> <file.crt> <config_file> <extensions_section>" exit 1 fi if [ $# -le 3 ]; then openssl ca -config $3 -out $2 -infiles $1 exit 0 fi openssl ca -config $3 -out $2 -extensions $4 -infiles $1 exit 0 19.

(20) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. generaPKCS12.sh #!/bin/bash if [ $# -le 3 ]; then echo "Usage: "$0" <key_file> <file.crt> <CA_certificate> <file.p12>" exit 1 fi openssl pkcs12 -export -in $2 -inkey $1 -certfile $3 -out $4 exit 0. En el capítol 8, corresponent al “Joc de Proves”, en el primer apartat, s'explica amb detall com utilitzar aquests guions de seqüències per a generar les parelles de claus, els certificats i els fitxers P12 per a cadascun dels actors i usuaris del sistema. Introducció a IAIK Per a implementar tots els protocols criptogràfics emprarem la biblioteca criptogràfica IAIK. IAIK Java Cryptography Extension (IAIK-JCE) és un conjunt d'APIS (Application Programming Interfaces) i implementacions de funcionalitats criptogràfiques que complementen les funcionalitats de seguretats bàsiques del JDK de Java. Conté, per exemple, funcions de has, sistemes per a xifrat simètric, asimètric, així com gestió de claus i certificats. Passos per a instal·lar IAIK. Els passos per a instal·lar IAIK són, aproximadament, els següents: ●. Descarregar la versió última del JDK de SUN i instal·lar-lo. Cal vigilar que no s'utilitzi la màquina virtual de MS al compilar o executar.. ●. Descarregar l'última versió de IAIK. Encara que cal registrar-se, no suposa cap cost si es tracta per a projectes de recerca i/o de caire educatiu. Obtenim el fitxer iaik_jec_full.jar que és la versió completa signada, enllaç iaik-jce.. ●. Descarregar les polítiques de seguretat de Java que permeten emprar qualsevol longitud de clau, Java Cryptography Extension (JCE) Unlimited Strength Jurisdiccion Policy Files 5.0 RC.. ●. (Windows) Copiar l'arxiu iaik_jce_full.jar als directoris.  c:\Archivos de Programa\Java\jdk1.5.0\jre\lib\ext.  c:\Archivos de Programa\Java\jre1.5.0\lib\ext.. ●. (Linux) Copiar l'arxiu iaik_jce_full.jar al directori:  $JAVA_HOME/jre/lib/ext.. ●. (Windows) dins de l'arxiu jce_policy-1.5.0-beta2.zip hi ha els arxius: 20.

(21) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya.  local_policy.jar.  US_export_policy.jar ●. Copiar-los a:  c:\Archivos de Programa\Java\jdk1.5.0\jre\lib\security.  c:\Archivos de Programa\Java\jre1.5.0\lib\security.. ●. ●. (Linux) Dins de l'arxiu jce_policy-1.5.0-beta2.zip hi ha els arxius:  local_policy.jar.  US_export_policy.jar. Copiar-los a: $JAVA_HOME/jre/lib/security.. ●. Compilar i executar.. 21.

(22) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Capítol 3. Protocols criptogràfics.. 22.

(23) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Requisits de seguretat. A continuació es descriurà l'esquema criptogràfic implementat per a la gestió segura dels historials clínics dels pacients. El sistema permet els següents casos d'ús: ● ● ● ●. Autenticació per part dels usuaris (metges i/o pacients) en el sistema. Consulta d'una història clínica per part de metges o pacients. Consulta del llistat de pacients per part d'un metge. Inserció d'un nou apunt per part d'un metge en la història clínica d'un pacient.. Notació emprada en els protocols. La notació que farem servir per als protocols criptogràfics serà la següent: ●. K: clau d'un criptosistema simètric.. ●. Ek(M): Xifratge simètric d'un missatge M amb la clau K.. ●. DK(C): Desxifratge simètric del criptograma C amb la clau K.. ●. (PEntitat, SEntitat): Parella de claus asimètriques propietats d'Entitat, on P correspon a la clau pública i S a la privada.. ●. SEntitat[M]: Signatura digital del missatge M amb la clau privada S d'Entitat.. ●. PEntitat[S]: Xifratge del missatge M amb la clau asimètrica pública Pentitat d'Entitat.. ●. H(M): Sortida d'una funció resum criptogràfica del missatge M, aquestes funcions reben el nom de funcions hash.. Autenticació en el sistema. Aquesta operació permet a un metge o a un pacient autenticar-se en el sistema. A continuació, presentem el protocol d'autenticació (protocol de NeedhamSchroeder) per al cas d'un usuari Pi i el gestor del sistema G. 1.. Pi realitza les operacions següents: 1. 2. 3.. 2.. Obtenir un valor de forma aleatòria Ni. Xifrar Ni i Ipi amb la clau pública G, EG(Ni, Ipi). Ipi és l'identificador de Pi. Enviar EG(Ni, Ipi) a G;. G realitza les operacions següents: 1. Desxifrar EG(Ni,Ipi) amb Sg i obtenir Ni i Ipi. 2. Obtenir el certificat de Pi amb Ipi. A partir del certificat obtindrà Ppi. 3. Obtenir un valor de forma aleatòria, Ng. 4. Xifrar Ni, Ng, Ig amb la clau pública Ppi de Pi, Epi(Ni, Ng, Ig).. 23.

(24) PFC – Seguretat en historials clínics 5.. Universitat Oberta de Catalunya. Enviar Epi (Ni, Ng, Ig) a Pi.. 3.. Pi realitza les operacions següents: 1. Desxifrar Epi(Ni, Ng, Ig) amb la clau privada Spi i obtenir Ng, Ni i Ig. 2. Xifrar Ng amb la clau pública Pg de G, Eg(Ng). 3. Enviar Eg(Ng) a G;. 4.. G realitza les operacions següents: 1. Desxifrar Eg(Ng) amb la clau privada Sg i obtenir N'g. 2. Si N'g == Ng, G i Pi, estan autenticats bilateralment.. Consulta d'un historial. Aquesta operació permet a un metge obtenir l'historial clínic d'un determinat pacient o un pacient obtenir el seu propi historial. Per a la consulta d'un historial s'executen els passos següents: ●. Pas 1. L'usuari (metge o pacient) s'autentica amb el sistema.. ●. Pas 2. L'usuari envia al gestor l'operació desitjada(“ConsultaHistorial”).. ●. Pas 3. El gestor, si l'usuari s'autentica correctament, obté l'historial clínic del pacient demanat, el desxifra amb la seva clau pública, el xifra amb la clau pública de l'usuari i li envia.. ●. Pas 4. L'usuari desxifrarà l'historial clínic rebut i validarà, per a cada entrada, els seus números de seqüència, les signatures digitals del Gestor i també del metge.. Protocol 1 1.. U realitza les operacions següents: (a) Executar el Procedure 1 amb la clau pública Pg i obtenir PG[Ni, Id_usuariu]; (b) Enviar Pg[Ni, Id_usuariu] a G;. 2.. G realitza les operacions següents:. (a) Executar el Procedure 2 amb PG[Ni, Id_usuarig]; (b) Enviar Pu[Ni, Ng, Id_usuarig] a U; 3.. Id_usuariu]. i. obtenir. PU[Ni,. NG,. U realitza les operacions següents: (a) Desxifrar Pu[Ni, Ng, Id_usuarig] amb la clau privada Su, i obtenir Ng, N'i i Id_usuariG; (b) Si Ni' == Ni fer: i. Xifrar NG, Consulta, Id_usuari amb la clau pública PG de G, PG[NG, Consulta, Id_usuari]. Consulta indica que es vol consultar l'historial de l'usuari identificat amb Id_usuari; ii. Enviar PG[NG, Consulta, Id_usuari] a G;. (c) Sinó, retornar error;. 4.. G realitza les operacions següents:. 24.

(25) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. (a) Desxifrar PG[NG, Consulta, Id_usuari] amb la clau privada SG, i obtenir N'G, Consulta, Id_usuari; (b) Recuperar GN de la BBDD. En el pas 4 del Procedure 2, NG i Ni han estat desats a la BBDD; (c) Si N'G == NG fer: i. Si (Id_usuariu == Id_usuari) o (Id_usuariu és metge i Id_usuari és un pacient de Id_usuariu) fer: A. Executar el Procedure 3 amb Id_usuari i Pu, i obtenir Pu[H]; B. Enviar Pu[H] a U. ii. Sinó, retornar error. (d) Sinó, retornar error. (e) Borrar NG i Ni de la BBDD:. 5.. U realitza les operacions següents: (a) Executar el Procedure 4 amb Pu[H], i obtenir H; (b) Mostrar H.. Procedure 1 (Pu) 1. 2. 3.. Obtenir un valor de forma aleatòria, Ni; Xifrar Ni i Id_usuariu amb la clau pública de G, Pg[Ni, Id_usuariu]; Enviar Pg[Ni, Id_usuariu] a G; Procedure 2 ( Pg(Ni, Id_usuariu)). 1. 2.. 3. 4. 5.. Desxifrar Pg[Ni, Id_usuariu] amb SG, i obtenir; Ni i Idusuariu; Obtenir el certificat U a partir de Id_usuariu. Suposem que el sistema disposa d'una Base de dades (BD) on per cada Id_usuari trobem el seu certificat corresponent. A partir del certificat es pot obtenir la clau pública Pu; Obtenir un valor de forma aleatòria, Ng; Guardar a la BD els valors Ni i Ng associats amb U; Xifrar Ni, Ng, Id_usuariG, amb la clau pública Pu de U, Pu[Ni, Ng, Id_usuariG]. Procedure 3 (id_usuari, Pu). 1. 2. 3. 4.. Buscar l'historial H corresponent a id_usuari; Desxifrar la part de H que està xifrada utilitzant la clau privada SG de G. Xifrar H amb la clau pública Pu, Pu[H]. Retornar Pu[H]. Procedure 4. 1. 2.. 3.. Desxifrar Pu[H] amb la clau privada Su de U, Su[Pu[H]]; Per cada entrada de l'historia H que està signada fer: (a) Verificar la signatura digital de M; (b) Verificar la signatura digital de G; (c) Verificar la seqüència; Retornar H.. Consulta dels pacients assignats a un metge. Aquest protocol implementa l'opció, per als metges, d'obtenir un llistat dels pacients que té assignats. 25.

(26) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Els passos seran els següents: ●. Pas 1. El metge s'autentica amb el sistema.. ●. Pas 2. El metge envia al gestor l'operació desitjada (“LlistatPacients”).. ●. Pas 3. El gestor, si el metge s'ha autenticat correctament, generarà un llistat dels pacients assignats al metge, signant cadascun d'ells amb la seva clau privada i xifrant després les dades amb la clau pública del metge.. ●. Pas 4. El metge rep el llistat que li tramet el gestor en el pas anterior, es desxifra utilitzant la seva clau privada i valida les signatures.. Protocol 2 1.. U realitza les operacions següents: (a) Executar el procedure 1 amb la clau pública Pu, i obtenir Pg[Ni, Id_usuariu]; (b) Enviar Pg[Ni, Id_usuariu] a G;. 2.. G realitza les operacions següents: (a) Executar Id_usuariG];. el. Procedure. 2. amb. PG[Ni,. Id_usuariu],. i. obtenir. Pu[Ni,. Ng,. (b) Enviar Pu[Ni, NG, Id_usuariG] a U;. 3.. U realitza les operacions següents: (a) Desxifrar Pu[Ni, Ng, Id_usuariG] amb la clau privada Su, i obtenir Ng, N'i i Id_usuariG; (b) Si Ni' = Ni fer: i. Xifrar NG i Llista_pacients amb la clau pública PG de G, PG[NG, Llista_pacients]. Llista_pacients indica que es vol un llistat dels identificadors d'usuari corresponents als pacients del metge identificat amb Id_usuariu; ii. Enviar PG[NG, Llista_pacients] a G;. (c) Sinó, retornar error;. 4.. G realitza les operacions següents:. (a) Desxifrar PG[NG, Llista_pacients] amb la clau privada SG, i obtenir N'g i Llista_pacients; (b) Recuperar NG de la BBDD. En el pas 4 del Procedure 4 NG i Ni han estat guardats a la BBDD; (c) Si N'G == Ng fer: i. Si Id_usuariu és metge fer: A. Executar el Procedure 5 amb Id_usuariu i Pu, i obtenir Pu[{Id_usuariu1,..., Id_usuarin} , SG[{Id_usuariu1, .... , Id_usuarin}]]; B. Enviar a U Pu[{Id_usuari1, .... , Id_usuarin}, Sg[{Id_usuari1, .... , Id_usuarin}]].. 26.

(27) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. (d) Sinó, retornar error; (e) Borrar Ng i Ni de la BBDD.. 5.. U realitza les operacions següents:. (a) Executar el Procedure 6 amb Pu[{Id_usuari1, ..., Id_usuarin}, Sg[{Id_usuari1, ...., Id_usuarin}]], i obtenir {Id_usuari1, ...., Id_usuarin}; (b) Mostrar {Id_usuari1, ...., Id_usuarin}.. Procedure 5 (Id_usuari, Pu). 1. 2. 3.. 4.. Cercar a la BBDD els pacients assignats al metge Id_usuari, obtenint {Id_usuari1, ..., Id_usuarin}; Signar {Id_usuari1,..., Id_usuarin} amb la clau privada SG de G, SG[{Id_usuari1,...., Id_usuarin}]; Xifrar {Id_usuari1, ... , Id_usuarin} i SG[{Id_usuari1, .... , Id_usuarin}] amb la clau pública de Id_usuari, Pu, Pu[{Id_usuari1,...., Id_usuarin} , SG[{Id_usuari1,...., Id_usuarin}]]. Retornar Pu [{Id_usuari1,..., Id_usuarin}, SG[{Id_usuari1,....,Id_usuarin}]].. Procedure Id_usuarin}))) 1.. 2. 3.. 6. (Pu({Id_usuari1,. ...,. Id_usuarin},. SG({Id_usuari1,....,. Desxifrar Pu[Sg[{Id_usuari1, .... , Id_usuarin}]] amb la clau privada Su de U, Su[Pu[SG[{Id_usuari1, .... , Id_usuarin}]]] i obtenir SG[{Id_usuari1,..., Id_usuarin}]; Verificar la signatura digital SG[{Id_usuari1, .... , Id_usuarin}] amb la clau pública PG de G; Si la verificació anterior és correcta retornar {Id_usuari1, ... , Id_usuarin}.. Inserció de dades a l'historial mèdic. Aquest protocol implementa l'opció, per als metges, d'introduir un nou apunt en l'historial clínic d'un determinat pacient. Els passos per a fer-ho son els següents: ●. Pas 1. El metge s'autentica amb el sistema.. ●. Pas 2. El metge signa l'apunt de la visita, que conté, almenys, l'identificador del pacient, el codi CIE9 amb el qual es relaciona el nou apunt i el seu apunt pròpiament dit.. ●. Pas 3. El metge envia al gestor l'apunt signat en el pas anterior.. ●. Pas 4. El gestor rep la informació que el metge li ha tramés en el punt anterior, la desxifra i s'assegura que qui li ha enviat la informació és realment un metge i que aquest apunt està relacionat amb un pacient que realment pertany a aquest metge.. ●. Pas 5. Si el pas anterior s'efectua correctament, el gestor xifrarà la informació i l'introduirà a la base de dades.. 27.

(28) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Protocol 3 1.. M realitza les operacions següents: (a) Executar el Procedure 1 amb la clau pública PM, i obtenir PG[Ni, Id_usuariM]; (b) Enviar PG[Ni, Id_usuariM] a G;. 2.. G realitza les operacions següents: (a) Executar el Procedure 2 amb PG[Ni, Id_usuariM], i obtenir Pu[Ni,NG, Id_usuariG]; (b) Enviar PM[Ni,NG, Id_usuariG] a M;. 3.. M realitza les operacions següents: (a) Desxifrar PM[Ni, Ng, Id_usuariG] amb la clau privada SM, i obtenir NG, N'i i Id_usuariG; (b) Si Ni' == Ni fer: i. Obtenir les dades de la visita V. La visita hauria d'incloure com a mínim Id_usuarip; ii. Signar V amb la clau privada SM de M, SM[V]; iii. Xifrar NG, V i SM[V] amb la clau pública PG de G, PG[NG, Inserir_visita, V, SM[V]]. Inserir_visita indica que es vol afegir V a l'historial del pacient P; iv. Enviar PG[NG, Inserir_visita, V, SM[V]] a G; (c) Sinó, retornar error.. 4.. G realitza les operacions següents:. (a) Desxifrar PG[NG, Inserir_visita, V, SM[V]] amb la clau privada SG, i obtenir N'G, Inserir_visita, V i SM[V]; (b) Recuperar NG de la BBDD. En el pas 4 del Procedure 4 Ng i Ni han estat guardats a la BBDD. (c) Si N'g = Ng fer: i. Obtenir Id_usuarip a partir de V; ii. Verificar que ld_usuariM és metge; iii. Verificar que Id_usuarip és un pacient assignat a Id_usuariM; iv. Si les verificacions anteriors són correctes fer: A. Verificar la signatura digital SM[V] amb la clau pública PM; B. Obtenir l'instant de temps actual T; C. Obtenir el número de sèrie X de la última visita de l'historial H del pacient Id_usuarip; D. Incrementar en una unitat X, X+1; E.. Signar. V,. SM[V],. T,. SG[V,SM[V],. 28. X+1,. amb. la. clau. privada. SG. de. G,.

(29) PFC – Seguretat en historials clínics F.. Xifrar. V. Universitat Oberta de Catalunya T, SM[V]. i. amb. la. clau. pública. SG. de. G,. X+1]; SG[X+1,. Id_usuarip]; H. Guardar a la BBDD PG[V, SM[V]], X+1, T, SG[V,SM[V], T, X+1] i SG[X+1, Id_usuarip]; v. Sinó, retornar error.. (d) Sinó, retornar error.. Diagrama de classes. Per a la implementació dels casos d'ús anteriors s'han generat les classes següents: ●. Usuari.java: Classe abstracta amb mètodes comuns a metges i pacients.. ●. Metge.java: Classe que hereda de Usuari i implementa les accions que pot efectuar un metge.. ●. Pacient.java: Classe que hereda de Usuari i implementa les acciones que pot efectuar un metge.. ●. gestor.java: Classe que implementa les accions de l'usuari del sistema.. ●. gestorBBDD.java: Classe que implementa procediments comuns per a interactuar amb la base de dades.. ●. gestorCripto.java: Classe que implementa procediments comuns per a efectuar les operacions criptogràfiques (xifrar, desxifrar, signar, verificar signatures digitals, entre d'altres).. ●. P12.java: Classe gestorCripto.java.. ●. Base64.java: Classe amb mètodes per a codificar i descodificar en base64. S'ha extret aquesta classe des de http://iharder.net/base64 i té una llicència de programari lliure.. que. representa. un. PKCS. A continuació, el diagrama de classes en format UML:. 29. i. l'empra. la. classe.


(31) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Capítol 4. Representació de les dades: XML.. 31.

(32) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Introducció Per a traspassar informació entre els diferents agents del sistema (metges, pacients i gestor) s'utilitzaran documents en format XML. XML és l'acrònim, en anglès, de eXtensible Markup Language (“llenguatge de marques extensible”) i és un metallenguatge extensible d'etiquetes desenvolupat per al World Wide Web Consortium (W3C). Es tracta d'una simplificació i adaptació del SGML i permet definir la gramàtica de llenguatges específics (de la mateixa manera que l'HTML és també un llenguatge definit per l'SGML). Per tant, l'XML no és realment un llenguatge en particular, sinó una manera de definir llenguatges per a diferents necessitats. Alguns d'aquests llenguatges que usen XML per a la seva definició son l'XHTML, SVG, MathML. L'XML no ha nascut solament per a la seva aplicació a Internet, sinó que es proposa com un estàndard per a l'intercanvi d'informació estructurada entre diferents plataformes. Es pot utilitzar en bases de dades, editors de text, fulles de càlcul i gairebé qualsevol altra cosa. Per a treballar en documents XML s'utilitzarà la llibreria pública JDOM. Definició dels documents en XML. A continuació, un llistat amb les especificacions de tots els documents en XML que s'han emprat per a transmetre informació entre els diferents actors. Procedure 1. <?xml version="1.0" encoding="UTF-8"?> <Pfchistorials> <Procedure1></Procedure1> </Pfchistorials>. L'element “Procedure1” conté la cadena xifrada amb la clau pública del Gestor G següent: Ni-Id_usuariu On Ni és un valor obtingut de forma aleatòria i Id_usuariu és l'identificador de l'usuari que inicia l'autentificació. El DTD d'aquest document serà el següent: <?xml version="1.0"?> <!DOCTYPE Procedure1 [ <!ELEMENT Pfchistorials <!ELEMENT Procedure1 ]>. (Procedure1)> (#PCDATA)>. Procedure 2 <?xml version="1.0" encoding="UTF-8"?> <Pfchistorials> <Procedure2></Procedure2> </Pfchistorials>. L'element “Procedure2” conté la cadena xifrada amb la clau pública de l'usuari U següent: 32.

(33) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Ni-Ng-Id_usuarig On Ng és també un valor obtingut de forma aleatòria. El DTD d'aquest document serà el següent: <?xml version="1.0"?> <!DOCTYPE Procedure2 [ <!ELEMENT Pfchistorials <!ELEMENT Procedure1 ]>. (Procedure1)> (#PCDATA)>. Pas 3 <?xml version="1.0" encoding="UTF-8"?> <Pfchistorials> <Pas3> </Pas3> </Pfchistorials>. L'element “Pas3” conté la cadena xifrada amb la clau pública de l'usuari U següent: Ng-Operació-Id_usuari. El DTD d'aquest document serà el següent: <?xml version="1.0"?> <!DOCTYPE Pas3 [ <!ELEMENT Pfchistorials <!ELEMENT Pas3 ]>. (Pas3)> (#PCDATA)>. HistoriaClínica El següent esquema de document en XML representa la història clínica d'un pacient: <?xml version="1.0" encoding="UTF-8"?> <Pfchistorials> <HistoriaClinica> <Diagnostic> <Pgvsmv></Pgvsmv> <Sgvsmvtx></Sgvsmvtx> <Sgxidusuarip></Sgxidusuarip> <X></X> <T></T> </Diagnostic> </HistoriaClinica> <Pacient></Pacient> </Pfchistorials>. L'element Pacient conté l'identificador del pacient del qual s'està trametent la història clínica. L'element “HistoriaClinica” conté la història clínica del pacient. Aquest element pot contenir diversos elements “Diagnostic” amb els elements següents:. 33.

(34) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. ●. Pgvsmv: Conté la cadena següent: “codiCie-apuntsignatura_de_l'apunt” xifrada amb la clau pública del destinatari.. ●. Sgvsmvtx: Conté la cadena següent: “nhc_pacient-codiCie-apuntsignatura-tActual-numSerieX” xifrada amb la clau pública del destinatari.. ●. Sgxidusuarip: Conté la cadena “identificador_pacient-X”, signada amb la clau privada del Gestor i xifrada amb la clau pública del destinatari.. ●. X: Número de sèrie de l'apunt.. ●. T: Conté una cadena que representa el temps actual.. Llistat de malalties segons el codi CIE-9 A continuació, l'esquema XML que s'emprarà per a que el gestor retorni un llistat de les malalties i de les seves codificacions segons la codificació del CIE-9. <?xml version="1.0" encoding="UTF-8"?> <Pfchistorials> <LlistatCIE9> <CodiCIE> <Codi>521.2</Codi> <Descripcio> ABRASIO DENTAL; ABRASIO: PER DENTIFRIC,H </Descripcio> </CodiCIE> <CodiCIE> <Codi>910.1</Codi> <Descripcio> ABRASIO O CREMADA PER FRIC.CARA[ULL NO], </Descripcio> </CodiCIE>. Document per a les dades administratives d'un pacient Aquest document en XML conté les dades administratives d'un determinat pacient identificat per el seu número d'història clínica (NHC). <?xml version="1.0" encoding="UTF-8"?> <Pfchistorials> <Dades_Admin_Pacient> <nhc></nhc> <dni></dni> <tis></tis> <nss></nss> <nom></nom> <cognom1></cognom1> <cognom2></cognom2> <correue></correue> </Dades_Admin_Pacient> </Pfchistorials>. El contingut de tots els nodes va xifrat amb la clau pública del destinatari, de manera que solament aquest hauria de poder llegir el contingut d'aquest document. 34.

(35) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Llistat de Pacients A continuació, l'esquema XML que s'emprarà per a que el gestor retorni als metges un llistat amb els seus pacients assignats: <?xml version="1.0" encoding="UTF-8"?> <Pfchistorials> <Llista_pacients> <Pacient> </Pacient> <Signatura> </Signatura> </Llista_pacients> </Pfchistorials>. On l'element Pacient contindrà el nom del pacient xifrat amb la clau pública del destinatari del document. L'element Signatura contindrà la signatura del nom del pacient creada a partir de la clau privada del Gestor.. 35.

(36) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Capítol 5. Comunicació entre agents: RMI.. 36.

(37) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Introducció. La comunicació dels diferents actors i components del sistema és una part essencial del projecte. Tants els pacients com els professionals mèdics (metges) han de poder accedir de forma remota als historials clínics de forma remota sobre una xarxa de comunicacions. A més, els professionals mèdics han de poder visualitzar un llistat dels pacients que tenen assignats i també afegir nous apunts en les històries clíniques dels seus pacients. Evidentment, la base de dades tant de pacients, metges, i dels seus historials clínics està centralitzada i protegida mitjançant xifrat. La comunicació dels diferents components del sistema tradicionalment suposaria el disseny d’un protocol o mecanisme de comunicació. Per evitar la sobrecàrrega de feina, i donat que la part essencial és l’esquema criptogràfic es va optar per la utilització de la tecnologia RMI. RMI correspon a l'acrònim de Remote Method Invocation. Java incorpora aquesta tecnologia en la seva API estàndard. RMI consta d’un servidor on s’executen diferents instàncies de les classes servidores que es necessiten. Les aplicacions que volen emprar els mètodes remots únicament necessiten saber la interfície del servidor, és a dir, els mètodes que ofereix la classe que està en servidor. La implementació d’aquesta interfície restarà oculta i el client no arriba mai a saber que és el que s’està executant. En el projecte s’ha utilitzat RMI per a comunicar els aplicatius de pacients i metges amb el gestor del sistema. Tota la informació que s’envia entre aquests diferents actors es realitza a través d'aquesta tecnologia RMI. La utilització de RMI ha reduït notablement el temps de desenvolupament, en contraposició a haver implementat un protocol des de zero emprant sockets o webservices. Mètodes accessibles públicament al gestor. Els mètodes als quals es poden accedir de forma remota en el gestor del sistema es defineixen a través d'una interfície, continguda en el fitxer GestorInterRemot.java. En aquest cas s'han definit els mètodes següents per a que siguin públicament accessibles: Document_XML procedure2 ( Document_XML) booleà pas 4 (Document_XML) booleà verPacMetge (Pacient, metge) Document_XML procedure3 ( Pacient, Metge) Document_XML procedure5 (id_usuari) booleà pas4InserirVisita (Apunt) Document_XML retornaLlistatCIE() Document_XML getDadesAdminPacient( us_desti, us_origen). A continuació, una explicació més detallada sobre què implementa cada mètode:. 37.

(38) PFC – Seguretat en historials clínics ●. Universitat Oberta de Catalunya. Document procedure2( org.jdom.Document a ) Aquest procediment, que s'executa en el gestor, implementa la part del sistema d'autenticació del protocol de Needham-Schroeder entre aquesta entitat i els pacients i/o metges.. ●. boolean pas4( org.jdom.Document c ) Aquest procediment implementa en el gestor el pas 4 del protocol 2.. ●. boolean verPacMetge( String pacient , String metge ). Aquest procediment determina si el pacient “pacient” està assignat, o no, a un determinat metge. El mètode retornarà “cert” si és el cas o “fals” en cas contrari.. ●. Document procedure3 ( String pacient , String metge ). El procedure3 és l'encarregat de retornar la història clínica d'un determinat pacient a partir de l'identificador d'usuari “Pacient” i l'identificador del “Metge” (o propi pacient) que demana l'historial.. ●. Document procedure5 ( String id_usuari ). Aquest procediment implementat en el servidor és l'encarregat de retornar un llistat de pacients assignats al metge en qüestió, identificat pel paràmetre “id_usuari”. ●. boolean pas4InserirVisita ( String a ) Aquest procediment implementa el pas 4 del protocol 3.. ●. Document retornaLlistatCIE () Aquest mètode retornarà un document en format XML amb un llistat de malalties amb el nom o descripció de la malaltia i també amb el codi CIE-9 associat a la malaltia. Aquest document no viatjarà xifrat i és que no conté informació sensible, sinó pública.. ●. Document getDadesAdminPacient ( String id_usuari_vull , String id_usuari_peticio ). El mètode getDadesAdministratives s'encarrega de retornar les dades administratives d'un determinat pacient a partir del seu identificador.. 38.

(39) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Capítol 6. Gestor de base de dades.. 39.

(40) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Introducció Per a que aquest sistema descrit funcioni correctament és necessari un sistema gestor de base de dades per a emmagatzemar tota la informació. En concret, els certificats d'usuari, les històries clíniques dels pacients, les dades administratives dels pacients, entre d'altres. Les dades del sistema s'emmagatzemaran en un sistema gestor de base de dades. El servidor escollir serà MySQL, disponible com a programari lliure. Comentar que, malgrat a la documentació es proposa realitzar la identificació dels usuaris a través del seu DNI (Document Nacional d'identitat) o a través del seu número de seguretat social (N.S.S), en aquest projecte, per a identificar els pacients emprarem un número, que denominarem NHC (Número d'història Clínica). S'ha escollit aquest sistema com a mètode per a identificar pacients a causa del fet que en un centre sanitari poden passar-hi persones que no disposen de cap d'aquests dos números, però que, en canvi, s'han de visitar. Pot ser el cas, per exemple d'immigrants o persones desplaçades (que, malgrat tot, poden tenir NIE o Passaport o no tenir res) . Com a identificador dels professionals sanitaris s'ha decidit emprar el seu número de col·legiat. Comentar finalment que el fitxer complet amb totes les taules i dades d'inicialització està en la carpeta src/pfchistorials.sql. Descripció de les taules A continuació, la descripció de cada una de les taules. Cada camp que actua com a clau primària, apareix de forma subratllada. Taula dtcertificats: Conté els certificats dels usuaris. idusuari: Conté l'identificador de l'usuari certificat: Conté el certificat de l'usuari Taula dtcodCIE9: Conté una relació de les malalties codificades segons el CIE-9. codicie: Conté el codi CIE descrip: Conté la descripció del codi CIE. Taula dtdiagnostics: Aquesta taula conté els diagnòstics per a cada pacient. Camp nhcpacient: Conté l'identificador de l'usuari. numseriex: Conté el número de sèrie X. instanttemps: Conté l'instant de temps. pgvsmv: Sgvsmvtx: sgxidusuarip: Taula dtmetges: Aquesta taula conté els metges disponibles en el sistema. numcolegiat: Conté el número de col·legiat del metge. 40.

(41) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. nom: Conté el nom del metge. cognom1: Conté el primer cognom del metge. cognom2: Conté el segon cognom del metge. correue: Conté el correu electrònic del metge. telf: Conté el telèfon de contacte del metge. Taula dtpacients: Aquesta taula conté la informació dels pacients del sistema. nhc: Conté l'identificador del pacient (acrònim de número d'història clínica). Dni: Conté un document d'identificació nacional. Tis: Conté el número de la targeta sanitària. Nss: Conté el número de la seguretat social. Nom: Conté el nom del pacient. Cognom1: Conté el primer cognom del pacient. Cognom2: Conté el segon cognom del pacient. Correue: Conté el correu electrònic del pacient. Telf: Conté el telèfon de contacta amb el pacient. Direccio: Conté l'adreça de residència habitual del pacient. Codipostal: Conté el codi postal de la població de residència habitual del pacient. Poblacio: Conté el nom de la població de residència habitual del pacient. Metgeassignat: Conté el número de col·legiat del metge que té assignat. Datanaixement: Conté la data de naixement del pacient. Sexe: Conté el sexe del pacient. Taula dtsessionsges: Conté els números aleatoris generats pels usuaris i el gestor durant l'autenticació. Nhc: Identificador del pacient. Ni: Ni. Ng: Ng.. Diagrama entitat-relació El diagrama entitat-relació de les taules comentades anteriorment és el següent:. 41.

(42) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Illustration 1: Diagrama entitat-relació de la base de dades. 42.

(43) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Capítol 7. Interfície gràfica.. 43.

(44) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Introducció La darrera part de la implementació era el disseny de les interfícies d'usuari: El sistema per a que els diferents actors del sistema puguin desenvolupar i executar totes les operacions anteriors de la forma més còmoda i intuïtiva possible. El disseny de les interfícies d'usuari s'han realitzat amb el programari NetBeans. Malgrat es varen avaluar altres alternatives (ex. Eclipse), em semblà que estava més còmode amb NetBeans, em va semblà que era igual d'intuïtiu i a més, es tracta de programari lliure també. NetBeans és pot http://www.netbeans.org.. descarregar. gratuïtament. a. través. de. l'adreça:. En la carpeta /project/ s'han deixat els fitxers en XML amb l'extensió .form que representen les interfícies d'usuari que es presentaran a continuació. Interfície d'usuari per als clients. La primera interfície gràfica que s'ha dissenyat és per als diferents clients del sistema: Pacients i professionals sanitaris. La primera pantalla que apareix és per a autenticar l'usuari en el sistema i per a determinar si es tracta d'un pacient o un professional sanitari. A més del fitxer P12 i la contrasenya per a identificar l'usuari, serà necessari definir també la direcció IP de la màquina on s'executa el gestor i el seu port RMI. Aquesta interfície està implementada en el fitxer pfcGuiLogin.form.. Illustration 2: Pantalla d'entrada. En funció de si l'usuari que s'ha introduït és un pacient o un professional sanitari, apareixerà una interfície o una altra. A continuació, la interfície d'usuari per als pacients:. 44.

(45) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Illustration 3: Vista principal per als pacients Com podem observar en la il·lustració anterior, aquesta pantalla mostra la informació següent: ●. ● ●. En la part superioresquerra un quadre amb les dades de tipus administratiu del pacient. En concret: Número d'història clínica del pacient, DNI, TIS, nom i cognoms i adreça postal. En la part esquerra un arbre amb el títol i codi CIE-9 de tots els episodis oberts. En la part dreta un quadre on mostra l'apunt en concret per a cadascun dels diferents episodis oberts.. Els dos botons que apareixen en el formulari (“Mostra HC” i “Sortir”) serveixen, respectivament, per a mostrar la història clínica i per a sortir del programa. Aquesta interfície està implementada en el fitxer pfcHistorialGuiPacient.form.. A continuació, la interfície d'usuari per als professionals sanitaris:. 45.

(46) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Illustration 4: Pantalla principal per als professionals sanitaris Aquesta pantalla està implementada en el fitxer pfcHistorialGuiMetge.form. El botó “Llista Pacients” obre un formulari on apareix un llistat amb els noms i els identificadors dels seus pacients assignats:. Illustration 5: Llistat de pacients, amb el seu nom i identificador Aquí és possible seleccionar a un dels pacients per a poder visualitzar a continuació la seva història clínica. Aquesta interfície està definida en el fitxer pfcGuiLlistaPacients.form.. 46.

(47) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. També ha de ser possible afegir un nou apunt en l'historial clínic d'aquest pacient. Cada apunt s'associa a un codi CIE-9:. Illustration 6: Pantalla per a afegir un nou apunt en la història clínica d'un pacient. Aquesta interfície està implementada en el fitxer pfcGuiAfegeixApunt.form. S'ha afegit també un formulari per a cercar malalties codificades segons l'estàndard internacional CIE-9:. Illustration 7: Llistat de malalties segons la codificació CIE-9 Aquesta interfície està implementada en el fitxer pfcGuiCodisCIE.form.. 47.

(48) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Execució del client Per a executar el client és necessari solament executar la instrucció: ./executaClient.sh Que no fa més sinó executar la següent classe en Java: $JAVA_HOME/bin/java pfcGuiLogin & Interfície d'usuari per al gestor del sistema. El gestor del sistema també disposa d'una interfície gràfica per a poder realitzar les seves operacions: Bàsicament per a Iniciar/aturar el servei. També seria interessant afegir la possibilitat de crear nous usuaris (ja siguin pacients o professionals sanitaris), malgrat no s'ha disposat de més temps per a poder realitzar aquesta millora. La interfície principal per al gestor és la següent:. Illustration 8: Pantalla principal per al gestor A través d'aquest formulari, s'ha d'establir el port RMI on desitjarem que s'executi el servidor i també escollirem el fitxer P12 i la contrasenya per a poder identificar al Gestor. Aquesta interfície està implementada en el fitxer pfcGuiGestor.form.. 48.

(49) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Illustration 9: Quadre per a cercar el fitxer P12 que identifica al gestor. El programa també ofereix la possibilitat d'afegir en el sistema un nou pacient. Quan es fa clic sobre el botó del formulari principal “Afegeix pacient” apareix un formulari similar al següent:. Illustration 10: Formulari per a afegir un nou pacient en el sistema.. Comentar que aquesta funcionalitat NO ha estat implementada però que es deixa indicat l'aspecte que hauria de tenir. Aquesta interfície pfcGuiGestorNewPacient.form.. està. implementada. 49. en. el. fitxer.

(50) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. De manera similar als pacients, hauria d'existir un formulari per a afegir nous professionals en el sistema, però que tampoc NO ha estat implementada. Execució del gestor Per a executar el gestor del sistema, executem les comandes següents: cd bin/ ./executaGestor.sh port-rmi A continuació, el guió de seqüències executaGestor.sh:. #!/bin/bash echo "PFC - Historials - Execució del Gestor..." if [ ! -n "$1" ] then echo "Us: `basename $0` port-RMI (ex. `basename $0` 2099)" exit 0 fi if [ ! -n "$JAVA_HOME" ] then echo "Definiu la variable JAVA_HOME per a poder executar el programa gestor" exit 0 fi echo "Executem Gestor en el port RMI " $1 APP_PATH="/home/gerard/pfc-historials/entrega/bin/" $JAVA_HOME/bin/rmiregistry $1 & $JAVA_HOME/bin/java -classpath lib/iaik_jce_full.jar:lib/jdom.jar:lib/mysql-conn ector-java-5.0.7-bin.jar:$APP_PATH pfcGuiGestor $1. 50.

(51) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Capítol 8. Jocs de proves. 51.

(52) PFC – Seguretat en historials clínics. Universitat Oberta de Catalunya. Introducció L'objectiu del joc de proves és donar un exemple de la configuració i l'execució completa del sistema presentat. En aquest capítol es mostra com crear els certificats dels usuaris, la configuració de la base de dades, l'execució del servidor RMI i un exemple concret d'autenticació, accés a la història clínica d'una pacient per part d'un professional sanitari, l'accés al llistat dels seus pacients i la introducció d'un nou apunt. Generació dels certificats El primer pas és la preparació dels arxius necessaris pels usuaris de l'aplicatiu. El primer que s'ha de preparar és el certificats autosignat de l'entitat certificadora. Per a dur a terme aquesta tasca s'empraran els arxius de comandes que s'han comentat en el capítol corresponent. Totes les contrasenyes que introduïm serà sempre la mateixa: “uoc07”. Adjunt a aquesta memòria s'ha subministrat un directori anomenat PKI que conté l'estructura de carpetes preparada per a dur a terme la tasca següent. Es recomana ubicar-se en la carpeta “pki/bin” per a executar els guions de següencies de forma més còmoda. Per a crear les claus per a la autoritat certificadora amb una longitud de 2048 bits i després generar un certificat autosignat farem el següent: ./generarClaus CA.key 2048 Obtindrem un fitxer anomenat CA.key que conté la parella de claus de la CA. A continuació, generarem un certificat autosignat per a la CA. Executem la comanda següent: ./generaCertificatAutosignat CA.key CA.crt 365 El paràmetre 365 es refereix al total de dies que aquest certificat serà vàlid. Durant l'execució d'aquesta comanda es demanarà, a més, que s'introdueixin totes les dades per a poder identificar la CA. S'han utilitzat els següents: ● ● ● ● ● ● ●. Country Name: ES State or Province Name: Lleida. Locality Name: Solsona. Organization Name: UOC. Organization Unit Name: UOC. Common Name: Entitat Certificadora. Email: [email protected]. Per pantalla, apareix quelcom similar al següent:. 52.