Secure Apt

Me he permitido traducir este artículo (con la gran ayuda de Esther Castellanos) sobre Secure Apt que está disponible en el wiki de Debian. Está escrito por Joey Hess. Se admiten correcciones de todo tipo



SECURE APT

Recientemente, las ramas Unstable y Testing de Debian han comenzado a usar criptografía fuerte para validar los paquetes descargados. A esto se le llama comúnmente Secure Apt (o apt-secure) y fue implementado en la versión 0.6. Como la documentación (aquí y aquí ) es verdaderamente escasa sobre cómo funciona esto desde el punto de vista de un administrador, este documento intentará explicar en detalle cómo funciona Secure Apt y cómo usarlo.



1.Todo sobre Secure Apt
2.Conceptos básicos
3.Trabajo preliminar de Secure Apt: Checksums
4.Ficheros Release firmados
5.Cómo Apt usa Release.gpg
6.Cómo decirle a Apt qué autenticar
7.Cómo encontrar una llave
8.Cómo añadir una llave de forma segura
9.Rotación anual de la llave del archivo Debian
10.Otros problemas
11.Configurando un repositorio de Apt Secure
12.Historia
13.Comentarios y preguntas
14.Copyright


CONCEPTOS BÁSICOS


Aquí están unos pocos conceptos básicos que necesitarás para entender el resto del documento. Un checksum (suma de comprobación) es un método para coger un fichero y reducirlo a un número pequeño de forma razonable que identifica únicamente el contenido de un fichero. Esto es mucho más difícil de hacerlo bien de lo que puede parecer, y el tipo de checksum más comúnmente utilizado, el md5sum, está en proceso de romperse.

La criptografía de llave pública está basada en el par de llaves, una llave pública y una privada. La llave pública se da a todo el mundo; la llave privada debe permanecer en secreto. Cualquiera que posea la llave pública puede cifrar un mensaje para que sólo pueda ser leído por alguien que posea la llave privada. También es posible usar una llave privada para firmar un archivo, no para cifrarlo. Si una llave privada es utilizada para firmar un archivo, entonces cualquiera que tenga la llave pública puede comprobar que el archivo fue firmado por esa llave. Nadie que no tenga esa llave puede falsificar la firma.

Esas llaves son números bastante largos (al menos 1024 bits, por ejemplo 256 o más dígitos hexadecimales) y para hacer más fácil el trabajar con ellos, incorporan una identificación de llave, que es un número corto de 8 ó 16 dígitos que puede ser utilizado para referirse a ellos.

GPG es la herramienta usada en Secure Apt para firmar los ficheros y comprobar sus firmas. Apt-key es un programa que se usa para gestionar el anillo de llaves de gpg para asegurar Apt. El anillo de llaves se guarda en el archivo /etc/apt/trusted.gpg (no se debe confundir con el archivo /etc/apt/trustdb.gpg con el que está relacionado y que no es muy interesante). Apt-key puede ser usado para mostrar las llaves en el anillo de llaves, y para añadir o remover una llave.


TRABAJO PRELIMINAR DE SECURE APT: CHECKSUMS


Un archivo de Debian contiene un archivo llamado Release, el cual se actualiza cada vez que cualquiera de los paquetes en el archivo cambian. Entre otras cosas, el fichero Release contiene algunos md5sums de otros ficheros en el archivo. Un extracto de un ejemplo de fichero Release:



 MD5Sum:
 6b05b392f792ba5a436d590c129de21f            3453 Packages
 1356479a23edda7a69f24eb8d6f4a14b            1131 Packages.gz
 2a5167881adc9ad1a8864f281b1eb959            1715 Sources
 88de3533bf6e054d1799f8e49b6aed8b             658 Sources.gz

(Los ficheros Release también incluyen checksums sha1, las cuáles serán útiles una vez que md5sums estén completamente rotos, aunque Apt aún no las utilice). Ahora si miramos dentro de un fichero Release, encontraremos más md5sums, una por cada paquete listado en él. Por ejemplo:


Package: uqm
Priority: optional
...
Filename: unstable/uqm_0.4.0-1_i386.deb
Size: 580558
MD5sum: 864ec6157c1eea88acfef44d0f34d219

Estas dos checksums permiten a Apt verificar que se está descargando una copia correcta del fichero Packages, con un md5sum que concuerde con el del fichero Release. Y cuando descarga un paquete individual, también puede comprobar el md5sum sobre el contenido del fichero Packages. Si Apt falla en cualquiera de estos pasos, abortará.

Nada de esto es nuevo en asegurar Apt, pero proporciona los cimientos.Hay que fijarse que hasta ahora hay un fichero que Apt no tiene la manera de comprobarlo: el fichero Release. Secure Apt trata de hacer verificar a Apt el fichero Release antes de que haga cualquier otra cosa con él, y tapando este agujero, de tal forma que hay una cadena de verificación desde el paquete que vas a instalar hasta el proveedor del paquete.


