Capítulo 8. Implementación realizada

Transcripción

1 Capítulo 8. Implementación realizada 8.1 Introducción En esta sección se describe el sistema de firma digital desarrollado. En primer lugar se realiza el análisis del mismo identificando los subsistemas que lo componen y desglosando su funcionalidad mediante casos de uso. Seguidamente se describe el diseño de la implementación, en el cual se especifican las tecnologías utilizadas, las clases que componen cada subsistema así como la interacción entre dichas clases que describe tanto el proceso de firma como el de verificación. La aplicación Java de firma digital XML desarrollada en este proyecto se basa en tres puntos fundamentales: Generación al vuelo. El documento XML de entrada se analiza mediante eventos. En cada paso del análisis, se obtiene la información relacionada con un evento del documento de entrada, se procesa para la obtención de la firma y se genera dicho evento en el documento de salida. Con este procesamiento se evita almacenar el documento de entrada completo en memoria y se mejora la velocidad en la generación de la salida ya que con una sola lectura del documento XML de entrada se obtienen los datos necesarios para la firma y se genera la salida. <Datos1 id= 1 > <Datos1 id= 1 > <Nombre> Miguel </Nombre>... </Datos> Procesado <Datos1 id= 1 > Siguiente evento? Figura 8.1 Procesado del documento XML Canonización a medida. La canonización es una vía de estandarización de la sintaxis XML que permite obtener una representación del documento 89

2 independiente de las distintas formas superficiales que permite XML para representar una misma información. Por ejemplo, existen varios caracteres para representar el final de una línea y si durante la generación de la firma se toma representación distinta de la que se tome en el proceso de verificación puede provocar que la firma no se tome como válida. Existen diversas herramientas para la canonización de un documento XML pero ninguna se adapta a los requisitos de la implementación ya que o bien necesitan que el documento se almacene por completo en memoria, o bien necesitan una lectura del documento de entrada para generar la salida canonizada lo que provocaría que se tuviese que leer dos veces el documento para generar la firma, una para calcular la representación canonizada de la entrada y otra para calcular la firma sobre la versión canonizada. Esto ha provocado que para este proyecto se defina e implemente una canonización del documento que también se realice conforme se leen los eventos correspondientes del documento de entrada, de la misma forma que se genera la firma y la salida. Algoritmos de cifrado ligeros. En el proceso de generación y verificación de una firma digital se utilizan dos tipos de algoritmos criptográficos. El primero de ellos de resumen o digest permite transformar textos de longitud variable a textos cifrados de tamaño fijo sin emplear claves. El segundo es un algoritmo que proporciona un texto cifrado de la misma longitud que el texto original. Como algoritmo de resumen, en principio se decidió utilizar MD5 por su prestaciones de velocidad, sin embargo, ante el descubrimiento de que este algoritmo había sido hackeado, se ha optado por usar el algoritmo SHA-1 para calcular el digest de los datos a firmar. En cuanto al algoritmo de cifrado de dicho resumen, en la recomendación de firma digital del W3C se propone usar el algoritmo de clave pública RSA, sin embargo, para dotar de una mayor simplicidad y rapidez a la implementación se ha seleccionado el algoritmo de clave secreta Rijndael (estándar AES) para cifrar el resumen calculado. 8.2 Análisis del sistema de firma digital XML Identificación de subsistemas La implementación se divide en dos subsistemas independientes. El primero de ellos desarrolla la generación de la firma mientras el segundo es un módulo de verificación de documentos firmados. Ambos módulos hacen uso de un API desarrollado para crear los objetos que representan la firma y que realiza los correspondientes cálculos para generar y validar firmas. Estos subsistemas pueden identificarse en el siguiente diagrama de paquetes: 90

