Certificado de sello electrónico

[flyf]

A ver si me aclaro.. Si cuando sea funcionario tengo un entorno que hace:
1.- Firma documentos que se manda al ciudadano
2.- Establece conexiones con @firma y cualquier otro servicio común que se os ocurra...

Suponemos que 1 y 2 no están relacionados..es decir, son trámites totalmente distintos. Están físicamente en servidores diferentes.
Para todas estas operaciones, necesito certificado de sello electrónico. ¿donde lo pongo físicamente? un servidor de "árbitro" de esos que llaman seguros?. Un certificado y su clave en cada servidor que realice los trámites y pongo la condición de que sea almacén seguro?

Pues ale, a ver quien me torea el toro!!

Flyf

[laurilop]

buena pregunta

si tienes varios servidores que hacen función de firma:
a) tienes n certifiacdo de sello
b)el certificado de sello es único y lo replicas ¿se puede hacer?

la b) no me parece viable

si la a) es posible, imagino que cada servidor cifrará lo suyo
aunque por no sobrecargar se podría delegar esta tarea en un servidor dedicado ??? Alguien que conozca esto nos podría aclarar?

En cualquier caso, cuando se hacen firmas en otro sitio como cuando accedes a @firma para el servicio de firma.. ¿ no es peligroso el trasiego de datos??

¿Alguien podría explicar como funciona el servicio de firma de @firma cuando se accede desde un servidor?

[E.Garcia]

A ver si consigo responder todo, porque hay muchas cosas juntas:

• - ¿Como firmar si tengo una aplicación en un servidor?
  Existen dos posibilidades. O tienes instaladas librerias y material criptográfico en el servidor o acudes a una plataforma externa (tipo @firma) que es la que tiene librerias y material criptográfico e invocas por webservices (existe un estándar pero no lo recuerdo). Quien tenga el material criptográfico lo puede tener en un repositorio software o hardware (HSM).
  
  - ¿No hay demasiado trasiego de datos si se firma en una plataforma de firma?
  No necesariamente. Dependiendo de lo lista que sea la plataforma de firma. Si te lo acepta, basta que le mandes el hash del documento, que es lo único que en realidad se firma. Con @firma esto es posible.
  
  - ¿Se pueden replicar un certificado en varios servidores?
  No sólo se puede sino que suele ser lo habitual. No es tan complicado. Basta con instalar el fichero PKCS12 en los repositorios criptográficos de cada uno de ellos (hw o sw).

[laurilop]

Muchas gracias E. García

[flyf]

Gracias E.García...abusando un poco más...
Entonces, si tengo necesidad de firmas en mi entorno por varias razones (firma de documentos, conexión con @firma, servicio de notificaciones seguras... cada una de ellas necesita firma), puede tener todo en un servidor dedicado como repositorio de certificados de componentes? A ese servidor, le invocarían la aplicación de firma de documentos y debería tener los WS de comunicación con las otras plataformas/servicios (@firma, SNTS,....).
Es posible? recomendable? estoy haciendo una animalada?

Muchísimas gracias!!

Flyf

[apachito]

• - ¿Como firmar si tengo una aplicación en un servidor?
  Existen dos posibilidades. O tienes instaladas librerias y material criptográfico en el servidor o acudes a una plataforma externa (tipo @firma) que es la que tiene librerias y material criptográfico e invocas por webservices (existe un estándar pero no lo recuerdo). Quien tenga el material criptográfico lo puede tener en un repositorio software o hardware (HSM).
  
  - ¿No hay demasiado trasiego de datos si se firma en una plataforma de firma?
  No necesariamente. Dependiendo de lo lista que sea la plataforma de firma. Si te lo acepta, basta que le mandes el hash del documento, que es lo único que en realidad se firma. Con @firma esto es posible.
  
  - ¿Se pueden replicar un certificado en varios servidores?
  No sólo se puede sino que suele ser lo habitual. No es tan complicado. Basta con instalar el fichero PKCS12 en los repositorios criptográficos de cada uno de ellos (hw o sw).

