EDItran - Firma XAdES-BES para TGSSmontilla.indra.es/doc/CICS/criptografia/EDXAdESUSIA.pdfEDItran - Firma XAdES-BES para TGSS zOS Manual de Usuario e Instalación Indra. Mayo - 2012

EDItran - Firma XAdES-BES para TGSS zOS

Manual de Usuario e Instalación

Indra. Mayo - 2012. EDXAdESUSIA.doc.

DOCUMENTO/ARCHIVO

Título: NombreArchivo/s:EDXAdESUSIA.doc Código: Soporte lógico: Documento Word 97 Fecha: Ubicación física:

/home/jumilla/editranxades/doc/os390/Doc. Tecnica

Versión: 0.1

REGISTRO DE CAMBIOS

Versión Páginas Motivo del cambio 0.1 10 Redacción inicial

DISTRIBUCIÓN DEL DOCUMENTO

Nombre Área Personal de EDItran Desarrollo

CONTROL DEL DOCUMENTO

PREPARADO REVISADO APROBADO ACEPTADO

Damián Menéndez Mejía Cumplimentar con el nombre, la firma y la fecha Sólo para clientes

Índice

Indra. Todos los derechos reservados 24/05/2012 Pag. I - 1

1. INTRODUCCIÓN ............................................................................................... 1-1

2. INSTALACIÓN Y REQUISITOS .......................... .............................................. 2-1

2.1. Requisitos de instalación. ..................................................................................................................... 2-1

2.2. Instalar en USS. .................................................................................................................................... 2-1

3. INSTALACIÓN CERTIFICADOS DE CAS DE TGSS ........... ............................ 3-1

3.1. Creación del keystore. .......................................................................................................................... 3-1

3.2. Incorporación de CAs al keystore. ...................................................................................................... 3-2

4. DEFINICIONES. INTERFAZ GRAFICA .................... ........................................ 4-1

4.1. Ficheros, Recursos cics. ........................................................................................................................ 4-1

4.2. EDItran/P. ............................................................................................................................................. 4-1 4.2.1. Sesión de transmisión EDItran/P (sólo CICS). .............................................................................. 4-1

4.3. EDItran/G. ............................................................................................................................................ 4-1 4.3.1. Sesión de presentación EDItran/G. ................................................................................................ 4-1

4.4. EDItran/FF. .......................................................................................................................................... 4-2 4.4.1. Entorno local EDItran/FF. ............................................................................................................. 4-2 4.4.2. Usuarios remotos EDItran/FF. ....................................................................................................... 4-3

4.4.2.1. ¿Cómo incluir el CN si no conocemos el mismo?. ............................................................... 4-5 4.4.3. Sesión de presentación EDItran/FF (parámetros generales). ......................................................... 4-8 4.4.4. Grupos asociados a Sesión de presentación EDItran/FF. ............................................................... 4-9 4.4.5. Usuarios asociados a Sesión de presentación EDItran/FF. .......................................................... 4-10 4.4.6. Consulta de la sesión de presentación EDItran/FF (firmantes). ................................................... 4-11

5. EJEMPLO PROCEDIMIENTO POSTERIOR A RECEPCION ....... ................... 5-1

5.1. Fichero de salida a la aplicación. ......................................................................................................... 5-4

5.2. Otras situaciones................................................................................................................................... 5-5

6. LOG EDITRAN/FF .................................... ........................................................ 6-1

7. ANEXO A ........................................... ............................................................... 7-1

7.1. Subir al USS el certificado de la CA ................................................................................................... 7-1

8. ANEXO B ........................................... ............................................................... 8-1

8.1. Códigos de Resultado del servidor ...................................................................................................... 8-1

1 INTRODUCCIÓN

Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 1-1

1. INTRODUCCIÓN

En este documento se describen las acciones necesarias para:

• Instalar EDItran/CD (en la parte USS del zos).

• Instalar certificados de las CA de la TGSS.

• Instalar EDItran/FF. Definiciones en la interfaz gráfica

• Proceso de descarga de un fichero -BES firmado. Modo de funcionamiento.

El módulo EDItran/FF-CD hasta la fecha, usaba sólo el formato PKCS#7. No obstante, en una primera fase, se implementa la funcionalidad -BES, para recibir ficheros firmados, validar los certificados y los firmantes y descargar.

En una primera fase:

� TGSS firmará ficheros de aplicación norma 34 en ASCII, con 2 firmantes, uno del grupo de gestores y otro del grupo de interventores, ambos bajo un certificado de la misma CA (si en el futuro hay más de una, no habría problemas). Enviará a las EEFF un fichero attach por cada transmisión (aunque pudieran ser más en un futuro). Este fichero es un XML ASCII base64 con el propio fichero de aplicación más las 2 firmas.

� En las EEFF, se definirá el grupo de tesoreros y el de gestores, cada uno de ellos con 3 posibles firmantes remotos (aunque el fichero sólo viene con una firma de cada uno de los grupos anteriores).

� Al recibir el fichero attach firmado, las EEFF en su proceso posterior a recepción:

o En un primer paso, descargarán el XML

o En un segundo paso, validarán que los firmantes pertenecen a los grupos descritos, que viene una firma de cada grupo, que son correctos los nombres y NIF de los firmantes y validarán el propio certificado. Una vez hecho esto, extraerán las firmas el fichero attach, quedando por tanto un fichero norma 34 en ASCII.