3 Figura 8.1 Identificación de subsistemas Análisis del subsistema de firma El caso de uso o funcionalidad que ofrece el sistema es la firma de un documento. Esto se puede dividir en los siguientes casos de uso incluidos en el principal: Leer documento de entrada. El sistema realiza la lectura del documento para obtener la información a firmar y generar el documento de salida firmado. Canonización de la entrada. Se realiza un procesado de la información con el objetivo de obtener una representación XML estándar independiente de la representación superficial de los datos. Calcular el resumen. Mediante el algoritmo de cálculo de hash SHA-1 se obtiene un resumen de la información a firmar de una longitud igual a 160 bits. Cifrar el elemento SignedInfo. Se forma el elemento XML SignedInfo que incluye el método de canonización utilizado, el método de firma, una referencia que identifica qué información se firma, las transformaciones efectuadas al documento para obtener la firma, el método de resumen y el valor del mismo. Todo el elemento es cifrado mediante AES obteniéndose el valor de la firma. Generar documento firmado y canonizado. La última funcionalidad del subsistema es la generación de un documento XML que incluye la información de entrada y la firma en el formato especificado. 91

4 El diagrama de casos de uso que se muestra a continuación describe las funcionalidades que el subsistema de firma ofrece al actor que para este subsistema es el firmante. Figura 8.2 Casos de uso del subsistema de firma Análisis del subsistema de validación El subsistema de validación de firma ofrece como funcionalidad principal la comprobación de la autenticidad de una firma. Este caso de uso se puede dividir en diferentes acciones que se llevan a cabo en este proceso y que se muestran en el siguiente diagrama: 92

5 Figura 8.3 Casos de uso del subsistema de validación El primer paso del proceso de verificación es la lectura y procesado del documento de entrada para obtener el elemento XML Signature comprobando que sigue una correcta estructura y almacenando los valores de resumen y firma para su validación. A continuación se procede a la validación de la referencia mediante las siguientes operaciones: Leer documento de entrada. Se realiza una segunda lectura del documento de entrada para obtener la información firmada y poder recalcular el resumen. Canonización de la entrada. Al igual que en e proceso de firma se debe procesar la información de entrada para obtener su representación estándar o de lo contrario podría fallar la verificación por variaciones en la representación superficial del documento XML. Calcular el resumen. Los datos canonizados son procesados mediante el 93

6 algoritmo de resumen SHA-1 obteniendo un valor de hash de longitud igual a 160 bits de manera análoga al proceso de firma. Comparar valor de firma calculado y recibido. Por último se comparan byte a byte los valores de resumen obtenido del documento y calculado. Si los valores coinciden la referencia es válida, es caso contrario se finaliza el proceso de verificación concluyendo que la firma no es válida. Si el proceso de verificación de la referencia finaliza con éxito se procede a la verificación de la firma como se detalla a continuación: Cifrar elemento SignedInfo. Se forma el elemento XML SignedInfo y se cifra mediante al algoritmo AES obteniendo el valor de la firma. Comparar valor de firma calculado y recibido. Por último se comparan byte a byte el valor de firma calculado y el obtenido del documento para concluir que la firma es correcta si ambos valores coinciden. 8.3 Diseño del sistema de firma XML implementado La aplicación de firma digital XML ha sido desarrollada mediante tecnología Java J2SE por lo que podrá ser usada en cualquier plataforma. Para la representación de datos se usa la sintaxis universal XML que facilita la conexión con distintos sistemas que requieran el uso de firma digital. El análisis del documento y el parseado de XML a objetos y viceversa se realiza mediante el API de análisis de XML StAX. En primer lugar se describen las clases que forman el API de firma que es utilizado en los subsistemas de generación y de validación de la firma. A continuación se detalla el funcionamiento del subsistema generador de firma, las clases que lo componen y las operaciones que realiza utilizando diversas funcionalidades proporcionadas por el API. Por último, se analiza el subsistema de verificación de documentos firmados Diseño del API de firma El API de firma contiene clases que ofrecen métodos para la generación y validación de una firma digital. Sigue el modelo propuesto en la JSR 105 XML Digital Signature con las consiguientes modificaciones para conseguir una firma ligera con mínimos requisitos de memoria y capacidad de procesamiento. Está dividida en cuatro paquetes que se detallan a continuación. 94