Entiendo que quieres decir que para utilizar el servicio, el certificado con el que se firma está en la plaftaforma @firma.

Sobre el servicio de firma de @firma se dice que:
Este servicio permite a una aplicación cliente realizar, con el certificado de firma de servidor indicado, y siempre dentro del contexto de la plataforma @firma 5.0, una firma electrónica. Es decir, la generación de dicha firma se lleva a cabo en la plataforma, ....
Entiendo yo que solo se le envía el hash, como tu dices, pero no el certificado para que firme con él (que tendría que estar "hospedado" (textualmente) en la plataforma @firma (esto último de -en la plataforma @firma- lo digo/pregunto yo).

También hay un cliente firma (se utiliza un "Plugin XAdES" en el navegador) Entiendo que el plugin sirve para cuando el certificado está en el cliente y no en la plataforma @firma, ¿no? (por ejemplo un ciudadano quiero firmar un documento)

[sico]

• - ¿Como firmar si tengo una aplicación en un servidor?
  Existen dos posibilidades. O tienes instaladas librerias y material criptográfico en el servidor o acudes a una plataforma externa (tipo @firma) que es la que tiene librerias y material criptográfico e invocas por webservices (existe un estándar pero no lo recuerdo). Quien tenga el material criptográfico lo puede tener en un repositorio software o hardware (HSM).
  
  - ¿No hay demasiado trasiego de datos si se firma en una plataforma de firma?
  No necesariamente. Dependiendo de lo lista que sea la plataforma de firma. Si te lo acepta, basta que le mandes el hash del documento, que es lo único que en realidad se firma. Con @firma esto es posible.
  
  - ¿Se pueden replicar un certificado en varios servidores?
  No sólo se puede sino que suele ser lo habitual. No es tan complicado. Basta con instalar el fichero PKCS12 en los repositorios criptográficos de cada uno de ellos (hw o sw).

Entiendo que quieres decir que para utilizar el servicio, el certificado con el que se firma está en la plaftaforma @firma.

Sobre el servicio de firma de @firma se dice que:
Este servicio permite a una aplicación cliente realizar, con el certificado de firma de servidor indicado, y siempre dentro del contexto de la plataforma @firma 5.0, una firma electrónica. Es decir, la generación de dicha firma se lleva a cabo en la plataforma, ....
Entiendo yo que solo se le envía el hash, como tu dices, pero no el certificado para que firme con él (que tendría que estar "hospedado" (textualmente) en la plataforma @firma (esto último de -en la plataforma @firma- lo digo/pregunto yo).

También hay un cliente firma (se utiliza un "Plugin XAdES" en el navegador) Entiendo que el plugin sirve para cuando el certificado está en el cliente y no en la plataforma @firma, ¿no? (por ejemplo un ciudadano quiero firmar un documento)

Yo más o menos coincido con apachito. Es decir, en caso de querer utilizar la funcion de firma remota de @firma, entonces el certificado de sello (con el que quiero firmar) debería estar ya allí. Tanto por seguridad como por economía, ya que mandar todas las veces el mismo certificado no parece logico.

Dicho esto imagino que el susodicho certificado que en un principio se le pasó a @firma incluiría la llave privada para que así se pueda firmar.

[E.Garcia]

• - ¿Como firmar si tengo una aplicación en un servidor?
  Existen dos posibilidades. O tienes instaladas librerias y material criptográfico en el servidor o acudes a una plataforma externa (tipo @firma) que es la que tiene librerias y material criptográfico e invocas por webservices (existe un estándar pero no lo recuerdo). Quien tenga el material criptográfico lo puede tener en un repositorio software o hardware (HSM).
  
  - ¿No hay demasiado trasiego de datos si se firma en una plataforma de firma?
  No necesariamente. Dependiendo de lo lista que sea la plataforma de firma. Si te lo acepta, basta que le mandes el hash del documento, que es lo único que en realidad se firma. Con @firma esto es posible.
  
  - ¿Se pueden replicar un certificado en varios servidores?
  No sólo se puede sino que suele ser lo habitual. No es tan complicado. Basta con instalar el fichero PKCS12 en los repositorios criptográficos de cada uno de ellos (hw o sw).

Entiendo que quieres decir que para utilizar el servicio, el certificado con el que se firma está en la plaftaforma @firma.

Sobre el servicio de firma de @firma se dice que:
Este servicio permite a una aplicación cliente realizar, con el certificado de firma de servidor indicado, y siempre dentro del contexto de la plataforma @firma 5.0, una firma electrónica. Es decir, la generación de dicha firma se lleva a cabo en la plataforma, ....
Entiendo yo que solo se le envía el hash, como tu dices, pero no el certificado para que firme con él (que tendría que estar "hospedado" (textualmente) en la plataforma @firma (esto último de -en la plataforma @firma- lo digo/pregunto yo).

También hay un cliente firma (se utiliza un "Plugin XAdES" en el navegador) Entiendo que el plugin sirve para cuando el certificado está en el cliente y no en la plataforma @firma, ¿no? (por ejemplo un ciudadano quiero firmar un documento)

Yo más o menos coincido con apachito. Es decir, en caso de querer utilizar la funcion de firma remota de @firma, entonces el certificado de sello (con el que quiero firmar) debería estar ya allí. Tanto por seguridad como por economía, ya que mandar todas las veces el mismo certificado no parece logico.

Dicho esto imagino que el susodicho certificado que en un principio se le pasó a @firma incluiría la llave privada para que así se pueda firmar.

Lo que quiero decir, es que hay dos opciones de firmar:

• - Pasándoselo a @firma (u otra plataforma similar) para que lo haga, en este caso el certificado está en @firma
  - Hacíendolo la aplicación por su cuenta en local, desde antes que existiera @firma existían librerías para ello, en este caso la aplicación tiene el certificado

Luego, además, si quieres que lo haga @firma, tienes otras dos opciones:

• - Le pasas el documento, para que @firma genere hash y lo cifre, es decir haga todo el proceso de firma
  - Le pasas el hash, y @firma lo único que hace es cifrar el hash

Con la segunda opción evitas el trasiego de datos

[Jaluro]

Creo que esa opción que apuntáis no puede ser. ¿Cómo le voy a proporcionar mi clave privada a un tercero para que firme por mí? Eso vulnera toda la seguridad del sistema, únicamente yo debo custodiar mi clave privada y en caso de querer utilizar @firma para firmar con ella, deberé usarla descargándome las librerías a mi servidor y firmando yo personalmente.

O quizás vía aplet como el que se ofrece a los ciudadanos para que firmen sus documentos. En ese caso, por ejemplo, al no poder salir las claves de la tarjeta criptográfica, @firma lo único que hace es ofrecer vía aplet una aplicación que permita generar la firma, que por supuesto se produce dentro de la tarjeta criptográfica.

¿Alguien podría aclararlo? y si es con una descripción oficial del funcionamiento de @firma mejor.

Gracias

[agustin_pitufo]

Creo que esa opción que apuntáis no puede ser. ¿Cómo le voy a proporcionar mi clave privada a un tercero para que firme por mí? Eso vulnera toda la seguridad del sistema, únicamente yo debo custodiar mi clave privada y en caso de querer utilizar @firma para firmar con ella, deberé usarla descargándome las librerías a mi servidor y firmando yo personalmente.

O quizás vía aplet como el que se ofrece a los ciudadanos para que firmen sus documentos. En ese caso, por ejemplo, al no poder salir las claves de la tarjeta criptográfica, @firma lo único que hace es ofrecer vía aplet una aplicación que permita generar la firma, que por supuesto se produce dentro de la tarjeta criptográfica.

¿Alguien podría aclararlo? y si es con una descripción oficial del funcionamiento de @firma mejor.

Gracias

En el ctt viene claro. Le cedes tu firma al MAP y la plataforma firma por tí (si quieres).

[Jaluro]

agustin_pitufo, ¿puedes poner un link a la página del ctt en la que viene lo que dices?

Muchas gracias. Ciao