o En un último paso, se traducirá el fichero de aplicación de TGSS a EBCDIC y se formateará sobre un FB de LRECL=72, para que lo puedan tratar las aplicaciones de las EEFF, proporcionando además información (fichero ZTBFFSAL), sobre las validaciones de la firma.

� Las EEFF, con la información anterior, y con el tratamiento del fichero de aplicación, enviarán un fichero de confirmación (positivo o negativo), a TGSS sin firmar.

2 INSTALACIÓN y REQUISITOS


2. INSTALACIÓN y REQUISITOS

La verificación de firma que proporciona EDItran está desarrollada como un servidor en Java que será instalado en los servicios Unix del zOS.

2.1. Requisitos de instalación.

Se debe tener instalado, al menos, IBM 31-bit SDK for z/OS, Java Technology Edition, V6 y tener acceso al JZOS para el acceso a ficheros de MVS, los ficheros para ello se encuentran en $JAVA_HOME/lib/ext.

Con el fin de superar las limitaciones en el tamaño de las claves criptográficas que se utilicen en las firmas, se deben reemplazar los archivos de política restringidos US_export_policy.jar and local_policy.jar del directorio $JAVA_HOME/lib/security, con los que IBM entrega el SDK, por otros de versión no restringida que están en $JAVA_HOME/demo/jce/policy-files/unrestricted.

Un servidor TCP java, el cual debe disponer de una dirección y un puerto en el que escuchar las peticiones realizadas desde el EDItran en MVS.

Acceso a los servicios UNIX del ZOS.

Disponer de criptografía DES (para poder cifrar password).

Versión mínima EDItran V5R0F02.

2.2. Instalar en USS.

1. Se recomienda crear un directorio en la partición Unix de zOS (USS) para instalar el software de verificación de firma, por ejemplo: /u/editranxades

2. Enviar, en modo binario, al USS el paquete EDItranSignatureServicesZOS.tar. Puede usar cualquier utilidad de transferencia de ficheros, como el ftp (ejemplo en el punto 7).

3. Conectarse al USS y descomprimir el fichero dentro del directorio creado (u/editranxades>tar -xof EDItranSignatureServicesZOS.tar). Dejará esta estructura:

|-lib |---boot |-logs |-rsc |---truststore

En el ejemplo queda como sigue:



/u/editranxades: >ls -l total 17278 -rw-rw-r--+ 1 KI1056E KISNCE 8826880 Apr 26 17: 05 EDItranSignatureServicesZOS.tar -rwxrwxr-x+ 1 KI1056E KISNCE 132 Apr 27 10: 22 keystore.sh drwxrwxr-x+ 3 KI1056E KISNCE 832 Apr 24 10: 26 lib -rwxrwxr-x+ 1 KI1056E KISNCE 86 Apr 26 16: 49 listks.sh drwxrwxr-x+ 2 KI1056E KISNCE 256 Apr 27 10: 26 logs drwxrwxr-x+ 3 KI1056E KISNCE 448 Apr 24 10: 26 rsc -rwxrwxr-x+ 1 KI1056E KISNCE 867 Apr 24 10: 26 start.sh -rwxrwxr-x+ 1 KI1056E KISNCE 255 Apr 24 10: 26 stop.sh

Ahora podemos comprobar que los ficheros keystore.sh, listks.sh, start.sh y stop.sh tienen permisos de ejecución.

4. A continuación se edita el fichero start.sh y se da valor a las siguientes variables:

PWD= ruta de instalación, donde se ha descomprimido MEM_INI= memoria inicial destinada, en Megas MEM_MAX= memoria máxima destinada, en Megas IP= IP en la que arranca el servidor PORT= PUERTO en el que está escuchando el servidor JAVA_HOME= ruta de instalación de java

En nuestro ejemplo el fichero contiene las siguientes líneas:

PWD=/u/editranxades cd ${PWD} MEM_INI=1024 MEM_MAX=1024 IP="192.168.172.88" PORT="7775" JAVA_HOME="/usr/lpp/JAVA/J6.0"

5. Posteriormente se edita el fichero stop.sh dando valor a las siguientes variables

PWD= ruta de instalación, donde se ha descomprimido

En el ejemplo:

PWD=/u/editranxades

6. En la instalación se suministra un fichero con la clave pública de la TGSS, keystore, para la validación de los certificados firmantes: /u/editranxades/rsc/truststore/ trustStore.pfx . Este fichero tiene como contraseña “password”. Se recomienda crear un nuevo keystore en el que incorporar el fichero con la clave pública, que también se proporciona, u/editranxades/rsc/truststore/CA--TGSS.cer (véase el apdo. 3).

7. Una vez hecho esto ya es posible arrancar la aplicación ejecutando el comando:

./start.sh

Una vez arrancado el servidor se crea un fichero con el id del proceso: ThreadPooledServer.pid



Para comprobar que el Servidor ha arrancado correctamente una vez ejecutado el comando vemos el archivo logs/out.log, y debería tener las siguientes trazas (el puerto y la IP deberían ser las que hayamos configurado en el fichero). Ponemos el ejemplo: /u/editranxades: >cd logs /u/editranxades/logs: >cat out.log 24/04/2012 14:37:49,564 0 INFO [main] servers. ThreadPooledServer main - Starting Server 24/04/2012 14:37:49,610 46 INFO [Thread-3] ser vers.ThreadPooledServer openServerSocket - Port:7775 24/04/2012 14:37:49,611 47 INFO [Thread-3] ser vers.ThreadPooledServer openServerSocket - LocalSocketAddress:/192.168.172. 88:7775 24/04/2012 14:37:49,613 49 INFO [Thread-3] ser vers.ThreadPooledServer openServerSocket - InetAddress:/192.168.172.88