7 Paquete castanedo.xml.crypto Este paquete contiene principalmente interfaces de las cuales heredan otras en el paquete castanedo.xml.crypto.dsig o bien son implementadas en dicho paquete directamente. Destacan la interfaz AlgorithMethod de la cual heredan las distintas interfaces que representan los distintos algoritmos de resumen, cifrado o canonización implementados y la clase KeySelector que permite indican el propósito con el que se usa una clave. El diagrama completo de clases que componen este paquete se puede ver en la siguiente figura: Figura 8.4 Diagrama de clases castanedo.xml.crypto A continuación se describe con mayor profundidad las clases e interfaces que componen este paquete. AlgorithmMethod Es una representación abstracta de un algoritmo definido en las especificaciones de seguridad XML. Las subclases representan tipos específicos de algoritmos de seguridad XML así como tipos Transform. KeySelector Clase abstracta para indicar el propósito del cifrado. Contiene la clase anidada Purpose que permite indicar dicho cometido de la clave. 95

8 Purpose Contiene atributos estáticos que permiten indicar el propósito con el que se usa una determinada clave. URIReference Interfaz que permite identificar un objeto de datos via URI-Reference, como se especifica en RFC URIReferenceClase Implementación de la interfaz URIReference. Recibe como parámetro del constructor un String URI al instanciarse. Con el método geturi() se puede recuperar este String. XMLCryptoContext Contiene información de contexto común para operaciones criptográficas XML. Ésta interfaz contiene métodos para establecer y recuperar propiedades que afectan al proceso de firma XML o a las estructuras XML encriptadas. Las instancias XMLCryptoContext pueden contener información y estado específico de la estructura criptográfica XML. Los resultados son impredecibles si un XMLCryptoContext se usa con múltiples estructuras (por ejemplo no se debe usar la misma instancia de XMLValidateContext para validar dos objetos XMLSignature diferentes). Paquete castanedo.xml.crypto.dsig Este paquete contiene todas las clases que representan a cada uno de los elementos que componen la firma por lo que es un paquete de gran relevancia en el desarrollo de la aplicación. Contiene la implementación de los algoritmos utilizados y las clases ReferenceClase y XMLSignatureclase que contienen métodos para calcular y verificar resúmenes de documentos y valores de firma respectivamente. Debido a su gran dimensión, el diagrama de clases se ha divido en varias figuras que muestran sus relaciones por lo que se irán alternando dichas figuras con la descripción de las clases que aparecen en la misma. 96

9 Figura Diagrama de clases castanedo.xml.crypto.dsig XMLSignatureFactory Factoría de firma. Crea objetos necesarios para el desarrollo de la firma del documento. El constructor es privado y sólo se podrá crear una instancia de la factoría. XMLSignature Interfaz que define la firma de una referencia. Declara métodos para calcular y validar la firma. SignatureValue Interfaz anidada de XMLSignature que encapsula el valor de la firma. XMLSignatureClase La clase XMLSignatureClase implementa la interfaz XMLSignature. Recibe como 97

10 parámetros del constructor un objeto de la clase KeyInfoClase y otro SignedInfoClase que encapsula un ReferenceClase que a su vez tiene un método para calcular el digest y devolverlo. También proporciona el método de firma. Tiene una clase anidada SignatureValueClase que sólo encapsula el byte[] con el valor de la firma. El método sign recibe como parámetro un XMLSignContext con la clave que se usa para cifrar el elemento SignedInfo calculando el valor de la firma. SignatureValueClase Clase anidada que encapsula el valor de la firma calculado. Transform Interfaz que define las transformaciones que se pueden realizar sobre un documento para obtener su firma. TransformClase Implementación de la interfaz Transform. 98

11 Figura Diagrama de clases castanedo.xml.crypto.dsig 99

