openssl: Codificaciones DER y PEM

A la hora de trabajar con openssl, podemos usar dos formatos para almacenar la información de las claves que generemos. El primero de ellos se conoce como PEM - derivado de las propuestas Privacy Enhanced Email -, un formato que codifica la información binaria en base64 - cuyo alfabeto de símbolos son todos caracteres ASCII imprimibles -. El segundo se conoce como DER, y no es más que una manera de codificar en binario estructuras expresadas a través de la notación ASN.1 - donde andarán mis apuntes de redes II ... -

La codificación PEM no es más que la información codificada en DER, transformada en base64 y con dos líneas que marcan el comienzo y el final de dichos datos en base64. Por ejemplo, un fichero con los parámetros para generar una clave DSA comienzan por -----BEGIN DSA PARAMETERS-----, en medio van las líneas codificadas en base64 y termina con -----END DSA PARAMETERS-----

A la hora de generar claves, se puede especificar el formato que se va a usar para almacenar la misma. Por defecto se usa PEM, pero puede controlarse el formato de salida y de entrada con ayuda de los parámetros -outform fmt e -inform fmt, pudiéndose respectivamente, donde fmt es PER o DER en función de la codificación que se desee usar.

Por ejemplo, si se quiere convertir una clave DSA en formato PEM a formato DER se utilizaría la orden:

openssl dsa -inform PEM -in private.pem -outform DER -out private.der

Curiosamente, aunque se puede generar los parámetros de las claves en formato DER o PEM, ni genrsa ni gendsa admiten éstos en formato DER, al menos en la versión que viene por defecto en MacOS X 10.7 "Lion". Mucho más interesante es ver como realizar estas operaciones a través de programación. Espero tener tiempo para escribir un par de entradas que sirvan de guía para programar con OpenSSL.

---

Technorati Tags: openssl, criptografía,cifrado

vim: Introducción a comandos (III)

A la hora de definir comandos en vim, se puede especificar rangos de líneas o contadores. Cuando se quiere definir un comando que acepte un rango de líneas se usa el parámetro ‑range. En función del valor que tenga este, tendrá un significado u otro: ‑range - por defecto la línea actual - , ‑range=% - por defecto todo el fichero -, ‑range=N, que indica que va a tener un número de línea, por defecto N y ‑count=N que indica una cuenta. Una particularidad es que vim comprueba que los rangos son correctos. Si el fichero tiene 1000 líneas, si se llama al comando usando un rango de líneas erróneo - por ejemplo, 100,10001Comando .- , vim dará un error y no ejecutará el comando.

Cuando se define el comando, hay una serie de sustituciones para los parámetros. En el caso del rango son <line1> y <line2>. Para el caso de la cuenta el parámetro que se utiliza es <count>. Un ejemplo sencillo es un comando RExp, que admite un rango y lo imprime:

:command ‑range Rexp :echo <line1> <line2>

Para ejecutar el comando anterior, en modo comando se introduce 10,20Rexp1, y si el fichero tiene más de 20 líneas imprimirá 10 y 20. Si se llama sin parámetros, imprimirá el rango que corresponde a la línea actual.

Para el caso de la cuenta, se utiliza el texto de sustitución <count>. Si se quiere definir un comando RExp1, que devuelva el valor de cuenta especificado, por defecto el valor 10:

:command ‑range=10 RExp1 :echo <count>

Si se llama sin parámetros, imprimirá el valor por defecto 10, si se le especifica una cuenta, imprimirá el valor que se le pasa: 20RExp1, imprimirá el valor de 20.

Technorati Tags: vim

vim: Introducción a comandos (II)

Continuando con la entrada introducción a la creación de comandos de vim, los comandos que se crean en vim pueden tener parámetros. La presencia de los mismos se indican en la definición del comando con ayuda del modificador -nargs=value.

Un ejemplo: Supongamos que se quiere definir un comando ITechtag, que reciba un parámetro y que cuando se ejecute inserte una url que sea un enlace a una etiqueta en technorati, las cuales tienen el siguiente formato:

<a href="http://www.technorati.com/tag/etiqueta" rel="tag">etiqueta</a>

La definición del comando ITechtag puede ser la siguiente:

command ‑nargs=1 ITechtag :normal o<lt>a href="http://www.technorati.com/tag/<args>" rel="tag"><args><lt>/a>

Las partes de la definición de este comando importantes son tres:

• ‑nargs=1 Indica que el comando recibe un sólo parámetro.
• <args> Indica en que parte del comando se va a sustituir el parámetro.
• <lt> Sirve para representar un < en el código del comando.

Si al comando anterior se le llama con parámetro vim, ITechtag vim, insertará el siguiente texto en el editor:

<a href="http://www.technorati.com/tag/vim" rel="tag">vim</a>