En caso de que ya estuviera arrancado (por el mismo usuario de USS) obtenemos la siguiente respuesta:

/u/editranxades: >./start.sh Error:The Server is already started

Si lo intentamos arrancar desde otro usuario, en el fichero de log veríamos: /u/ki64f6e/logs: >tail -f out.log 18/04/2012 12:17:06,229 29 ERROR [Thread-3] ser vers.ThreadPooledServer openServerSocket - Make sure the address is not in use. 18/04/2012 12:17:06,231 31 INFO [Thread-3] ser vers.ThreadPooledServer openServerSocket - Fichero de identificación del pr oceso eliminado correctamente 18/04/2012 15:49:32,375 0 INFO [main] servers .ThreadPooledServer main - Starting Server 18/04/2012 15:49:32,403 28 ERROR [Thread-3] ser vers.ThreadPooledServer openServerSocket - Error Starting Server. 18/04/2012 15:49:32,404 29 ERROR [Thread-3] ser vers.ThreadPooledServer openServerSocket - Make sure the address is not in use. 18/04/2012 15:49:32,408 33 INFO [Thread-3] ser vers.ThreadPooledServer openServerSocket - Fichero de identificación del pr oceso eliminado correctamente 24/04/2012 14:41:01,422 0 INFO [main] servers .ThreadPooledServer main - Starting Server 24/04/2012 14:41:01,453 31 ERROR [Thread-3] ser vers.ThreadPooledServer openServerSocket - Error Starting Server. 24/04/2012 14:41:01,454 32 ERROR [Thread-3] ser vers.ThreadPooledServer openServerSocket - Make sure the address is not in use. 24/04/2012 14:41:01,457 35 INFO [Thread-3] ser vers.ThreadPooledServer openServerSocket - Fichero de identificación del pr oceso eliminado correctamente

8. Para parar el proceso:

./stop.sh

Una vez finalizado se borrará el fichero: ThreadPooledServer.pid

3 INSTALACIÓN CERTIFICADOS de CAs de TGSS


3. INSTALACIÓN CERTIFICADOS de CAs de TGSS

3.1. Creación del keystore.

Para crear el almacén de certificados en el que, en principio, vamos a incluir las CAs de la TGSS, utilizaremos la herramienta keytool, proporcionada por IBM en su instalación del SDK for z/OS, Java Technology Edition (guía de uso en la dirección www.ibm.com/developerworks/java/jdk/security/60/secguides/keytoolDocs/keytool.html).

El keystore se creará de tipo PKCS12 incorporando el certificado que viene en el fichero u/editranxades/rsc/truststore/CA--TGSS.cer.

Para ello ejecutaremos:

./keystore.sh nombre_de_keystore

Ejemplo:

En la instalación que tenemos partimos de la siguiente situación:

/u/editranxades/rsc/truststore: >ls CA--TGSS.cer trustStore.pfx

Ejecutamos el siguiente comando:

/u/editranxades: >./keystore.sh claves.p12

Cuya respuesta es:

Enter keystore password:

Introduciremos la contraseña con la que queramos crear el keystore, que nos volverá a ser pedida:

Re-enter new password:

Nos mostrará información sobre el certificado y nos preguntará si es de confianza, a lo que contestaremos yes:

Owner: OU=SGI, O=Seg-social, C=ES Issuer: OU=SGI, O=Seg-social, C=ES Serial number: 3e4ce218 Valid from: 2/14/03 1:03 PM until: 2/14/23 1:33 PM Certificate fingerprints: MD5: 2E:25:DE:80:85:0C:CF:B0:B5:A5:ED:0D: F7:A4:44:DB SHA1: A6:7B:6A:93:09:70:66:93:CC:BE:F0:7E:B2:B1:59:C3:F4: BB:D9:AF Trust this certificate? [no]: yes

El proceso finaliza correctamente con esta respuesta:

Certificate was added to keystore

Para ver que se ha añadido el certificado correctamente podemos ejecutar el comando:

./listks.sh nombre_de_keystore

3 INSTALACIÓN CERTIFICADOS de CAs de TGSS


Siguiendo con nuestro ejemplo:

/u/editranxades: >./listks.sh claves.p12

Nos pedirá la contraseña con la que hemos creado el fichero

Enter keystore password:

Y obtenemos esta respuesta:

Keystore type: pkcs12 Keystore provider: IBMJCE Your keystore contains 1 entry tgssca1, Jan 1, 1970, trustedCertEntry, Certificate fingerprint (MD5): 2E:25:DE:80:85:0C:CF:B0:B5:A5:ED:0D:F7:A4:44:DB

Nos indica que se ha añadido al keystore el certificado con el alias tgssca1. En caso de querer cambiar el alias con el que se guarda el certificado en el fichero tendríamos que editar el archivo keystore.sh y cambiar la opción –alias tgssca1 con el nombre que se desee.

3.2. Incorporación de CAs al keystore.

Si quisiéramos incorporar una nueva CA al keystore podremos hacerlo mediante las utilidades que proporciona la instalación Java de IBM (keytool, ikeyman) o ejecutando el script keystore.sh donde cambiaremos:

• el nombre del alias (en el original tgssca1)

• el nombre del fichero donde resida el certificado que vamos a incorporar (parámetro –file , en el original CA--TGSS.cer).

En el caso de que TGSS no proporcionara un fichero con la nueva CA, sino que enviase algún fichero firmado con algún certificado que incorpore esa nueva CA, podremos obtener un fichero con la CA siguiendo los pasos detallados en el ANEXO A

4 DEFINICIONES. INTERFAZ GRAFICA


4. DEFINICIONES. INTERFAZ GRAFICA

4.1. Ficheros, Recursos cics.

Debe definir los ficheros ZTBFFLO y ZTBFFPE al CICS (ver miembro FCTCEDA en la librería de jcls). A su vez, debe inicializar dichos ficheros al CICS (ver miembros ZTBFJILO y ZTBFJIPE en la librería de jcls)

Para la versión IMS consultar el manual EFF51USUI.doc.

4.2. EDItran/P.

4.2.1. Sesión de transmisión EDItran/P (sólo CICS).

En la sesión de transmisión EDItran/P, se indicará:

Procedimiento posterior a recepción: Indra proporciona un procedimiento especial para la descarga, verificación y extracción de firmas, ZTBFP4C.

4.3. EDItran/G.

4.3.1. Sesión de presentación EDItran/G.

En la sesión de presentación EDItran/G, se indicará:

Formato fichero descarga = V. El fichero que se recibe es un binario XML, pero necesitamos descargarlo como variable.

Fichero único en Recepción. Si va a recibir más de 1 fichero en la misma transmisión, indique N. Si va a recibir un único fichero en cada transmisión indique S.

Nombre físico del fichero de aplicación de recepción. Este es el nombre del fichero con que descarga EDItran el XML ASCII base64 que contiene las firmas y el documento. Por tanto, es un fichero que no será tratado por su aplicación. En base a ello, indique un nombre “temporal” ó no indique nada, en cuyo caso, EDItran creará los valores por defecto para crearlo. Revise la documentación EDItran para ver las opciones de parametrización de este campo. En el ejemplo que sigue, por si se recibe más de 1 fichero, se añade la variable %C (número de orden del fichero recibido)

Procedimiento posterior a recepción: Indra proporciona un procedimiento especial para la descarga, verificación y extracción de firmas, ZTBFP4C, ZTBFP4 en IMS.

Ascii/Ebcdic = E. TGSS transmite desde una máquina EBCDIC.

Traducir en recepción = N. No se puede traducir al descargar el fichero, pues perdería la validez de las firmas.

Tabla de conversión en recepción = espacios. No se puede aplicar tabla de conversión al recibir, pues perdería la validez de las firmas.



4.4. EDItran/FF.

En lo referente a los perfiles de la versión de IMS se deberá consultar el manual EFF51USUI.doc.

4.4.1. Entorno local EDItran/FF.

Incluir el directorio de funciones y el almacén, así como fichas jcl, prefijo ficheros y procedimiento proporcionado para consultar certificados

Pulse PF8 e introduzca path key storage, campos del servidor , PSW del key storage.

Path del key storage, es la ruta del fichero keystore donde se guarda el certificado de la TGSS (CA). En esta pantalla se muestra el fichero creado por el usuario (véase 3.1).

PSW, deberá introducir la password del keystore. Si el keystore utilizado es el que se suministra con la instalación, trustStore.pfx, deberá poner password. Si ha creado un keystore, deberá introducir la password elegida en el momento de su creación.

IP del (listener) servidor donde reside la aplicación java de firma de ficheros. La aplicación java, corre en el entorno USS y requiere arrancar un listener en una ip y puerto específicos.

Puerto del (listener) servidor donde reside la aplicación java de firma de ficheros. La aplicación java, corre en el entorno USS y requiere arrancar un listener en una ip y puerto específicos.

Tiempo conexión servidor. Tiempo en segundos, durante los cuales se espera que la aplicación java devuelva control, extrayendo el fichero del XML y validando las firmas.



Ejemplo. Si la ip es la misma que la de la pila ip que atiende al monitor de teleproceso, indique 127.0.0.1 (dirección de loopback). El puerto, puede poner por ejemplo el 7775 (resérvelo en la pila IP), y el tiempo recomendado 60 segundos.

4.4.2. Usuarios remotos EDItran/FF.

TGSS podrá emitir en cada transmisión, n ficheros a tratar. Cada uno de ellos es un binario cuyo contenido es un XML con el propio documento a tratar (en ASCII y base64), y con 2 firmas embebidas. Sólo es viable traducirlo y formatearlo una vez validadas las firmas y extraído el documento ASCII, pues de otro modo se perdería la opción de verificación.

Cada uno de esos XML transmitidos contiene 2 firmas autorizadas. No puede contener ni más firmas ni menos (excepto que TGSS indique lo contrario). Una de ellas, pertenece siempre al grupo de Gestión de TGSS. La otra, pertenece siempre al grupo de Intervención de TGSS.

A su vez, hay 3 posibles firmantes en cada uno de los grupos descritos.

En base a lo anterior, mientras TGSS no notifique lo contrario:

No puede haber 1 única firma en el fichero XML, ni 3. Sólo puede haber 2.

No puede haber 2 firmas en el fichero XML que pertenezcan por ejemplo a intervención ó a cualquier otro grupo distinto. Deben pertenecer una a Gestión y la otra a Intervención.

