Archivo de la categoría: Firma Electrónica

Diseño y planificación de una infraestructura de clave pública (PKI)

3 respuestas

Albalia Interactiva, empresa especializada en firma electrónica, factura electrónica, banca electrónica y administración electrónica, en colaboración con IBM,  ofrece el servicio de Diseño y planificación de una infraestructura de claves públicas (PKI)

Una infraestructura de claves públicas (PKI) bien planificada y construida permite afrontar los requisitos estrictos de autenticación, cifrado y firma digital que se espera de las actuales aplicaciones de e-business.

Destacamos

Los servicios de diseño y planificación de la infraestructura de claves públicas de IBM preparan la estructura necesaria para cumplir con los objetivos de su empresa y mejorar la seguridad de sus iniciativas de e-business.

Gracias al aprovechamiento de las metodologías probadas y del capital intelectual, los asesores y arquitectos de IBM le permiten comprender cómo debe aplicarse la infraestructura de claves públicas (PKI) a su entorno empresarial, desarrollar la solución y preparar el despliegue de la tecnología PKI en su empresa.

El servicio incluye:

El siguiente conjunto de actividades conforma las fases de planificación y diseño de la infraestructura completa de servicios de PKI probados y se ofrece de forma individual o en paquetes, según sus necesidades:

  • La estrategia de la infraestructura de claves públicas (PKI) examina el entorno y la estrategia de su empresa y construye los fundamentos para tomar en consideración una infraestructura de claves públicas.
  • El asesoramiento de preparación de la PKI determina el modo en el que la creación de una infraestructura de claves públicas incidirá en la empresa y recomienda los pasos a seguir para su preparación.
  • El valor de la PKI describe las ventajas y la justificación empresarial de una infraestructura de claves públicas.
  • Los requisitos de la PKI definen los requisitos empresariales, tecnológicos y del proceso de seguridad que responden a las necesidades de su empresa.
  • La política de PKI define las políticas operativas, de procedimiento y de seguridad que regularán la infraestructura de claves públicas.
  • La arquitectura conceptual identifica la estructura de la PKI, el modelo de seguridad y los principios del diseño.
  • La arquitectura funcional se basa en la arquitectura conceptual de la infraestructura de claves públicas y define sus funciones requeridas y las relaciones entre dichas funciones.
  • La selección de productos de PKI proporciona un análisis de los requisitos de su infraestructura de claves públicas y de la arquitectura conceptual de la misma, en comparación con las soluciones del sector para que pueda escoger la tecnología que mejor se ajusta a sus necesidades.
  • La selección del sitio y el diseño de la infraestructura le permiten evaluar las posibles ubicaciones y ofrece recomendaciones para el diseño y el despliegue del recurso.
  • La arquitectura de los componentes se basa en la arquitectura funcional de la infraestructura de claves públicas y define las tecnologías, los estándares, las interfaces y los productos seleccionados que cumplan con los requisitos, la estrategia y la política de la infraestructura de claves públicas de su empresa.
  • El desarrollo de procesos describe los procesos necesarios para dar soporte a la infraestructura de claves públicas, incluidos el registro, la revocación, el mantenimiento de registros y la generación de claves de la entidad emisora de certificados.
  • Las prácticas de certificación de la PKI destacan los componentes técnicos de los documentos de la política de infraestructura de claves públicas más importantes, la declaración de práctica de certificación y las políticas de certificación.
  • El plan de implementación incluye los pasos, los conocimientos y los recursos necesarios para implementar la infraestructura de claves públicas.

Una vez definidos los planes, el siguiente paso es integrar e implementar su solución de PKI mediante nuestros servicios personalizados, que están disponibles previa petición.

En los entornos corporativos, que disponen de Mainframe, con z/OS, parte de los recursos hardware y software necesarios están ya disponibles, por lo que la estrategia de gestión de PKI es una alternativa económica o otros sistemas de gestión de certificados.

IBM ha publicado los documentos que explican la forma de desplegar su PKI en organizaciones con sistemas z/OS:

Otros artículos relacionados:

    Crypto Express3 en zEnterprise

    4 respuestas

    Los recientemente anunciados sistemas zEnterprise de IBM con el procesador z196 convenientemente destacado como corazón de la nueva arquitectura suponen un nuevo impulso en la estrategia de Mainframe del gigante azul, con un claro impacto en la racionalización de los CPDs al gestionar cualquier tipo de carga y virtualización con metodologías de servicios críticos.

    Uno de los elementos que caracterizan desde el punto de vista de seguridad la nueva arquitectura, es la disponibilidad de funciones criptográficas por hardware ya preinstalado. La funcionalidad denominada Crypto Express3 se basa en dos adaptadores criptográficos PCI Express. Cada uno de los adaptadores criptográficos PCI Express puede ser configurado como coprocesador criptográfico o acelerador criptográfico.

    La funcionalidad Crypto Express3 (CEX3) supone un nuevo avance en el estado de la técnica en lo relativo a funciones cifrado, tanto en criptografía simétrica como asimétrica.

    Al igual que sus predecesoras, está diseñada para complementar las funciones del CPACF (CP Assist for Cryptographic Function). La placa detecta intentos de manipulación y reacciona ante ellos. Incluye dos procesadores criptográficos que funcionan en paralelo, dotando a las funciones criptográficas de un rendimiento y fiabilidad sin precedentes.

    La funcionalidad Crypto Express3, se aloja en la cabina de entrada/salida o en en el receptáculo de entrada/salida del procesador z196 y mantiene en las arquitecturas zEnterprise las funciones disponibles en la Crypto Express3 originalmente desplegada en sistemas System z del tipo z10.

    Cuando uno o ambos de los adaptadores PCIe se configuran como coprocesador, quedan disponibles las siguientes mejoras criptográficas introducidas por el procesador z196:

    • Seguridad por PIN según la norma ANSI X9.8
    • Encapsulamiento mejorado de claves CCA (Common Cryptographic Architecture) en conformidad con los requisitos de agrupamiento de claves de la norma ANSI X9.24
    • HMAC (Keyed-Hash Message Authentication Code – Código de autenticación de mensajes de Hash basado en clave) de clave segura.
    • Algoritmo de Firma Digital  basado en  Criptografía de curva elíptica (ECC)
    • Concurrent Driver Upgrade (CDU) Actualización de controlador concurrente y Concurrent Path Apply (CPA)

    Otras funciones clave de Crypto Express3 incluyen:

    • Dynamic Power Management (gestión dinámica de consumo) para maximizar el rendimiento de RSA, manteniendo la CEX3 dentro de los límites de temperatura del sistema de reacción ante manipulaciones del conjunto.
    • Todas las particiones lógicas (LPAR) en todos los subsistemas de canal lógico (LCSSs – Logical Channel Subsystems) tienen acceso a la funcionalidad Crypto Express3, con hasta 32 LPARs por cada equipamiento.
    • Carga segura de código que permite la actualización de la funcionalidad, aunque la unidad esté en uso asignada a una aplicación.
    • Comprobación de bloqueo de CPUs duales para la detección de errores mejorada y aislamiento de fallos de
      las operaciones criptográficas que ejecute un coprocesador cuando un adaptador PCI-E se configure como
      coprocesador.
    • Mejora de RAS (Reliability, Availability and Serviceability) sobre versiones anteriores como consecuencia del uso de procesadores dobles y del prcesador de servicio.
    • Inserción dinámica  y configuración de equipamientos Express3 Crypto a LPAR sin interrupción del servicio.

    Los equipamientos Crypto Express3 están diseñado para ofrecer mejoras de rendimiento tanto para operaciones criptográfica simétricas y asimétricas.

    Otros artículos relacionados:

    Período de gracia en las firmas XAdES-XL

    5 respuestas

    Debido al estado de desarrollo de los PSC cuando se redactaron algunas normas de firma electrónica, se tuvo en consideración el llamado «periodo de gracia para comprobación del estado de revocación de un certificado».

    En alguna de aquellas normas  se recomendaba tener en cuenta la existencia de un periodo de tiempo de espera, conocido como periodo de precaución o periodo de gracia, para comprobar el estado de revocación de un certificado. Por ello, toda la información de revocación en formatos AdES se recomendaba incluirla después de trascurrido el periodo de precaución o periodo de gracia desde la obtención del sellado de tiempo. Este periodo como mínimo debía ser el tiempo máximo permitido para el refresco completo de las CRLs o el tiempo máximo de actualización del estado del certificado en el servicio OCSP. Estos tiempos podrán ser variables según la Declaración de Prácticas de Certificación del Prestador de Servicios de Certificación.

    En la actualidad, está precaución no tiene sentido, especialmente cuando las firmas XAdES-XL se generan del lado del firmante y es este el que inlcuye los datos de timestamping y de validación basada en OCSP (y por tanto conoce si su certificado está revocado o no).

    Efectivamente, en la actualidad, la información sobre revocación de certificados que ofrecen los prestadores de servicios de certificación sobre OCSP incluyen de forma inmediata cualquier información de revocación que se produzca, en tiempo real.

    Sólo hay que tomar precauciones cuando se utilice como mecanismo de comprobación de la revocación el acceso a las listas CRL (un mecanismo obsoleto que solo se usa en algunos contextos) o cuando se utilice un servicio de validación que, aun siendo soportado por el protocolo OCSP, se basa en la consulta de CRLs para su funcionamiento.

    En España, los únicos certificados que podrían requerir el mantenimiento del período de gracia son los de FNMT-RCM, ya que en muchos casos siguen distribuyendo CRLs. Igualmente, cuando se utilice @firma como plataforma de validación, conviene cerciorarse que el servicio no esté basado en consulta de CRLs.

    EADTrust – European Agency of Digital Trust

    3 respuestas

    Logo EAD Trust As I mentioned in other articles, one of the companies with which I am working is EADTrust, European Agency of Digital Trust, a CSP (Certification Service Provider) that provides services related to electronic signatures in the framework of Law 59/2003 (or Directive 1999/93/CE) with a philosophy we intend to be innovative:

    • It is not planned to issue individual certificates to natural persons (we might consider issuing certificates to natural persons linked to groups as part of a project).
    • It provides services to manage trust of the Information Society, particularly by encouraging the creation of high quality electronic signatures with timestamping services, validation of digital certificates and electronic document custody.
    • It provides advanced services, some specifically designed for public administrations in the framework of eGovernment Law 11/2007: certified publication in the contractor’s profile, certified service of notice, electronic invoicing or generation and verification of electronic signatures through the OASIS DSS protocol (the Ministry of Presidence announced that the evolution of the official @firma platform will evolve to implement this protocol).
    • It manages two root CAs linked together, combining RSA cryptography and ECC (Elliptic curve cryptography).

    The latter is a significant milestone, since this way EADTrust becomes the first certification authority in the world with dual technology, and possibly the first European Certification Authority that manages a PKI hierarchy based on elliptic curve cryptography.

    The root CAs of both of the certificate hierarchies are as follows:

    • RSA (sha1RSA). RSA 2048-bit key size
    • ECC (sha1ECDSA). ECC key sizes: 256 bits (equivalent to 3020 bit RSA)

    Both root CA certificates and keys were generated in the presence of a notary, a procedure that we have been refining on several CA (Certification Authority) key generation ceremonies to other certification providers with whom we have collaborated: FESTE, Camerfirma, Banesto and ANCERT.

    The certification authority based on Elliptic Curve algorithm, uses random 256 BITS ECDSAFp (secp256r1), as indicated in the documents generated by the NIST (National Institute of Standards and Technology) FIPS (Federal Information Processing Standards) 186 -2 and FIPS 186-3 in Appendices 6 and D respectively in their sections on the Recommended Elliptic Curves for Federal Government use (United States).

    This algorithm is also described in document ETSI TS 102 176-1 V2.0.0 (2007-11) «Technical Specification. Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms».

    Other references:

    • RFC 4051 «Additional XML Security Uniform Resource Identifiers (URIs)»
    • RFC 4492 «Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)»
    • ISO/IEC 15946 «Information technology — Security techniques — Cryptographic techniques based on elliptic curves»
    • ANSI X9.62:2005 «Public Key Cryptography for the Financial Services Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA)»

    Obtener certificados de CERES – FNMT

    7 respuestas

    Aunque muchos usuarios de firma electrónica ya saben que la solicitud y obtención de certificados de CERES es algo más sencilla con el navegador Mozilla Firefox que con Internet Explorer 8 (especialmente en sistemas operativos Windows Vista y Windows 7),  teniendo en cuenta unas sencillas indicaciones (que el propio servicio CERES de la FNMT remite a los usuarios que experimentan algún problema y solicitan ayuda a través de los números 902181696 / 913463892 / 917040191) es posible gestionarlos adecuadamente en estos entornos.

    Las indicaciones se recogen seguidamente y hay que seguirlas antes de solicitar el certificado.

    El problema, que no es específico de la FNMT, sino que afecta a todos los PSC que incluyan un mecanismo parecido de «enrollment»,  aparece como consecuencia de que el  control de solicitud de certificados (CertEnroll) no funciona con Internet Explorer 8 en equipos que ejecutan Windows 7 cuando se incluye en un elemento FRAME o IFRAME en la página web, que es el caso de la página de la FNMT. Se explica en el blog de desarrolladores MSDN de Microsoft:  CertEnroll control won’t work when hosted inside a frame/iframe in IE8

    La forma de resolverlo para los usuarios es descargar e instalar el hotfix 322891 relacionado con el artículo KB 2078942 de la Microsoft Knowledge Base o que la entidad de certificación prepare las páginas teniendo en cuenta ciertas recomendaciones (como se indica en el citado blog).

    Al descargarse el parche, es preciso elegir el paquete adecuado para instalar. Las opciones son:

    • Windows 7/WindowsServer 2008 R2 (x86) – Para Windows 7 de 32 bits
    • Windows 7/WindowsServer 2008 R2 (x64) – Para Windows 7 de 64 bits
    • Windows 7/WindowsServer 2008 R2 (ia64) – Para Arquitectura Intel (Intel Itanium) de 64 bits

    En el proceso hay que introducir una dirección de correo electrónico a la que se enviará un email con el enlace para descargar el paquete. En dicho correo también se le enviará la contraseña para poder instalar el paquete.

    Después de instalar el hotfix hay que configurar el navegador (Internet Explorer) accediendo a la sección de opciones de menú siguientes: Herramientas/Opciones de Internet/Seguridad.

    • Pulsar en «Sitios de Confianza».
    • En el control de nivel de la izquierda, desplazar hacia abajo hasta seleccionar nivel «bajo». Si no aparece control de nivel hay que pulsar el botón «nivel predeterminado«
    • Pulsar en el botón «Sitios«.
    • Abajo, desmarcar la opción de «Requerir comprobación del servidor (https://) para todos los sitios de la zona»
    • En el cuadro de texto «Agregar este sitio Web a la zona»: hay que agregar las siguientes URLs http://*.fnmt.es y https://*.fnmt.es
    • Cerrar la ventana.
    • En el icono «Sitios de Confianza» pulsar botón Nivel personalizado y reducir los niveles de seguridad habilitando las siguientes opciones de configuración:
    1. Comportamiento de binarios y scripts
    2. Descargar los controles ActiveX firmados.
    3. Descargar los controles ActiveX sin firmar.
    4. Ejecutar controles y complementos de ActiveX.
    5. Generar scripts de los controles ActiveX marcados como seguros para scripting.
    6. Inicializar y generar scripts de los controles ActiveX no marcados como seguros para scripts.
    7. Permitir que todos los controles activeX no usados anteriormente se ejecuten sin preguntar.
    8. Permitir scriptlets.
    9. Preguntar automáticamente si se debe usar un control activeX
    • Pulsar en Aceptar, tras el que aparecerá un mensaje para confirmar que se deberá aceptar.
    • Aplicar y aceptar la última ventana.
    • Cerrar el navegador para que se apliquen los cambios.

    Una vez instalado el parche y ajustados los parámetros es posible solicitar el certificado. Después de realizar la solicitud (y la instalación del certificado tras acudir a una de las entidades de registro), se puede volver a reestablecer las opciones de seguridad a un nivel más alto.

    Hay más información en el sitio web de Microsoft.

    Una alternativa para no usar la extensión de «Certificate enrollment» que suele ser fuente de problemas desde hace muchos años, en Albalia recomendamos a los PSC que generen directamente el fichero PKCS#12 con las claves y los certificados, de modo que el propio fichero ya es un respaldo (backup) para que los usuarios lo puedan guardar en un lugar seguro y además para que lo puedan importar con facilidad en diferentes navegadores.

    Un ejemplo es la propia CA de pruebas que Albalia ha desarrollado y a la que ya he hecho mención en alguna ocasión. Los certificados de prueba generados por esta CA no tienen valor legal pero son muy útiles para experimentar.

    EADTrust – European Agency of Digital Trust

    1 respuesta

    Como ya he mencionado en otros artículos, una de las empresas en las que colaboro es EADTrust, European Agency of Digital Trust, un Prestador de Servicios de Certificación que presta servicios relacionados con la firma electrónica en el marco de la Ley 59/2003 con una filosofía que intentamos que sea novedosa:

    • No está prevista la emisión de certificados individuales a personas físicas (podría considerarse la emisión de certificados a personas vinculadas a colectivos, en el marco de un proyecto).
    • Se prevé que gestione servicios de confianza de la Sociedad de la Información, especialmente favoreciendo la creación de firmas electrónicas de alta calidad con servicios de timestamping, validación de certificados y custodia digital de documentos electrónicos
    • Proporciona servicios avanzados, algunos especialmente diseñados para administraciones públicas en el marco de la Ley 11/2007: publicación fehaciente en el perfil del contratante, notificación fehaciente, facturación electrónica o generación y verificación de firmas electrónicas mediante protocolo DSS de OASIS (el Ministerio de Presidenca ha anunciado que la evolución de la plataforma @firma se orientará a la implementación de este protocolo).
    • Dispone de CAs root vinculadas que combinan criptografía RSA y criptografía ECC (Elliptic curve cryptography)

    Este último es un hito significativo, al ser la primera autoridad de certificación del mundo con tecnología dual, y, posiblemente, la primera autoridad de certificación europea que cuenta con una jerarquía PKI basada en curvas elípticas.

    Los certitificados raiz de la jerarquía dual son estos:

    • RSA (sha1RSA). Tamaño clave RSA 2048 bits
    • ECC (sha1ECDSA). Tamaño clave ECC: 256 bits (equivalente a 3020 bits en RSA)

    Ambas root se generaron en presencia notarial, siguiendo un procedimiento que hemos ido perfeccionando en sucesivas ceremonias de  generación de claves de CA (Certification Authority) en otros prestadores con los que hemos colaborado: FESTE, Camerfirma, Banesto y ANCERT.

    La autoridad de certificación basada en algoritmo de Curva Elíptica utiliza, en particular,  ECDSAFp de 256 BITS aleatorios (secp256r1), según se indica en los documentos generados por el NIST (National Institute of Standards and Technology) FIPS (Federal Information Processing Standards) 186-2 y FIPS 186-3 en sus apéndices 6 y D respectivamente en sus secciones referentes a las Curvas Elípticas Recomendadas para uso del Gobierno Federal (Estados Unidos).

    Colisiones en las firmas en PDF

    1 respuesta

    Florian Zumbiehl reporta un problema en las firmas PDF que permitiría forzar colisiones de funciones resumen (hash) de documentos de forma que la firma electrónica de uno de ellos podria ser utilizada para aparentar que el firmado es el otro.

    Según su descripción es una vulnerabilidad que radica en la propia especificación del formato PDF por lo que no depende de la implementación, y por tanto no cabe atribuirlo a un producto en particular.

    En mi opinión, el tipo de ataque documentado no supone un problema real para los documentos PDF ya firmados, más allá de los aspectos probabilísticos  de las colisiones, consustanciales a las funciones resumen.

    Es decir, siempre que obtengamos colisiones de documentos «a priori» estas colisiones podrán ser utilizadas para «suplantar» los documentos que colisionan, utilizando la firma de uno para dar la apariencia de firma al otro.

    En este caso particular la concatenación de documentos, siendo uno de ellos firmado, podría dar lugar a que se considerara válida una firma sin serlo, ya que solo aplicaría a uno de los documentos y no al otro.

    La solución general es utilizar funciones resumen diferentes en sistemas de firma dual o múltiple, tal y como hacemos en el proyecto Binum, que ya mencioné en este blog o tal como es posible llevar a cabo con certificados emitidos en la jerarquía de certificación dual de EADTrust.

    Y, por supuesto, también merece la pena adoptar la solución propuesta por Florian, que consiste en afinar un poco más la especificación de la firma en PDF para que se reforzaran los controles que identifican lo que va firmado dentro del PDF.

    Diplomática Digital

    6 respuestas

    La diplomática, como ciencia que estudia las formas documentales, su autenticidad y su valor probatorio, establece una serie de términos sobre los elementos internos de la forma de los documentos. Para cada documento distingue las siguientes partes: protocolo, texto y escatocolo.

    En este último, enumera diferentes elementos estructurales que pueden estar presentes en los dcumentos: corroboración, fecha, apreciación, salutación, claúsulas complementarias, atestación, certificación de firmas, notas de secretaría, etc.

    La diplomática contemporánea establece el estudio de los documentos oficiales, especialmente en el ámbito notarial y administrativo.

    La diplomática digital se centra en los documentos electrónicos y en su transcripción al papel para ser utilizados en contextos de prueba diferentes, que pueden llegar al ámbito jurisdiccional.

    La transcripción al papel de un documento electrónico se denomina Albalá (o copia constatable)  y en él se incluye un elemento nuevo, denominado metacolo, que es una extensión del protocolo, y que puede ir a continuación del escatocolo.

    El metacolo recoge elementos complementarios del documento electrónico que se extiende en sus metadatos. Entre los datos que se incluyen en el metacolo están la referencia al expediente del que forma parte, las anotaciones posteriores al documento, su vigencia o derogación y las referencias a documentos posteriores que afectan a sus efectos jurídicos.

    En el escatócolo se indican, entre otros detalles, la información técnica relativa a las firmas electrónicas que acompañan al documetos: datos del certificado, datos del timestamping, datos de la comprobación de la vigencia del certificado (OCSP).

    Crypto Summer Camp

    4 respuestas

    En Albalia estamos buscando programadores que quieran vivir un interesante reto en torno a sistemas de criptografía y firma electrónica.

    Lo vemos como una experiencia de verano (retribuida), pero que puede tener continuidad si los participantes piensan que este tipo de proyectos destinados a «despapelizar» la sociedad manteniendo el valor probatorio de las alternativas digitales, les enganchan.

    Puede ser una interesante oportunidad profesional que continuará tras el verano en torno a un nuevo «paradigma» de gestión electrónica que producirá ahorros millonarios a las empresas y administraciones que adopten estas tecnologías.

    Nuevo seminario sobre eAdministración

    1 respuesta

    El próximo 21 de septiembre de 2010 Atenea Interactiva organiza un nuevo seminario de eAdministración en el que compartiremos cartel Santi Casas, Fernando Pino y yo mismo. El evento, tendrá lugar en el Hotel Nuevo Madrid, y tiene un coste de 350 € (+IVA).

    Este es el progrma previsto:

    1.     Introducción. Iniciativas de Impulso de la Administración electrónica

    2.     Nuevo Marco Legal de  eAdministración y Contratación Pública Electrónica

    3.     Identidad Digital y DNIe.

    • La identidad digital en Internet
    • Los sistemas de federación de identidades
    • Los sistemas “fuertes” de autenticación
    • Los certificados digitales y el DNIe
    • La gestión de las capacidades y la representación
    • Aceptación de Certificados de otros países

    4.     Documento Electrónico

    • Modelo General del documento electrónico de carácter probatorio
    • Firma Electrónica, Custodia Digital, Sede Electrónica y Metadatos
    • Convivencia de los documentos electrónicos y de los documentos en papel: Compulsa, digitalización certificada y copia constatable

    5.     Sede Electrónica

    • La Sede Electrónica en la Ley 11/2007 y en el RD 1671/2009
    • Autenticidad. Certificados

    6.     Registro Telemático

    • Flujo de documentos. Conservación y registro de entradas
    • Distribución de copias electrónicas a los distintos usuarios
    • Visor de Documentos, firmas electrónicas, validaciones y sellados de tiempo
    • Orden  PRE/3523/2009  Registro Electrónico Común

    7.     Notificación fehaciente por vía telemática

    • SMS y correo electrónico certificado

    8.     Expediente Electrónico

    • Compulsa electrónica de documentos. Digitalización de Documentos
    • Identificación de los empleados públicos en los trámites telemáticos

    9.     Esquemas  Nacionales de Interoperabilidad y de Seguridad

    • Interoperabilidad organizativa, semántica y técnica
    • Principios del Esquema Nacional de Seguridad
    • Requisitos mínimos de Seguridad
    • Auditoria bienal de la Seguridad

    10.   Licitación Electrónica

    • Perfil del Contratante
    • Publicación Fehaciente
    • Factura Electrónica
    • Tipos Contractuales
    • Expediente de Contratación. Fases de la Contratación Pública
    • Tipos de Procedimientos
    • Usos de medios electrónicos, informáticos y telemáticos en los procedimientos. Contratación Pública

    Está disponible el folleto en PDF