El mecanismo de uso de los argumentos en los comandos no es todo lo flexible que nos pueda parecer, puesto que sólo permite especificar si no hay argumentos, ‑nargs=0; si hay un solo argumento, ‑nargs=1; si hay uno o más argumentos ‑nargs=+; si hay uno o ningún argumento, ‑nargs=? o bien si hay cualquier número de argumentos , ‑nargs=*. En este caso, lo normal es usar el comando para llamar a una función escrita en vimscript si se quiere usar cualquier número de argumentos.

A la hora de llamar a una función desde un comando con varios argumentos hay una particularidad: Debe de usarse <f-args> para representar los argumentos.

Como ejemplo de lo anterior, voy a definir una función Do_tech_tags que recibe uno o más argumentos a la cual se le llama a través del comando ITechtags que puede tener uno o más argumentos y que va a insertar cada una de las etiquetas que se le pasen como argumentos. Voy a suponer que esta función está definida en el fichero technorati.vim y que se ha cargado con ayuda del comando source

function! Do_tech_tags(...)
    let l:index = 1
    let l:cadena = '<p style="text‑align:right;font‑size:10px;">'."\n".'Tecnorati tags: '
    while l:index <= a:0
        let l:cadena = l:cadena . '<a href="http://www.technorati.com/tag/'.a:{index}.'" rel="tag">'.a:{index}.'</a>'
        let l:index = l:index + 1
        if l:index < a:0
            let l:cadena = l:cadena . ','
        endif
    endwhile
    let l:cadena = l:cadena."\n"."</p>\n"
    execute ":normal o" .l:cadena
endfunction 

Ahora se define el comando:

command -nargs=+ ITechtags :call Do_tech_tags(<f-args>)

Este comando puede llamarse como ITechtags tag1 tag2 tag3 ... . Por ejemplo, si se llama como ITechtags vim insertará el siguiente código html en el buffer actual.

<p style="text-align:right;font-size:10px;">
Technorati Tags: <a href="http://www.technorati.com/tag/vim" rel="tag">vim</a>
</p>

---

Technorati Tags: vim

Chipre, bancarización, dinero en efecto y aviso a navegantes

La noticia económica de la semana - y veremos si no es del año - ha sido las medidas exigidas a Chipre a cambio de su rescate por parte de la Unión Europea. La medida que ha levantado toda la polémica ha sido la imposición de un impuesto sobre los depósitos bancarios - entre el 6.75% y el 9.9% - en función de la cantidad depositada. Además, se han prohibido las transferencias desde los bancos chipriotas hacía entidades fueras del país. Un corralito en toda regla, que acaba con uno de los pilares básicos de la Unión Europa: la libre circulación de capitales y mercancías.

De todo este problema, personalmente saco algunas conclusiones, no sé si acertadas,pero ...

• La primera de todas es que la garantía del Estado es tan arbitraria como decida los que ocupa el poder en ese momento. Chipre, es un país que pertenece a la Zona Euro desde el año del 2008 cuyos gobiernos decían una y otra vez que tenían que garantizar el depósito de los clientes bancarios. Por lo que vemos, estas garantías y buenas intenciones no vale para todo el mundo dentro de la UE. Y no vale la excusa de que Chipre es un paraíso fiscal. Eso ya se sabía cuando entró a formar parte del euro.
• No soy muy amigo de la desaparición del dinero en efectivo, considero que sólo el dinero electrónico es una mala idea.. Hoy tengo otro argumento más que sumar a dicha opinión: Que los gobiernos confisquen directamente parte de lo que tengas ahorrado en una cuenta bancaria. Y eso es mucho más sencillo, como hemos visto, que prohibir el papel moneda. Esta mañana, una vez tomada la decisión, ya el gobierno chipriota había aplicado la tasa a las cuentas de los depositantes.
• Esperemos que este paso de los burócratas europeos no acabe provocando una corrida bancaria, entrando de lleno en la profecía autocumplida, pero están ellos solos echando gasolina al fuego.
• Recordar siempre que el Estado tiene el monopolio de emisión de dinero. Y hace con su valor lo que le da la gana. Es capaz de cobrar por la espalda vía inflación o devaluar la moneda como considere. Y cuando muchos celebran el éxito de las subastas del Tesoro en España, debemos de pensar quienes vamos a pagar esas deudas.
• Se cae ese dicho de que en la Unión Europea no puede haber corralitos: Hoy ya sabemos que no es así. Y que si se quiere, se puede restringir la libre circulación de capitales. Aviso a navegantes.

---

Technorati Tags: política,economía

Notas rápidas sobre openssl y generación de claves para firmado

Estos dos últimos días he estado utilizando la herramienta de línea de comandos que tiene el toolkit de openssl para realizar varias tareas de firmado y generación de claves en un entorno de criptografía asimétrica, también conocida como criptografía de clave pública.