FICHEROS RELEASE FIRMADOS


Para tapar el agujero, Secure Apt añade una firma gpg para el fichero Release. Esto está puesto en un fichero llamado Release.gpg que se envía junto al fichero Release. Se parece a algo así, aunque realmente sólo gpg mira normalmente su contenido.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBCqKO1nukh8wJbxY8RAsfHAJ9hu8oGNRAl2MSmP5+z2RZb6FJ8kACfWvEx
UBGPVc7jbHHsg78EhMBlV/U=
=x6og
-----END PGP SIGNATURE-----

(Técnicamente hablando, esto es una firma gpg ascii-armored separada)


CÓMO APT USA RELEASE.GPG


Secure Apt siempre descarga los ficheros Release.gpg cuando está descargando los ficheros Release, y si no puede descargar el Release.gpg, o si la firma está mal, lo advertirá, y te dirá que el fichero Packages al cual apunta el fichero Release, y todos los paquetes enumerados dentro, son de una fuente sin autentificar. Así es como apararece durante un apt-get update:


W: GPG error: http://ftp.us.debian.org testing Release: The following signatures
 couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F

Observa que la segunda mitad del número largo es la identificación de la llave que Apt no conoce, es este caso es 2D230C5F.

Si ignoras ese aviso e intentas instalar un paquete después, Apt te advertirá de nuevo:


WARNING: The following packages cannot be authenticated!
  libglib-perl libgtk2-perl
Install these packages without verification [y/N]?

Si dices Y (Sí) aquí, no puedes saber si el paquete que estás obteniendo es el paquete que supuestamente estás instalando, o si es otra cosa se te ha presentado una chistera con una sorpresa dentro. Observa que puedes deshabilitar esas comprobaciones ejecutando Apt con allow-unauthenticated.

Es algo digno de tener en cuenta que las nuevas versiones del instalador de Debian usan el mismo mecanismo de firmar el fichero Release durante el debootstrap del sistema base de Debian, antes de que Apt esté disponible, y que incluso el instalador usa este sistema para verificar partes de sí mismo que se descarga de la red. Además, Debian actualmente no firma los ficheros Release en sus CD's; Apt puede ser configurado para autentificar siempre los paquetes desde los CD's, por lo que esto no es un gran problema.


CÓMO DECIRLE A APT QUÉ AUTENTICAR


La seguridad del sistema entero depende de que haya un fichero Release.gpg, el cual firma un fichero Release, y de Apt comprobando que esa firma use gpg. Para comprobar la firma, debe conocer la llave pública de la persona que firmó el fichero. Esas llaves se mantienen en el anillo de llaves de Apt (/etc/apt/trusted.gpg), y administrando esas llaves es donde aparece Secure Apt.

Por defecto, los sistemas Debian vienen preconfigurados con la llave del archivo Debian en el anillo de llaves.


joey@dragon:~>sudo apt-key list
/etc/apt/trusted.gpg
--------------------
pub   1024D/4F368D5D 2005-01-31 [expires: 2006-01-31]
uid                  Debian Archive Automatic Signing Key (2005) <ftpmaster@debi
an.org>

Aquí 4F368D5D es la identificación de la llave, y observad que esta llave sólo era válida por un año. Debian rota estas llaves como última línea de defensa contra algunas brechas de seguridad que rompen una llave.

Eso conseguirá que Apt certifique el archivo oficial de Debian, pero si añades algún otro repositorio de Apt a /etc/apt/sources.list, también tendrás que darle a Apt su llave si quieres que Apt las certifique. Una vez que tienes la llave y la has verificado, es simplemente hacer un apt-key add file para añadirlo. Conseguir la llave y verificarla es la parte más complicada.


CÓMO ENCONTRAR UNA LLAVE


Todavía no hay una localización estándar donde puedas encontrar la llave para un repositorio Apt ya dado. Hay un estándar aproximado sobre cómo poner la llave en una página web para el repositorio o como un fichero dentro del mismo repositorio, pero no es un estándar real, por lo tanto tendrías que encontrarlo.

El archivo Debian que firma la llave está disponible en http://ftp-master.debian.org/ziyi_key_2006.asc (se cambia 2006 por el año en curso). (La herramienta que se usa para firmar en los servidores de Debian se llama Ziyi, por Ziyi Zhang).

El mismo gpg tiene una forma estándar de distribuir llaves, usando un servidor de llaves desde el que gpg puede descargarse una llave y añadirlo a su anillo de llaves. Por ejemplo:


joey@dragon:~>gpg --keyserver pgpkeys.mit.edu --recv-key 2D230C5F
gpg: requesting key 2D230C5F from hkp server pgpkeys.mit.edu
gpg: key 2D230C5F: public key "Debian Archive Automatic Signing Key (2006) <ftpm
aster@debian.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1
Entonces puedes exportar esa llave de tu propio anillo y añadirla a apt-key

joey@dragon:~>gpg -a --export 2D230C5F | sudo apt-key add -
gpg: no ultimately trusted keys found
OK

(¿Qué significa el aviso gpg: finalmente no se han encontrado llaves verificadas? --> El aviso finalmente no se han encontrado llaves verificadas significa que gpg no estaba configurado para verificar una llave específica. Las configuraciones de verificación son parte de las webs de verificación de OpenPGP, algo que no interesa aquí. Por lo tanto no hay ningún problema con esta advertencia. En configuraciones normales la propia llave del usuario está finalmente verificada.)


CÓMO AÑADIR UNA LLAVE DE FORMA SEGURA


Añadiendo una llave al anillo de Apt, le dices a Apt que verifique todo lo que la llave ha firmado, y esto te permite saber de forma segura que Apt no instalará nada que no haya sido firmado por la persona que posee la llave privada. Pero si eres lo suficientemente paranóico puedes ver que esto únicamente lleva las cosas a un nivel superior, y ahora en lugar de tenerte que preocupar de si un paquete, o un fichero Release es válido, te puedes preocupar de si realmente has conseguido la llave correcta. ¿Es realmente la http://ftp-master.debian.org/ziyi_key_2006.asc que se mencionó arriba la llave que firma el archivo de Debian, o es éste documento una trampa inteligente?.

Es bueno ser paranóico con la seguridad, pero verificando las cosas desde este punto es más difícil. Gpg tiene el concepto de una cadena de autentificación, que puede empezar con alguien en quien confías, que firma la llave de alguien, que firma alguna otra llave, etc., hasta que llegas a la llave del archivo. Si eres lo suficientemente paranóico, querrás comprobar que la llave de tu archivo está firmada por una llave en la que puedes confiar, con una cadena de autentificación que se remonta a alguien que conoces personalmente. Si quieres hacer esto, ve a una conferencia de Debian o quizás en un Grupo de Usuarios de Linux (LUG) local para firmar la llave.

(Nota: no todas las llaves del repositorio de Apt se firman por otra llave. Quizá la persona que configura el repositorio no tiene otra llave, o quizás no se sienten cómodos firmando esa llave con su llave principal.)

Si no puedes aguantar este nivel de paranoia, haz lo que tú consideres apropiado a la hora de añadir una nueva fuente de Apt y una nueva llave. Quizás quieras mandar un correo electrónico a la persona que te da la llave y verificarla, o quizás quieras tener la oportunidad de descargártela y dar por hecho que tienes la auténtica. Lo importante es que reduciendo el problema a lo que las llaves del archivo autentifica, Secure Apt permite que seas tan prudente y seguro como acostumbras a ser.

Aquí hay un mensaje en una bitácora con un procedimiento para verificar la integridad de la llave.


ROTACIÓN ANUAL DE LA LLAVE DEL ARCHIVO DE DEBIAN


Como se ha mencionado arriba, la llave que firma el archivo de Debian cambia cada año, en Enero. Como Secure Apt es reciente, no tenemos mucha experiencia a la hora de cambiar la llave y todavía quedan puntos sin explicar.

En Enero de 2006, se hizo una nueva llave para el 2006 y el fichero Release comenzó a firmarse por ella, pero para intentar evitar romper los sistemas que tienen la vieja llave del 2005, el fichero Release fue firmado también por esa. La intención era que Apt aceptaría una firma u otra dependiendo de la llave que tuviera, pero Apt resultó ser defectuoso y rechazó autentificar el fichero a menos que tuviera ambas llaves y fuera capaz de comprobar ambas firmas. Esto se arregló en la versión 0.6.43.1 de Apt. Hubo también confusión acerca de cómo la llave se distribuyó a usuarios que ya tenían sistemas que utilizaban Secure Apt; inicialmente fue subido al sitio web sin ningún tipo de anuncio y sin ninguna manera de verificarla y los usuarios se vieron forzados a descargársela manualmente. Esto se arregló por la introducción del paquete debian-archive-keyring, que gestiona las actualizaciones del anillo de llaves de Apt.