12 XMLSignContext Interfaz que extiende XMLCryptoContext sin añadir ningún método. XMLSignContextClase La clase XMLSignContextClase implementa la interfaz XMLSignContext. Contiene el valor de la clave, el propósito de la misma y opcionalmente un valor uribase. XMLValidateContext Interfaz que extiende XMLCryptoContext sin añadir nuevos métodos a implementar. XMLValidateContextClase La clase XMLValidateContextClase implementa la interfaz XMLValidateContext. Contiene el valor de la clave, el propósito de la misma y opcionalmente un valor uribase. DigestMethod Interfaz que establece el método de resumen. DigestMethodClase Clase que representa el nombre de un algoritmo de resumen. Implementa la interfaz DigestMethod. Reference Interfaz que encapsula un objeto con el método de resumen a emplear. Permite calcular el resumen, y validar el resumen de un documento. ReferenceClase ReferenceClase implementa Reference que extiende URIReference. Contiene métodos para calcular el digest, leyendo el XML a partir de un flujo de entrada, aplicando las transformaciones necesarias incluida la canonización y generando simultáneamente el documento de salida. 100

13 Figura Diagrama de clases castanedo.xml.crypto.dsig DatosNombre Clase que almacena el nombre de un nodo y su espacio de nombres. Firma Interfaz que define constantes utilizadas en el proceso de firma o validación. CanonicalizationMethod Interfaz que define el método de canonización. En esta implementación se utiliza un método de canonización diseñado a medida denominado CANO_STAX, sin embargo, también se declaran como constantes los métodos de canonización propuestos en la especificación XML Digital Signature. CanonicalizationMethodClase Clase que establece el nombre del método de canonización a utilizar. Implementa la 101

14 interfaz CanonicalizationMethod. Figura Diagrama de clases castanedo.xml.crypto.dsig SignatureMethod Interfaz que establece el método de firma. Se define AES_SHA1 como método de firma, SHA1 para calcular el resumen y AES para el cifrado de SignedInfo. SignatureMethodClase Clase que representa el nombre de un algoritmo de firma. Implementa la interfaz SignatureMethod. SignedInfo Interfaz que encapsula una referencia, método de canonización y método de firma. Representa el elemento XML SignedInfo. 102

15 cd keyinfo Implementación realizada SignedInfoClase Clase SignedInfoClase que implementa la interfaz SignedInfo. Permite establecer (mediante parámetros del constructor) y a recuperar (mediante métodos) el método de firma y una referencia al documento xml que implementa un método para calcular el resumen. Paquete castanedo.xml.crypto.dsig.keyinfo El paquete keyinfo recoge herramientas de almacenamiento y descripción de claves. Está compuesto por dos interfaces y dos clases cuya descripción se muestra a continuación. KeyInfo La interfaz KeyInfo define el almacenamiento de información relacionada con la clave. KeyInfoClase Implementación de KeyInfo La información de la clave se recibe mediante ArrayList. Para obtener la información de éste objeto se usa el método getcontent(). «interface» KeyInfo «interface» KeyValue + getcontent() : ArrayList + getkey() : byte[] ~ KeyInfoClase content: ArrayList = null + getcontent() : ArrayList + KeyInfoClase(ArrayList) ~ KeyValueClase key: byte ([]) + getkey() : byte[] + KeyValueClase(byte[]) + KeyValueClase(byte[], int, int) Figura 8.6 Diagrama de clases castanedo.xml.crypto.dsig.keyinfo KeyValue Interfaz que define el almacenamiento del valor de la clave. KeyValueClase Implementación de la interfaz KeyValue. 103

16 Paquete castanedo.xml.crypto.dsig.stax Este paquete contiene clases que procesan información XML utilizando el analizador StAX. Ofrece funcionalidades como la lectura y generación de un documento, generación de firma o lectura de la firma de un documento. Las clases que lo componen se recogen en el siguiente diagrama: Figura 8.7 Diagrama de clases castanedo.xml.crypto.dsig.stax DatosFirma Clase que encapsula el elemento SignedInfo y el valor de la firma calculado a partir de dicho elemento. GeneradorSalida Lee el documento xml y genera el documento de salida añadiendo la firma calculada. Se usa para generación de firma en formato Enveloping ya que para los otros formatos Enveloped y Detached la salida se genera conforme se va analizando el documento de entrada para calcular el valor de la firma. LectorFirma Clase que contiene un método para leer documentos firmados y crear los objetos que 104