Quería probar la facilidad con la que se pueden generar claves para firmado y cifrado con el toolkit. Lo primero que hay que tener claro es que tipo de algoritmos de clave pública se quiere utilizar. En función de la versión del toolkit que se tenga instalada y las opciones que se hayan elegido a la hora de compilar el mismo, se dispondrán de algoritmos basados en curvas elípticas, DSA (Digital Signature Algorithm), extandar FIPS 186-3 , RSA ( Ron Rivest, Adi Shamir and Leonard Adleman) o claves para el intercambio usando el algoritmo de Diffie–Hellman. Lo primero que hay que hacer es elegir el algoritmo que se desea usar . Cada uno de los algoritmos tiene sus particularidades, para quien tenga curiosidad un buen libro que habla del tema es el Applied Cryptography: Protocols, Algorithms, and Source Code in C, Second Edition de Bruce Schneier.

Generación de claves

La secuencia de órdenes para generar un par de claves públicas y privadas para firmado es:

• Generar los parámetros para las claves en función del algoritmo que se desee usar (con la excepción de RSA)
• Generar la clave a partir de los parámetros del punto anterior y guardarlo en el formato que se desee.
• Extraer la información de la clave pública que se usa para las verificaciones.
• Realizar las correspondientes operaciones que se desee.

Si se desea realizar los pasos anteriores para una clava de tipo DSA, las órdenes que habría que introducir serían:

openssl dsaparam -outform PEM -out dsa.params.pem 4096
openssl gendsa -out private.pem dsa.params.pem
openssl dsa -in private.pem -outform PEM -out public.pem -pubout

Estas tres órdenes realizan la siguientes funciones

• Se genera un fichero de parámetros para poder generar una clave de tipo DSA de 4096 bits de longitud. Este fichero de parámetros se va almacenar en formato PEM (-outform PEM) con el nombre dsa.params (-out dsa.params). Con el formato elegido, el fichero dsa.params es un archivo de texto que puede verse en un editor fácilmente.
• Generamos la clave privada y pública DSA que se va a almacenar en el fichero private.pem (-out private.pem) a partir de la información que hay en dsa.params.pem. Decir que el fichero resultante, private.pem puede estar protegido cifrado usando el algoritmo DES (-des), tripe DES (-3des) o IDEA (-idea) o AES (-aes128,-aes192 o -aes256). Sino se especifica ninguno, no se cifrará. El fichero de parámetros debe de tener codificación PEM para que funcione correctamente esta orden.
• Se obtiene la clave pública (-pubout) desde el fichero que contiene ambas (-in private.pem), para almacenarla en formato PEM (-outform PEM) en el fichero public.pem (-out public.pem).

Firmado de un fichero

A la hora de firmar ficheros, se utiliza las opciones de dgst. Una particularidad es que con claves DSA, hay que usar el message digest dss1, lo que implica usar la opción -dss1. Para firmar es necesario la clave privada.

openssl dgst -dss1 -sign private.pem -out file.sign file

En este caso openssl generará una firma del fichero file, con el message digest dss1 (-dss1) usando la clave privada que está en private.pem (-sign private.pem) cuyo resultado almacenará en el fichero file.sign (-out file.sign)

Verificación de una firma

A la hora de verificar una firma se utiliza la clave pública que es pareja de la clave privada que se utilizó para firmar. Al igual que en el caso anterior, al estar usando claves DSA el message digest que hay que usar obligatoriamente es dss1

openssl dgst -dss1 -verify public.pem -signature file.sign file

Verificamos el fichero file cuya firma está contenida en el fichero file.sign (-signature file.sign) con la clave pública que está en public.pem (-verify public.pem), usando el message digest dss1 (-dss1). Decir que en este caso la opción -verify indica tanto el fichero de clave pública como que se va a proceder a realizar una verificación usando la misma.

Notas

Se que he dejado muchas cosas en el tintero, por ejemplo la necesidad de tener una fuente de entropía que se utiliza para calcular números aleatorios o la posibilidad de utilizar diversos motores para realizar las operaciones, que permitan descargar el procesador de las tareas de cálculo. He pasado de puntillas por los formatos de codificación que se pueden usar y no he hablado de como cifrar un fichero usando (se puede ver la página de manual de enc)

---

Technorati Tags: openssl,criptografía,cifrado

Playstation 3 y cifrado de disco duro

Una característica curiosa de la Playsation 3 es que cifra el contenido del disco duro interno que lleva con una clave única para cada consola. Por tanto, no se puede coger el disco de una consola y pasarla a otra. Esto hace que los únicos mecanismos oficialmente soportados por Sony que se existen para poder realizar el transvase de dicha información sea a través de los mecanismos de copia de seguridad o la transferencia de información a través de la ethernet. Hay ciertas limitaciones en el sistema de copias, sobre todo en lo referente a contenido protegido por alguna forma de gestión digital de derechos que no pueden transferirse entre máquinas a través de las copias de seguridad.