No puede haber firmantes que no conozcamos entre los 3 posibles de cada grupo que haya indicado TGSS.

En EDItran se necesita por tanto, controlar los grupos, cantidad de firmantes posibles por grupo, usuarios posibles de cada grupo, número de firmas requeridas de cada grupo, etc. Los usuarios posibles de cada grupo, los identificamos por su propio nombre y por su DNI (campo CN ), datos extraídos del Distingued Name (DN). Tiene textualmente los



dos apellidos y el nombre del firmante, luego hay un espacio, un guión, otro espacio y el número de DNI de la persona escrito siempre con 9 caracteres (8 dígitos + letra)

Este campo se corresponde con el “asunto” que aparece en los ”detalles del certificado” de ese usuario en concreto. En definitiva, hemos de indicar las siguientes características:

Sesión requiere 1 firma de 3 posibles del grupo de Gestión

Sesión requiere 1 firma de 3 posibles del grupo de Intervención

Los “posibles” firmantes del grupo de Gestión son (ejemplo): José Luis, María y Manuel.

Los “posibles” firmantes del grupo de Intervención son (ejemplo): Antonio, Luisa y Raquel

Los CN de cada uno de los 6 anteriores (detalles del asunto del certificado son: xxxx, yyy, zzzz, aaaa, bbbb, cccc

Por tanto, es necesario conocer los nombres y DNI de los firmantes (CN), puesto que EDItran, valida quien son los firmantes a partir de esta información. TGSS indica que en caso de que no vengan bien los firmantes, se envíe un fichero de confirmación con código de control 16 (Firmante(s) no autorizado(s) en la cuenta). Los CN normalizados de los firmantes, los necesitaremos para incluIrlos en los perfiles de EDItran/FF.

Los nombres y dni de los firmantes, los debería proporcionar TGSS, pero si esto no ocurriera, se pueden visualizar a partir del explorador de Windows.

Continuando con el ejemplo anterior, procederemos a dar de alta a los 6 firmantes posibles: José Luis, María, Manuel, Antonio, Luisa y Raquel. En la opción 7.2.2 procedemos a dar de alta a cada uno de ellos, como usuarios remotos de TGSS (8910)



Meteremos el CN de la siguiente forma, CN=los dos apellidos y el nombre del firmante, luego hay un espacio, un guión, otro espacio y el número de DNI de la persona escrito siempre con 9 caracteres (8 dígitos + letra)

4.4.2.1.¿Cómo incluir el CN si no conocemos el mismo?.

Si no conocemos el CN del firmante, debemos solicitarlo a TGSS. No obstante, también podemos coger el fichero XML recibido y realizar las siguientes operaciones:



Editar el XML recibido, con el explorador (*.xml) y seleccionar el contenido entre las primeras etiquetas <ds:x50S

Certificate> y ==</ds:x509Certificate>

Copiar ese contenido a un fichero *txt (bloc de notas), que acabaremos renombrando como *.cer

Abrimos con el explorador de windows



Vamos a la pestaña Detalles y después a Asunto:

Cogeremos exactamente el CN indicado y lo llevaremos al perfil FF (CN=FERNANDEZ HERNANDEZ JOSE LUIS – 12345678X)



4.4.3. Sesión de presentación EDItran/FF (parámetros generales).

Damos de alta en la opción 7.2.3.1 la presentación (es necesario que exista en EDItran/G), indicando que las firmas son attach, el nombre de los ficheros descargados y el modo de formateo.

En el ejemplo que nos ocupa, el fichero de aplicación final, será FB de LRECL 72, y será traducido a EBCDIC eliminando los saltos de carro x’0D0A’.

Tenga en cuenta que el nombre del fichero descargado y que trataba su aplicación, hasta ahora era el que figuraba en la sesión de presentación de EDItran/G, si así se lo indicábamos. Ahora, es conveniente poner otro nombre en la sesión de presentación de EDItran/G y trasladar el nombre que había antes allí a la sesión de presentación EDItran/FF. En el ejemplo, estamos identificando (por si viene más de 1 fichero en la presentación), su número (%C), la fecha de descarga (%A%M%D), la hora de descarga (%H), la entidad remota (8910) y la aplicación de la presentación (-BESB)



4.4.4. Grupos asociados a Sesión de presentación EDItran/FF.

En el ejemplo que nos ocupa, tenemos que definir grupo GESTION y grupo INTERVENCION. Necesitamos 1 firma de cada uno de los grupos, y esos grupos tienen 3 componentes cada uno. Continuando con el ejemplo anterior, en la opción 7.2.3.2

Los “posibles” firmantes del grupo de Gestión son (ejemplo): José Luis, María y Manuel.

Los “posibles” firmantes del grupo de Intervención son (ejemplo): Antonio, Luisa y Raquel

Repetimos la operación con el grupo INTERVENCION.



4.4.5. Usuarios asociados a Sesión de presentación EDItran/FF.

Ahora, asociaremos cada usuario remoto a su grupo (opción 7.2.3.3) y le indicamos que el usuario puede firmar su emisión. Recordemos con el ejemplo

Los “posibles” firmantes del grupo de GESTION son (ejemplo): José Luis, María y Manuel.

Los “posibles” firmantes del grupo de INTERVENCION son (ejemplo): Antonio, Luisa y Raquel

Repetimos la operación con los otros 5 posibles firmantes.



4.4.6. Consulta de la sesión de presentación EDItran/FF (firmantes).

En la presentación FF (opción 7.2.3.1), ya tenemos que los firmantes están asociados. Si quisiéramos consultar ó modificar algún parámetro:

Una vez dentro, pulsamos PF4 (usuarios-grupos asociados) para ver los firmantes.

Si no indicamos nada y pulsamos INTRO, vemos todos los firmantes, los grupos y las características:

En el grupo de GESTION son (ejemplo): José Luis, María y Manuel. El número de firmas obligatorias es 1. Todos ellos tienen capacidad de firmar.



En el grupo de INTERVENCION son (ejemplo): Antonio, Luisa y Raquel. El número de firmas obligatorias es 1. Todos ellos tienen capacidad de firmar.

Si desde la primera pantalla de la presentación pulsamos PF5 (situación), vemos que en total hay 6 usuarios, 2 grupos remotos y que necesitamos 2 firmas. Aparece José Luis, por ser alfabéticamente el primer nombre del primer grupo



Y en esa pantalla, pulsando PF4, SITUACION ESPECIFICA DE GRUPOS Y USUARIOS, confirmamos que tenemos 2 grupos para la recepción, que tenemos los firmantes necesarios de cada grupo (1), puesto que indica que no faltan firmas obligatorias.

Si por ejemplo, el fichero viene firmado por José Luis y Manuel exclusivamente, el proceso de descarga daría errores porque no llega ninguna firma del grupo Interventores. En el log FF se indicaría:

5EJEMPLO PROCEDIMIENTO POSTERIOR A RECEPCION


5. EJEMPLO PROCEDIMIENTO POSTERIOR A RECEPCION

En el siguiente ejemplo, se muestra el funcionamiento del posterior a recepción

En la sesión de presentación G tenemos:

• FORMATO FICH.DESCARGA (F/V/E): V, (TGSS debería emitir poniendo los parámetros de EDItran/G en cuanto a sus ficheros de aplicación de emisión: Formato=B, Lenguaje=B, Traducir=N)

• Fichero único en recepción N,

• Nombre del fichero descargado KI.TGSS.NORM34.N%C.

En la sesión de presentación FF, tenemos:

• NOMBRE FISICO FICHERO DE APLICACION (FORMATEADO)...: KI.PMED.R8910.NORM34.F%A%M%D.H%H.N%C

• FORMATO FICH.DESCARGA (F-V-E): F

• LONGITUD REGISTRO (1-32756)..: 00072

• TRADUCIR RECEPCION (A-E-N)...: E

• ELIMINA SALTOS DE CARRO (S/N): S

• SALTOS A ELIMINAR EN HEXADEC.: 0D0A

El procedimiento posterior a recepción, que se usará en las sesiones en las que se reciban ficheros firmados por TGSS, ZTBFP4C, tiene varios pasos:

• A4P- Paso que descarga los ficheros firmados emitidos por TGSS. Si por ejemplo se hubieran recibido 2 ficheros en la misma transmisión, se descargarían 2 ficheros VB con los nombres KI.TGSS.NORM34.N01 y KI.TGSS.NORM34.N02. El contenido de cada uno de esos ficheros constaría de:

• El propio documento ASCII Base 64 del fichero de aplicación de emisión

• La firma de un usuario de TGSS perteneciente al grupo GESTION

• La firma de un usuario de TGSS perteneciente al grupo INTERVENCION

• Si este paso acaba con retorno distinto de cero (y no se trata de un 01, por motivo de no recibir todavía la última transmisión de la presentación), será necesario corregir el error y relanzarlo, ó recibir de nuevo la presentación.

• ZTBEBA00. Paso sólo aquellos clientes con Estadísticas y alarmas. Este paso sólo entra cando da ABEND el paso A4P. Corrija el error y relance el procedimiento.

• ZTBGLFE. Paso que genera un fichero (ZTBGFLFE), cuyo contenido son la lista de ficheros recibidos y sus características. Este paso, sólo entra cuando el paso A4P acaba con retorno ceros.



• PASSORT. Paso para ordenar la lista de ficheros creada anteriormente. La salida se llama ZTBFFLFT. Este paso, sólo entra cuando el paso ZTBGLFE acaba con retorno ceros.

• PASO01. Este paso, sólo entra cuando el paso ZTBGLFE acaba con retorno ceros. Se trata del paso para verificar y extraer las firmas de los ficheros KI.TGSS.NORM34.N01 y KI.TGSS.NORM34.N02. Este paso, llama mediante una conexión TCP/IP a la aplicación que está en los servicios UNIX y que se encarga de la validación. A este paso le entra un fichero ZTBFLFE con la lista de ficheros descargados a tratar, y crea a su vez 2 listas de ficheros de salida ZTBFFSAL y ZTBFFLF2. Además, crea 2 ficheros de salida, con un nombre por defecto, cuyo contenido son los ficheros de aplicación ASCII que posteriormente se firmaron en TGSS. En este paso, en las verificaciones de firma, se pueden dar las siguientes situaciones para cada uno de los ficheros recibidos:

• Que este paso acabe con retorno ceros. Indica que todos los ficheros recibidos han sido procesados correctamente en cuanto a verificación de firmas

• Que este paso acabe con retorno 01. Indica que algún (ó todos) los ficheros recibidos han sido procesados y hay algún problema en cuanto a la verificación de firmas

• Que este paso acabe con otro código de retorno. Será necesario corregir el error y relanzarlo,

• INBORR1. Este paso, sólo entra cuando el PASO01 acaba con retorno < 02. Borra la lista de ficheros ZTBGFLFE

• PASO02. Este paso, sólo entra cuando el PASO01 acaba con retorno < 02. Formatea los 2 ficheros VB ASCII recibidos a ficheros FB de longitud 72 con traducción a EBCDIC, de forma que se acabarán creando 2 ficheros (independientemente de que acabarán con retorno 00 ó 01 en pasos anteriores)

• KI.PMED.R8910.NORM34.F120410.H160000.N01, siendo la fecha 12-04-10 y la hora 16:00:00

• KI.PMED.R8910.NORM34.F120410.H160001.N02, siendo la fecha 12-04-10 y la hora 16:00:01

• Además, el paso tratará el fichero que finalmente se pasará a la aplicación (ZTBFFSAL), cuyo formato se especifica en 5.1.1.

• INBORR2. Este paso, sólo entra cuando el PASO02 acaba con retorno 00. Borra la lista de ficheros ZTBFFLF2

• A partir de aquí, la aplicación usuaria, recoge el fichero ZTBFFSAL para ver el dsname de los ficheros recibidos, los nif de los firmantes y el retorno en la validación de firmas y construye un fichero de confirmación positivo o negativo:

• Si el retorno no es cero, generará un fichero de confirmación negativo con los retornos que le hubiera dado EDItran en el fichero ZTBFFSAL (retornos 12 a 16)



• Si el retorno es cero, la aplicación, continuará con sus validaciones

o Si las validaciones de la aplicación son positivas, generará un fichero de confirmación positivo

o Si las validaciones de la aplicación, son negativas, generará un fichero de confirmación negativo (códigos de control 01 a 10). Incluso, puede ser el código 16, Firmante(s) No autorizados en la(s) cuenta(s).



5.1. Fichero de salida a la aplicación.

Se crea fichero (ZTBFFSAL) FB de 300. Indicará como fue la verificación de firmas para cada fichero recibido, así como características de las firmas. Tiene 2 tipos de registros: Nivel Nombre Long. Fmto. Descripción

1 Registro ZTBFFSAL alfn. Registros de TIPO 01. 2 Tipo de registros 2 Alfn 01-Registros referentes a ficheros tratados y a su

resultado de validación 2 Dos puntos 1 Alfn Valor: ‘:’ 2 Código de retorno 4 Num 0000- Verificación de la firma correctamente

0012- Autoridad certificadora no válida 0013- Certificado(s) revocado(s). No implementado aún 0014- Certificado(s) caducado(2) 0015- Documento modificado 0016- Firmante(s) no autorizados en la cuenta. Esto es una validación posterior de la firma contra los perfiles de EDItran/FF

2 Dos puntos 1 Alfn Valor: ‘:’ 2 Dsname Formateado

final 44 Alfn. Dsname del fichero formateado y traducido final, a tratar

por la aplicación. 2 Dos puntos 1 Alfn Valor: ‘:’ 2 Dsname descargado

ASCII 44 Alfn. Dsname del fichero ASCII, extraído del XML y con las

firmas también extraídas. 2 Dos puntos 1 Alfn Valor: ‘:’ 2 Dsname descargado

por EDItran 44 Alfn. Dsname del fichero descargado por EDItran, cuyo

contenido es el XML que se ha tratado. 2 Dos puntos 1 Alfn Valor: ‘:’ 2 Mensaje de error 80 Alfn Mensaje

Si rc=0000, Proceso de firma correcto (sin mensaje) Si rc=xxxx, mensaje de error oportuno

2 Area reserva 77 Alfn Area de reserva

Nivel Nombre Long. Fmto. Descripción

1 Registro ZTBFFSAL alfn. Registros de TIPO 02. 2 Tipo de registros 2 Alfn 02-Registros referentes a firmantes por fichero. Po r

cada registro tipo 1, habrá tantos registros de tip o 2, como firmantes contenga el fichero firmado.

2 Dos puntos 1 Alfn Valor: ‘:’ 2 Area de reserva 4 Alfn 2 Dos puntos 1 Alfn Valor: ‘:’ 2 Dsname Formateado

final 44 Alfn. Dsname del fichero formateado y traducido final, a tratar

por la aplicación. 2 Dos puntos 1 Alfn Valor: ‘:’ 2 Datos del CN firmante 138 Alfn. CN=Apellidos y el nombre del firmante, luego hay un

espacio, un guión, otro espacio y el número de DNI de la persona escrito siempre con 9 caracteres (8 dígitos + letra)

2 Filler 109 Alfn Area de reserva



5.2. Otras situaciones.

TGSS parece que emitirá un único fichero por transmisión. Tenga en cuenta que todo lo anterior, se trata de un ejemplo, recomendado para situaciones en las que se emitan varios ficheros por transmisión. Además, con esta forma de actuación en el ejemplo se consigue no perder el fichero de TGSS descargado en la transmisión anterior.

No obstante, si actualmente su aplicación recibe el fichero de aplicación con un nombre fijo, tenga en cuenta que quitando ese nombre del perfil-G y poniéndolo en el perfil-FF, su aplicación, continuará recibiendo ese mismo fichero.

Si por ejemplo, el posterior a recepción, arranca un procedimiento de su aplicación, para tratar el fichero de TGSS, tenga en cuenta, que puede poner variables, tanto en perfil-FF, como en el propio ZTBFFSAL, que pudieran pasarse vía parm a su procedimiento.

6 LOG EDITRAN/FF


6. LOG EDITRAN/FF

En la sesión de presentación tenemos un log que podemos consultar (opción 7.1.1)

7 ANEXO A


7. ANEXO A

7.1. Subir al USS el certificado de la CA

El propio paquete de instalación, lleva el certificado de la CA de la TGSS, por lo tanto, no es necesario realizar este proceso. Sin embargo, se describe el mismo, por si TGSS cambia de certificado.

En caso de no disponer del certificado de la CA, lo podemos conseguir, cogiendo uno de los certificados de los firmantes, lo abrimos y vamos a la pestaña Ruta de certificación. Marcamos SGI (CA) y pulsamos doble click

7 ANEXO A


Vamos a Detalles, copiar en archivo y se abre otra ventana. Seleccionamos Der Binario Codificado x509 y lo guardamos

7 ANEXO A


Ahora ya tenemos todos los datos necesarios

En caso que hubiera otras CA (parece que en esta primera fase no es así, repetimos la operación de exportar el certificado de otras CA. Si los 2 firmantes firman bajo la misma CA, no es necesario exportar la CA del segundo firmante.

Ya tenemos los certificados de la CA, c:\b2.cer, (c:\b3.cer si hubiera 2 CA…)

Una vez tengamos la CA sea porque nos la envió TGSS o la extrajimos de un certificado, lo tenemos en el PC, por ejemplo c:\ CA_SILCON_Prod.der o c:\b2.cer, c:\b3.cer,…., procedemos a ponerla en el USS.

1- Lo metemos en USS mediante los comandos (ejemplo de subir b2.cer): a. cmd b. ftp ip destino (pedirá usuario tso y password) c. cd /u/editranxades/rsc/truststore (directorio destino donde subiremos el

certificado de la CA). d. binary (ftp en binario) e. lcd c:\ (directorio origen donde se encuentra el certificado de la CA) f. put b2.cer (certificado de la CA, a subir) g. quit (salir)

7 ANEXO A


3.- Vemos que queda en el directorio USS. /u/editranxadescd: >ls -l -rw-r----- 1 editrancd KISNCE 753 Nov 2 15:09 b2.cer 4.- Si el nombre que hemos puesto es muy grande, lo renombramos (para poner un nombre muy corto, por ejemplo CA1, pues luego tenemos un jcl de incorporación al que no se le pueden pasar muchos parámetros)

/u/editranxadescd: >ls -l

-rw-r----- 1 editrancd KISNCE 753 Oct 25 09:08 CA_SILCON_Prod.der

/u/editranxadescd: >mv CA_SILCON_Prod.der CA1

/u/editranxadescd: >ls -l

-rw-r----- 1 editrancd KISNCE 753 Oct 25 09:22 CA1

8 ANEXO B


8. ANEXO B

8.1. Códigos de Resultado del servidor

Existen 2 categorías de resultado:

a) Resultados propios de la validación de la firma.

000- Verificación de la firma correctamente

012- Autoridad certificadora no válida

013- Certificado(s) revocado(s). No implementado aún

014- Certificado(s) caducado(2)

015- Documento modificado

016- Firmante(s) no autorizados en la cuenta: Esto es una validación posterior de la firma contra los perfiles de EDItran/FF

b) Errores propios del proceso.