17 representan dicha firma. Parseador Parseador de elemento SignedInfo a lista de eventos Stax. Su único método public String creareventos(signedinfoclase si); recibe un objeto SignedInfoClase y devuelve un String con su representación XML Diseño del subsistema de firma La generación de la firma se realiza mediante la ejecución de la clase Firmar, la cual contiene el método principal main. Para firmar un documento es necesario indicar los siguientes parámetros se entrada: Documento de entrada. Nombre del documento XML que se desea firmar. Documento de salida. Nombre del documento XML que se genera incluyendo la firma. idfirmado. Atributo id del elemento del documento de entrada que se desea firmar. Si este parámetro se especifica vacío se firma el elemento raíz del documento. Formato de salida. Por último, es necesario especificar uno de los tres formatos para la generación del documento de salida. Los posibles valores son enveloped, enveloping y detached. En el siguiente diagrama de secuencia se recoge de manera resumida el proceso de generación de firma: 105

18 Figura 8.8 Diagrama de secuencia de Firma Como se especifica en el diagrama, los cuatro parámetros de entrada se utilizan para crear el objeto Java que representa al elemento XML SignedInfo. Esto se realiza mediante las siguientes líneas de código: FirmaXML fxml = new FirmaXML(); SignedInfoClase sigin = fxml.creasignedinfo(formato, docentrada, idfirmado, docsalida); Figura 8.9 Instancia del elemento SignedInfo La clase FirmaXML contiene métodos de generación de los principales elementos que intervienen en la firma digital: SignedInfo, XMLSignContenxt y el elemento Signature final. El primer paso en la generación de la firma es instanciar el objeto que se corresponde con el elemento SignedInfo de la firma. Para instanciar este y el resto de objetos representativos del elemento Signature se utiliza una factoría denominada XMLSignatureFactory. Este objeto será una instancia de la clase SignedInfoClase. Como se puede observar en la figura anterior, el elemento SignedInfo está formado por varios elementos hijo y análogamente, para instanciar un objeto SignedInfoClase es necesario haber instanciado antes los correspondientes objetos representativos de 106

19 los elementos hijo de SignedInfo que son los siguientes: CanonicalizationMethod. Para representar este elemento se instancia un objeto de la clase CanonicalizationMethodClase pasándole como parámetro al constructor el nombre del método de canonización a utilizar que para esta implementación se ha desarrollado a medida y se ha denominado SignatureMethod. Como el elemento anterior, para representar este elemento se instancia un objeto de la clase SignatureMethodClase pasándole como parámetro al constructor el nombre del método de firma a utilizar que para esta implementación se ha denominado Reference. Este elemento es de especial relevancia ya que encapsula el valor del resumen de los datos firmados entre otros elementos y la clase que lo representa y de la que se crea una instancia es ReferenceClase. Cabe destacar que al instanciar esta clase no se calcula el valor del digest ya que requeriría una lectura del documento de entrada sólo para el cálculo de este resumen y como se ha mencionado anteriormente se pretende que en una sola lectura de la entrada se genere toda la firma y el documento de salida por lo que primero se deben crear todos los objetos necesarios para la representación de la firma. Una vez creadas las instancias de SignedInfoClase y XMLSignContext se tienen todos los datos necesarios para el cálculo de la representación del elemento Signature al completo. Se procede entonces a crear una instancia de la clase XMLSignatureClase y mediante una llamada a su método sign(xmlsigncontext contxt, String formato ); se desencadena el proceso de cálculo de la firma que se muestra en el siguiente diagrama de secuencia: 107

20 Figura 8.10 Detalle del diagrama de secuencia de firma Para generar la firma se comienza por obtener un resumen de los datos a firmar mediante el método getdigestvalue() de ReferenceClase. Para ello se procede a la lectura del documento que a su vez irá canonizando la información de entrada y generando la salida canonizada. De este modo, cuando se finaliza la lectura del documento se ha obtenido toda la información necesaria de la entrada para calcular el resumen o digest y además se han generado a la salida los datos a firmar canonizados. Una vez que se ha calculado el valor del resumen se forma el elemento XML SignedInfo mediante el elemento creareventos(signedinfo) de la clase Parseador. A continuación se obtiene el valor de la clave para cifrar dicho elemento SignedInfo mediante el algoritmo RijndaelEngine resultando el valor de la firma buscado. En la figura se muestra como si el formato de firma especificado es Enveloping no es posible generar el documento de salida conforme se lee el documento de entrada y necesita dos lecturas del documento de entrada para generar el documento final. Esto es debido a que para este tipo de firma los datos firmados se añaden como elementos hijo al final del elemento Signature por lo que primero se debe volcar en la salida el elemento Signature y para ello es necesario haber calculado el valor del resumen y de la firma con anterioridad. Esto no es necesario para los formatos de firma restantes Enveloped y Detached ya que para estos, se pueden incluir n primer lugar en la salida los datos que se firman y posteriormente se añade la firma como elemento hijo en el caso de firma Enveloped y como un elemento hermano en el caso de una firma Detached. 108