Basado en esta experiencia, aquí vemos cómo podrían funcionar las cosas en el 2007:

  • A principio de Enero se creará una llave para el 2007. Quizás con un anuncio y con una cadena de autentificación esta vez bien definida.
  • El fichero Release se firmaŕa con esta llave, mientras que también se firmará aún con la llave del 2006. Apt y otras herramientas aceptarán cualquiera de las dos firmas.
  • Debian-archive-keyring será actualizado para incluir la llave del 2007. Cuando los usuarios actualicen la nueva versión, utilizará la llave Apt para actualizar su anillo de llaves, añadiendo la llave del 2007. Este paquete también se puede actualizar para eliminar las llaves viejas del anillo de llaves si así se desea.
  • La llave del 2006 caduca el 31 de Enero de 2007.
  • No es aún seguro lo que le pasará a alguien que no actualice nada en Enero, y cómo esta actualización será gestionada por gente usando estable, una vez que Secure Apt esté disponible.

Pero es muy pronto para decir algo.


OTROS PROBLEMAS


  • Un obstáculo no tan obvio es que si tu reloj está muy atrasado, Secure Apt no funcionará. Si está puesto en una fecha en el pasado, como en 1999, Apt fallará con un mensaje tan inútil como éste:

  • 
    W: GPG error: http://archive.progeny.com sid Release: Unknown error executing gpg
    

    Aunque la lista de apt-key hará el problema más fácil

    
    gpg: key 2D230C5F was created 192324901 seconds in the future (time warp or clock problem)
    gpg: key 2D230C5F was created 192324901 seconds in the future (time warp or clock problem)
    pub   1024D/2D230C5F 2006-01-03
    uid                  Debian Archive Automatic Signing Key (2006) <ftpmaster@debian.org>
    

    Si se pone una fecha lejos en el futuro, Apt tratará las llaves como caducadas.

  • Otro problema que te puedes encontrar usando Testing o Unstable, es que si no has hecho un apt-get update últimamente y apt-get install con un paquete, Apt podría objetar que no puede ser autenticada (¿por qué hace esto?). Apt-get update arreglará esto.
  • Si tienes el paquete debsig-verify instalado, podrías obtener errores como este:

dpkg: error
processing /var/cache/apt/archives/anjuta-common_1.2.4a-2_all.deb (--unpack):
 Verification on package /var/cache/apt/archives/anjuta-common_1.2.4a-2_all.deb failed!
Authenticating /var/cache/apt/archives/anjuta_1.2.4a-2_i386.deb ...
debsig: Origin Signature check failed. This deb might not be signed.

Esto no tiene nada que ver realmente con Secure Apt. Debsig-verify comprueba firmas incluídas dentro de paquetes individuales de Debian. Como tales firmas no se utilizan ampliamente (usamos en su lugar Secure Apt), el intalar esto no funciona muy bien, y eliminar el paquete debsig-verify arreglará el problema.


CONFIGURANDO UN REPOSITORIO DE APT SECURE


Por hacer


HISTORIA


Conectiva implementó algo similar en su fork de Apt. Los Desarrolladores de Debian Colin Walters e Isaac Jones implementaron Apt Secure para Debian en 2003. Cerca de la Navidad de 2003, Matt Zimmerman (?) integró este parche en Apt 0.6. En Febrero de 2005, Debian comenzó a migrar a apt-secure


COMENTARIOS Y PREGUNTAS


Debian no es Ubuntu y no tendrá instalado por defecto Sudo. Merecería la pena cambiar el uso de Sudo, y hacer que los ejemplos usen la cuenta de root explícitamente. ---Steve Kemp

Dados los modos de error que he visto de las gpg recv-keys, sugerir que un usuario lo ejecute como root no me parece muy sabio. Pero realmente nunca lo he probado. A pesar de que Sudo no se instala por defecto (en Sarge), pienso que la mayoría de la audiencia de esta página está familiarizado con él, o pueden saltárselo. --- Joey Hess

¿Tiene sentido preinstalar el debian-server-keyring en cada sistema Debian?. Al menos se le debería preguntar al usuario si él/ella confía en esa llave. Hasta ahora (07/01/2006) la Firma Automática de Llaves del Archivo Debian no es la colección más fuerte de llaves. Así no es posible probar vía opathfinders si hay una ruta de autentificación de mi llave a la Firma Automática de Llaves del Archivo Debian (ver www.cs.uu.nl/people/henkp/henkp/pgp/pathfinder o www.lysator.liu.se/~jc/wotsap/search.html)

Sí, el paquete debian-archive-keyring será el camino para actualizar la llave para todos los sistemas Debian, así que debe ser instalado en todos, y supongo que será estándar. -- Joey Hess

¿Podemos integrar de alguna manera esta idea en la página?. Pienso que también es importante que nos movamos en esta dirección. --madduck


COPYRIGHT


Este documento tiene Copyright 2006 de Joey Hess y otros bajo los términos de la GNU GPL

Copyright © 2006 de la traducción: Daniel Barragán

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".