047- Error en proceso. Consultar el código RAZ.:

017- Petición no construida correctamente.

018- Error al leer del buffer de lectura la longitud de la trama.

Error al leer del buffer de lectura la petición.

019- Función peticionaria no reconocida.

020- Solamente se validan firmas Attach.

021- Lenguaje máquina origen no reconocido.

022- Valor de validación CRLS no reconocido.

023- Valor de zip no reconocido.

024- Valor de cifrado no reconocido.

025- Valor de codificación base64 no reconocido.

026- Identificador fichero a validar no reconocido.

027- Identificador fichero salida no reconocido.

028- Identificador clave keystore no reconocido.

029- Identificador del path del key storage no reconocido.

030- La ruta del fichero a validar debe ser mayor que 0.

031- La longitud de la ruta del fichero de salida debe ser mayor que 0.

032- La longitud de la ruta del fichero de salida de DN debe ser mayor que 0.

033- La longitud de la PASSWORD del keystore debe ser mayor que 0.

034- La longitud de la ruta del keystore a validar debe ser mayor que 0.

8 ANEXO B


035- Error en la lectura del fichero origen.

036- Error al analizar el xml.

037- No se encuentra el elemento Signature en el documento.

038- Error en el análisis del elemento signature.

039- Error en el proceso de validacion de la firma.

040- Error obteniendo la información de firma no válida.

041- No se utiliza.

042- No se ha encontrado el certificado con el que se firmo dentro del documento.

043- Error en la escritura del fichero destino.

044- Error en la escritura del fichero dn.

045- Error inesperado. + descrpcion del error standard java exception

046- Error leyendo el keystore.

048- Error OutOfMemoryError. + descrpcion del error standard java exception: Cuando se produzca este error, se debe aumentar los parámetros de asignación de memoria que están en el fichero start.sh de la instalación del producto.

Documents

EDItran - Firma XAdES-BES para TGSSmontilla.indra.es/doc/CICS/criptografia/EDXAdESUSIA.pdfEDItran - Firma XAdES-BES para TGSS zOS Manual de Usuario e Instalación Indra. Mayo - 2012