21 Con estas características se puede concluir que los formatos Enveloped y Detached resultan más eficientes que el formato de firma Enveloping en esta implementación ya que para los dos primeros se puede generar la salida con una única lectura del documento de entrada mientras que para firma Enveloping son necesarias dos lecturas del documento, una para calcular la firma y otra para generar el documento de salida. Para terminar con la descripción de la generación de la firma se describe a continuación con mayor profundidad cómo se calcula el resumen del documento de entrada, analizándolo mediante eventos, canonizando la entrada, generando el evento en la salida si el formato de firma no es Enveloping y actualizando el resumen con la información de cada evento obtenido tal y como se recoge en la siguiente figura: 109

22 Mientras se lean eventos while (xsr.hasnext()) Se obtienen los datos. String evento = xsr.gettext(); Se calcula el resumen final Se canoniza el evento. resumen.dofinal(); formato! = ENVELOPING? Se genera el evento a la salida. xswsalida.writetext(evento); Se actualiza el resumen. resumen.update(evento.getbytes()); Figura 8.11 Cálculo del resumen Características de la canonización implementada Esta sección describe cómo se ha implementado la canonización del documento en busca de una representación estándar XML. Se presentan las distintas características que debe cumplir un documento canonizado y de qué forma se ha resuelto teniendo en cuenta las propiedades del analizador Stax utilizado: No se incluye la declaración xml. Para implementar esta característica se identifica cuándo se produce este tipo de eventos y no se actualiza el valor del resumen. 110