Por curiosidad, he buscando un poco de información sobre el tipo de cifrado que utiliza la consola en el disco duro De la web PS3 Developer wiki se puede sacar alguna información interesante:

• El algoritmo de cifrado que utiliza es XTS-AES-128, similar al usado en varios sistemas.
• El cifrado se realiza a través de un módulo hardware llamado ENCDEC. Entiendo que no hay ningún comando ATA que establece una password a nivel de protocolo ATA en el disco duro.
• Por lo que he leído en varios foros, hay gente que ha logrado volcar las claves usadas en este proceso de cifrado para de esta manera poder acceder al contenido de los archivos del disco duro de una PS3.
• Si se es capaz de volcar las claves, se puede usar Linux para montar el disco
  de la PS3 en un PC
• Más detalles de este proceso pueden verse en ENCDEC Device Reverse Engineering

---

Technorati Tags: ps3,cifrado

Solaris y reinicios continuos automáticos

Tengo una una Sun Blade 2000, con Solaris 10, que utilizo para probar portabilidad de programas y para no olvidar algunas de las cosas que conocía de Solaris. El caso es que tras resetear la máquina, no arrancaba, entrando en un bucle continuo de reinicios. Lo primero que me hacía sospechar es que por consola mostraba Hostname: unknown , seguía hacia delante comenzaba el fsck del sistema de fichero raíz y se reteaba sola tras escribir syncing file systems… done. Y a partir de ese punto entra en un bucle reiniciándose una y otra vez.

Tras buscar bastante por Internet y en diversos foros, di con Solaris boots to single user mode and reboots automatically, donde he encontrado la clave del problema: Todos los Unix tienen un directorio /dev, donde hay unos ficheros especiales que sirven para acceder a los dispositivos. Estos ficheros sirven de interfaces con los drivers de dispositivos del kernel. Uno de los archivos que hay es /dev/null, que en Solaris es un enlace simbólico a un fichero en el directorio /devices, cuando está correctamente creado. El caso es que en mi sistema faltaba dicho enlace, que de ser correcto sería similar a:

ls -al /dev/null

lrwxrwxrwx   1 root     root          27 mar  5 12:44 null -> ../devices/pseudo/mm@0:null

Tras arrancar con un CDROM y montar el sistema de ficheros raíz de la máquina que no podía arrancar, vi que, efectivamente dicho dispositivo no era correcto. Entonces, siguiendo las instrucciones que se detallan en el enlace anterior, usando devfsadm, comando usado para administrar las entradas de /dev/:

boot cdrom -s # En el prompt de la PROM

mount /dev/dsk/c1t1d1s0 /a # Montamos el disco. Esto depende de la controladoras que tenemos, los id SCSI y las particiones

devfsadm -Cv -r /a # Recreamos los enlaces

pkgchk -f -R /a # Corrige los atributos de fichero

De esta manera, el sistema volvió a arrancar sin problemas.

---

Technorati Tags: solaris

Las previsiones macroeconómicas de la Comisión Europea

La semana pasada la Comisión Europea publicaba las previsiones de crecimiento y deuda para España para los próximos años. Me llamó especialmente la atención la estimación de que la deuda pública alcanzaría el 100% del PIB en el año 2014 y sus negativas espectivas de empleo.

Sin embargo, recordaba que cinco meses antes la misma Comisión Europea decía que el 100% de deuda sobre el PIB se alcanzaría en el año 2020. ¿Cómo puede darse tal variación en los datos de deuda pública sobre el PIB en apenas cinco meses?. ¿Qué tipo de modelos macroeconómicos se está usando para llegar a estas conclusiones tan dispares?.¿Por qué la prensa nacional, en vez de berrear con los manos en la cabeza con los datos coge y hace un análisis histórico de las previsiones de la Comisión y cuales han sido después los datos reales?

Entiendo que la Ciencia Económica no es algo exacto, que puede haber cisnes negros y multitud de factores que influyen en los resultados,que la economía no es la ecuación de ondas ni las ecuaciones de Maxwell, pero ¿semejante variabilidad en las previsiones?.

Lo más triste es que la Reserva Federal Australiana hizo un estudio sobre su previsiones económicas durante veinte años. Los resultados son cuanto menos curiosos: las estimaciones de inflación son correctas en el 70% , las de crecimiento, y en especial, las estimaciones de empleo no tiene mayor fiabilidad que una tirada de dados.

Aquí admitimos sin más las previones cuatrimestrales de la Comisión, sin plantearnos siquiera que ha dicho cinco meses antes, en especial por parte de la prensa económica.

---

Technorati Tags:economía