23 No se incluye DTD. De la misma forma que la característica anterior, se identifica el tipo de evento y no se actualiza el resumen cuando se produce. Se suprimen las líneas en blanco entre elementos. Se implementa controlando que cuando se produce un evento SPACE sólo se escriba un \n si se ha escrito el evento anterior. Se evitan SPACES seguidos. Primer carácter debe ser <. Se implementa controlando que el primer evento que se incluya sea START_ELEMENT. Esto se hace mediante la búsqueda del atributo id del elemento referenciado en el caso de detached o enveloping y mediante una bandera que controla si se ha encontrado el primer evento START_ELEMENT para el caso de firma enveloped. Conversión de elemento vacío a pareja comienzo-fin. Stax los identifica como eventos distintos por lo que se escriben de manera separada. Orden relativo en el elemento. Primero se solicitan al analizador los namespaces que aparecen en el elemento y a continuación los atributos. Atributos delimitados por. Se implementa formando la cadena canonizada correspondiente al atributo introduciendo este carácter como delimitador. Reemplazar los CDATA por caracteres. Sólo se usan los caracteres pertenecientes al elemento CDATA para actualizar el valor del resumen. Reemplazar referencias a entidades internas que estén presentes. Se realiza añadiendo la librería DTD-parser la cual implementa esta funcionalidad. Adición del atributo default. Se realiza añadiendo la librería DTD-parser la cual implementa esta funcionalidad. Codificar en UTF-8. Se implementa mediante un método denominado toutf8(string entrada); Ordenar atributos por orden lexicográfico. Se ha implementado una función recursiva aunque sencilla y rápida para ordenar los atributos. Reemplaza secuencias de espacios por carácter en blanco simple( ) en valores de atributo. Se ha implementado el método normalizar_espacios que elimina espacios en blanco consecutivos. Eliminar declaraciones de espacios de nombre superfluas o sobrantes. Se lleva un control de los espacios de nombre declarados en el árbol del documento y si en un elemento hijo se declara un espacio de nombres que aparece en algún antecesor suyo no se incluye para actualizar el resumen. Esto se realiza mediante el método escribir_namespaces(arraylist nombres, 111

24 XMLStreamReader xsr);. Al igual que los atributos, los espacios de nombre se ordenan lexicográficamente. Las siguientes características son inherentes al comportamiento del analizador StAX por lo que cuando se obtiene la información ya presenta dichas características: Pérdida de espacios en blanco entre la etiqueta PI y sus datos. Retener espacios en blanco entre etiquetas de inicio. Retener espacios en blanco entre etiquetas de final de elemento. Retener espacios en blanco entre etiquetas pareja. Retener espacios en blanco en contenido de caracteres. Codificación de caracteres especiales como referencias a caracteres en valores de atributo(&, <, ", &apos;). Codificación de caracteres especiales como referencias a caracteres en texto (&, <, >). Reemplaza el carácter tabulador TAB( ) por carácter en blanco simple ( ). Reemplaza el carácter INTRO ( ) por carácter en blanco simple( ). Sustitución de caracteres especiales (,, ) en valores de atributo tal y como se señala en la especificación de firma digital. A continuación se presentan las características de canonización que se proponen en C14N y que no se pueden implementar por diferentes motivos: Reemplazar las referencias a caracteres en texto. StAX no soporta referencia a caracteres de ida y vuelta, es decir, no produce error de lectura si aparecen estas referencias en el texto, pero tampoco es capaz de interpretarlas por lo que no produce ningún evento. Reemplazar referencias a entidades externas. No se realiza ya que StAX no implementa una resolución de entidades externas, sólo se define una interfaz que no está implementada. 112

25 8.3.2 Diseño del subsistema de validación El subsistema de validación consta de una clase principal Validar que contiene el método main(). En su ejecución, recibe como parámetro de entrada el documento firmado que se pretende validar. El proceso completo de validación se resume en el siguiente diagrama de secuencia: Figura 8.12 Diagrama de secuencia de validación En primer lugar se realiza una lectura del documento firmado para obtener el elemento Signature mediante el método leer() de la clase LectorFirma. Éste método identificará los diferentes elementos que conforman la firma e irá instanciando su correspondiente representación haciendo uso de la factoría de firma XMLSignatureFactory. Este detalle del proceso se recoge en el siguiente diagrama: 113

26 Figura 8.13 Detalle del diagrama de secuencia de validación En el diagrama se muestra cómo se van generando los distintos objetos conforme se realiza la lectura del documento y se identifica cada elemento en cuestión. De esta forma, cuando se finaliza la lectura del documento se ha obtenido la siguiente información de la firma que se pretende validar. Método de canonización. Método de firma. Método de resumen. Transformaciones a realizar al documento para la obtención de la firma. URI que identifica la información que se firma. Valor del resumen. Valor de la firma. Si no se encuentra alguno de estos elementos en el documento de entrada se muestra el correspondiente mensaje de error y se finaliza el proceso de validación. 114

27 En el caso de finalizar con éxito la lectura de la firma, se procede a la validación de la referencia mediante el método validate(xmlvalidatecontext xmlvc); de la clase instanciada durante la lectura ReferenceClase. Este método realiza los cálculos del valor del resumen de manera análoga a los realizados en proceso de firma mediante getdigestvalue(); y tras obtener el valor del resumen lo compara con el recibido en el documento y si ambos coinciden se da por válida la referencia. Tras validar el valor del resumen se instancia a través de la factoría de firma XMLSignatureFactory un objeto de la clase XMLSignatureClase pasándole como parámetros el elemento SignedInfo con la referencia validada y el valor de firma obtenido del documento de entrada y que se pretende validar. Mediante su método validate(xmlvalidatecontext xmlvc); se calcula el valor de la firma de la misma forma que se realiza en el proceso de firma con el método sign(); y se comparan ambos valores, calculado y leído del documento. Si son iguales se finaliza el proceso de validación con éxito mientras que si los valores difieren, se concluye que la firma no es válida. 115