Configurar SSH con validación de clave publica/privada

Super resumido ;)  http://bit.ly/u8PK74

Rsync falla con tareas programada CRON !!!

Trabajando en la política backup, de la plataforama de un conocido diario de tirada provincial, la solucion que he utlizado se basa en la maravillosa herramienta "rsync". El script de ejecuacion con todas sus opciones lo he dejado en /etc/cron.daily/ de manera que se ejecute al menos una  vez al dia. Al testear el script de forma manual, ciento de veces, este funciona a la perfeccion realizando el reguardo incremental como es de esperarse. Pero al poco tiempo me encuentro con la sorpresa que por algún motivo la tarea no funciona cuando es ejecutada con "cron". De los mensajes de logs del sistema y de la propia herramienta me encuentro con estas salidas, que llaman la atención:

/var/log/messages

rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="821" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.

Agregando la opción --log-file=/tmp/rsync.log a "rsync", hallo lo siguiente en la salida:

rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c
rsync: writefd_unbuffered failed to write  bytes to socket [sender]: Broken pipe (32)

No tengo tiempo de explicar la lógica del procedimiento deductivo para corregir este error, la verdad que esto se soluciono cambiando en las opciones de "rsync": -av por -rLptgov --modify-window=1 . Y reemplazando la version de rsync 3.0.7, que posee bugs, por la 3.0.9 desde las fuentes.  

NOTA: --modify-window=1 surge por estar volcando el backup a un sistema externo de archivos Windows en donde se produce un desfasaje en el timestamp que provoca errores en rsync.

Sistemas de Monitoreo de Infraestrucutura.

Planificando e implementando las acciones de resguardo y por ende las de recovery, de un conocido periódico de mi provincia, me encuentro con la necesidad de poseer un sistema que permita tener una panorámica completa y en tiempo real, de todos los equipos (virtuales) de la plataforma. Un decisión que parece medianamente simple, se convierte  en una perdida de tiempo total al encontrarse y tener que ver una cantidad enorme de buenos sistemas OpenSource, que pueden realizar el trabajo. Para tomar la decisión en mi caso, utilice esta matriz que me pareció barbara: http://bit.ly/smb2eV .
Después de un poco de análisis y debido a que la virtualizacion es un factor importante, ende aquí las ganadoras: PandoraFMS y OpensView.
Para probarlas sin perder tiempo en instalación y configuración, podemos utilizar los Virtual Appliance de VmWare: http://bit.ly/smVBaV .
Bueno por ultimo un videito que me pareció muy interesante sobre PandoFMS para VmWare:

DigiNotar Certificate Authority breach

La auditoría preliminar sobre la reciente intrusión en los sistemas de la autoridad certificadora DigiNotar puso de manifiesto cómo el descuido de políticas de seguridad básicas dio lugar a una intrusión de tal dimensión. Falta de antivirus, contraseñas débiles, servidores CA dentro de un mismo dominio, software desactualizado, carencia de sistemas de validación de credenciales (login), etc. presentan el caldo de cultivo perfecto para un A.P.T (Advance Persistent Threat).

Via: Cert INTECO Gathering

Oracle Distributed Recovery process

The RECO background process (Distributed Recovery process) of an Oracle instance
automatically resolves failures involving distributed transactions, when the
machine, network, or software problem is resolved.
Until RECO can resolve the transaction, the data is locked for both reads and writes.
Oracle blocks reads because it cannot
determine which version of the data to display for a query.

Oracle Backgroung Process !!!

Muy importante para tener en cuenta... :p

Never have a script which would kill any background processes, in which case it can have harmful effects on the database."
With most background processes (ie., RECO, ARCH, PMON), if they encounter failure or if are killed,
the database will crash and this is expected behavior.

Oracle Recoverer Process (RECO)

Recoverer Process (RECO)

The recoverer process (RECO) is a background process used with the distributed database configuration that automatically resolves failures involving distributed transactions. The RECO process of a node automatically connects to other databases involved in an in-doubt distributed transaction. When the RECO process reestablishes a connection between involved database servers, it automatically resolves all in-doubt transactions, removing from each database's pending transaction table any rows that correspond to the resolved in-doubt transactions.

If the RECO process fails to connect with a remote server, RECO automatically tries to connect again after a timed interval. However, RECO waits an increasing amount of time (growing exponentially) before it attempts another connection. The RECO process is present only if the instance permits distributed transactions. The number of concurrent distributed transactions is not limited.

Oracle RDA (Remote Diagnostics Tools)

RDA es una herramienta desarrollada por Oracle, de uso general, para la recopilación de información de productos, performance,Troubleshooting, ORA-0600, contadores de SO y muchos mas. En si, toma una fotografia del sistema capturando los datos importantes para su análisis.

Oracle recomienda el uso de esta herramienta, para resolución de services requests, antes y después de que se hagan presentes inconvenientes. De manera que los ingenieros de Oracle puedan analizar los reportes y responder al service request repidamente. Personalmente lo quiero usar para hacer Troubleshooting y poder justificar, en caso que se presente, problemas de red entre dos instancias.

Para su instalacion, primero desempaquetamos el archivo:
#> tar -xzvf p8805952_417_AIX64-5L.zip
#> cd rda
#>ls

DISCLAIM.txt        README_VMS.txt      hcve                rda.cmd             rda.sh              setup.bak
RDA                 README_Windows.txt  modules             rda.com             rda_aix             setup.cfg
README_Unix.txt     ccr                 output              rda.pl              rda_aix56

Comprobamos la integridad de la instalacion con

#>./rda.sh -vc

Nota: Como pre-requisito necesitamos perl >=5.5.

Loading the file list ...
Checking the directory '.' ...
Checking the directory 'RDA/Macro' ...
Checking the directory 'RDA/Macro/Unix' ...
Checking the directory 'RDA/Macro/Windows' ...
Checking the directory 'RDA/Object' ...
Checking the directory 'hcve' ...
Checking the directory 'modules' ...
No issues found --> lo que indica que esta correcta.


RDA puede ser utilizado con una variedad de modulos y opciones. Por lo que de primer momento, luego de desempaquetarlo y de leer el correspondiente README, se debe realizar un setup inicial. En este especificaremos donde guardar los reportes, el $ORACLE_HOME, usuario propietario del producto y toda la información que queremos recolectar.

Como primer paso ejecutamos el setup y especificamos los modulos con los cuales se realizara el setup.
Nota: Si no especificamos los modulos a utilizar (rda.sh -S) RDA tomara por default todos los módulos que posee y nos hara una gran nuemero de preguntas.

#>rda.sh -S OS DB DBA INST

• OS   Collects the Operating System Information
  
• DB   Controls RDBMS Data Collection
• DB   Controls RDBMS Data Collection
  
• INST Collects the Oracle Installation Information

Para listar los modulos y su descripción ejecutamos

#> rda.sh -L modules

Available data collection modules are:
ACFS Collects ASM Cluster File System Information
ACT Collects Oracle E-Business Suite Application Information
ADBA Collects ACS Oracle Database Assessment
ADX Collects AutoConfig and Rapid Clone Information
AGT Collects Enterprise Manager Agent Information
APEX Collects APEX Information
ASAP Collects Oracle Communications ASAP Information
ASBR Collects Application Server Backup and Recovery Information
ASG Collects Application Server Guard Information
ASIT Collects Oracle Application Server Installation Information
ASM Collects Automatic Storage Management Information
B2B Collects Oracle Business to Business Information
BAM Collects Business Activity Monitoring Information
BEE Collects Beehive Information
BI Collects Oracle Business Intelligence Enterprise Edition Info.
BIPL Collects Oracle Business Intelligence Publisher Information
BPEL Collects Oracle BPEL Process Manager Information
BPM Collects Oracle Business Process Management Suite Information
etc etc etc

Como opcion podemos utilizar perfiles, estos contienen  modulos y opciones ya predefinidas, con lo que nos ahorra algunas preguntas (el setup es obligatorio)

#>rda.sh -L profiles
Available profiles are:
9iAS Oracle Application Server 9i problems
AS10g Oracle Application Server 10g problems
AS10g_Identity Oracle Identity Management 10g problems
AS10g_IdentityFed Oracle Identity Federation 10g problems
AS10g_MidTier Oracle Application Server 10g Middle Tier problems
AS10g_Repository Oracle Application Server 10g metadata repository

Finalmente ejecutamos el setup y la coleccion para una Base de Datos con el profile 8i.
#>./rda.sh -S -p DB8i
S000INI: Initializes the Data Collection
-------------------------------------------------------------------------------
RDA uses the output file prefix to identify all files belonging to the same
data collection. The prefix must start with a letter and must contain only
alphanumeric characters.

Enter the prefix to be used for all the generated files
Hit 'Return' to accept the default (RDA)
>


Posterior a la primera recoleccion de datos, podemos utilizar RDA con las preferencias que anteriormente definimos, sin la necesidad realizar nuevamente el setup.

#>./rda.sh -vCRP

VMPlayer not compiling for latest Linux kernel ?

Como es costumbre, después de realizar un upgrade siempre hay cosas que dejan de funcionar. Aquí dejo la solución al problema que tuve con mi VmPlayer 3.1.4 después de actualizar a Ubuntu 11.10 64bits.

P/D: EL archivo que hay que descargar, lo subi a virustotal.com y esta limpio. No es una garantía .. pero.

VirtualBox Guest en Background

De la mano de me amigo @ingnucious he descubierto la utilidad de Virtual Box, VBoxHeadless, que nos permite lanzar maquinas virtuales en background, sin tener la molesta GUI de la misma. El uso es:

VBoxHeadless -s VboxName &

o

VBoxHeadless -s VboxGuest-ID &

Donde VboxName es el nombre que usamos para identificar la maquina y VboxGuest-ID es el ID asignado por VirtualBox. Despues de esto y segun el sistema operativo del guest, podemos entrar por la red usando por ejemplo: SSH o RDP. MUY BUENO.....

PodCasts Licenciamiento VMware vSphere y Transición a VMware ESXi

MUY BUENOS Podcast, de la gente de WetCom Group:

Licenciamiento VMware vSphere

http://www.wetcom.com.ar/content/podcast-que-licencia-de-vmware-comprar-escucha-nuestra-recomendacion

Claves para la Transición a VMware ESXi

http://www.wetcom.com.ar/content/podcast-2-claves-para-la-transicion-a-vmware-esxi/

¿Rebuild Index en Oracle, o no ?

La gran discusión, algunos DBA's SSr dicen que si, Oracle suport dice que no es necesario. Aun no he definido mi posición, pero lo que puedo sacar en limpio es que las distintas visiones concuerdan que hay que realizar el ANALYZE INDEX ,,,, VALIDATE STRUCTURE/COMPUTE STATICS para permitir al RDMS tomar mejores decisiones tanto a nivel estructural como en los planes de ejecucion.

Estos artículos son interesante como para comenzar.

http://www.dba-oracle.com/t_oracle_analyze_index.htm
http://www.dba-oracle.com/t_index_rebuilding_issues.htm
http://www.dba-oracle.com/t_scheduling_oracle_index_rebuilding.htm

============================================================================================
Oracle DocID 989093.1

Applies to:

Oracle Server - Enterprise Edition - Version: 8.1.7.0 to 11.2.0.1.0 - Release: 8.1.7 to 11.2
Information in this document applies to any platform.

Purpose

This article will try to outline the implications of rebuilding indexes. Indexes are often rebuilt on a regular basis, but in fact the call as to whether an index benefits from a rebuild is often not based on statistical indications and seldom is a rebuild history for an index kept.
Scope and Application

This article is intended for Database Administrators.
Index Rebuild, the Need vs the Implications

There have been many discussions about whether rebuilding indexes is useful or not. Generally speaking, the need to rebuild b-tree indexes is very rare, basically because a b-tree index is largely self-managed or self-balanced.

The most common justifications given for rebuilding an index are:
- index becomes fragmented
- index grows and grows - deleted space is not re-used
- index clustering factor becomes out of sync

In fact most indexes remain both balanced and fragmentation-free because free leaf entries will be reused. Inserts/Updates and Deletes result in free slots being scattered around the index blocks, but these will typically be refilled.
The clustering factor reflects how sorted the table data is with respect to the given index key. Rebuilding an index never has an influence on the clustering factor but instead requires a table re-organization.

Secondly the impact of rebuilding the index can be quite significant, please read the following comments thoroughly:

1. Most scripts around depend on the index_stats dynamic table. This is populated by the command:

analyze index ... validate structure;

While this is a valid method to inspect the index, it grabs an exclusive table lock while analyzing the index. Especially for large indexes, this can be very dramatic, as DML operations on the table are not permitted during that time.


2. Redo activity and general performance may increase as a direct result of rebuilding an index.

Insert/update/delete causes the index to evolve over time as the index splits and grows. When the index is rebuild it will become more tightly packed; however as DML operations continue on the table the index splits have to be redone again until the index reaches it's equilibrium. As a result, the redo activity increases and the index splits are now more likely to impact performance directly as we consume more I/O, CPU, etc to serve the index restructuring. After a certain period of time the index may again experience 'issues' and may be re-flagged for a rebuild, causing the vicious cycle to continue. Therefore it is often better to leave the index in its natural equilibrium and/or at least prevent indexes from being rebuilt on a regular basis.


3. An index coalesce is often preferred instead of an index rebuild. It has the following advantages:
- does not require approximately 2 times the disk storage
- always online
- does not restructure the index, but combines index leaf blocks as much as possible, avoiding system overhead as explained in point 2.
Note: To re-allocate an index, to another tablespace for example a rebuild is required.


Due to the reasons listed above, it is strongly advised not to rebuild indexes on a regular basis but instead use proper diagnostics.

Please see the following note which lists a script that can be used to analyze the index structure. It does not use the 'analyze index validate structure' command but is based on the current table and index statistics to estimate the index size.

Note 989186.1 : Script to investigate a b-tree index structure

Script para Desinstalar Oracle 10g

Esta es la recopilacion de la red, de que deberia borrarse para limpiar toda una instalacion Oracle 10g (RDBMS y instancias). Por que lo hago .. facil estoy probando unos productos y el ambiente esta demasiado sucio.
Oracle 11g ya dispone para realizar esta tarea.

http://pastebin.com/sCMBR6bw

Manteniendo el historial Sysstat - Estadisticas del SO en Linux/Unix

Ya hace tiempo que he habilitado las metricas de consumos de recursos (CPU,RAM,I/O,Swap,etc), con el paquete sysstat, en muchos de los servidores Linux/Unix que controlo.
Es posible habilitar las sysstat tools, para que nos genere una traza diaria de consumo de los distintos recursos del servidor, algo muy valioso a la hora de detectar problemas, activarlas no es parte de este post ya que en sangoogle hay mucha info. Las salida diaria de esta herramienta la encontramos en /var/log/sa o /var/log/sysstat, como un archivo sarXX donde XX es el dia del mes de la correspondiente salida. Magnifico todo hasta aqui, pero existe un problema, los archivos sarXX son sobrescriotos semanalmente por lo que no podemos mantener un historial completo de los consumos del equipo, por lo cual hay que buscar una forma de mantenerlos.

A tal efecto he generado el siguiente scrip, que lo podemos cronear en /etc/cron.daily para que se ejecute una vez al dia:

#!/bin/bash
#Descripcion:
# Renombra los archivos sar, para mantener el historial completo
# de los consumos del equipo.
# alejandro.andino@gmail.com
#http://pastebin.com/index/5p2Y9aX2

#ls /var/log/sa/sar* | xargs -i mv {} {}`date +"-%m-%y"`
files=`ls /var/log/sa/sar*|egrep "sar[0-9]{2}$"`
countFiles=`ls /var/log/sa/sar*|egrep "sar[0-9]{2}$"|wc -l`
if [ ${countFiles} -ne 0 ]
then
for x in $files
do
mv $x ${x}`date +"-%m-%y"`
done
fi

Esto nos dara archivos sarXX renombrados a sarXX-Mes-Año, lo que permitira que no sean borrados.

Por utilimo una herramienta espectacular para facilitar la visualizacion, entre otras cosas, de los archivos sar es ksar (http://sourceforge.net/projects/ksar/).

Guía de iniciación de Autotools

En este ultimo tiempo he estado realizando pruebas sobre la adaptacion de contenidos en paginas webs mas especificamente investigando el protocolo ICAP (RFC 3507) y sus distintas implementaciones Open Source. De la mano de SQUID, encontre una implementacion que parece prometedora pero el unico inconveniente es que hay que implementar el modulo o servicio de adaptacion de contenido uno mismo. Estoy hablando de C-ICAP ( http://sourceforge.net/projects/c-icap/ ) el cual esta desarrollado en C y C++. Por lo cual he tenido que retornar al camino de estos lenguajes y a las herramientas para manejar estos tipos de proyectos. AutoTools es esta herramineta, que nos permitira generar los clasicos archivos de instalacion configure y Makefile que usamos cuando instalamos desde los sources algun programa. Me parececio mas que interesante tener dentro de mi blog, una muy buena guia para inciar con esta herramineta: http://plagatux.es/2009/07/guia-de-iniciacion-de-autotools/ y su correspondiente doc http://plagatux.es/wp-content/uploads/2009/07/autotools.pdf

Como instalar JAVA en FreeBSD

Una publicación que valia la pena tener, despues de renegar bastante tiempo com java en FreeBSD.


Autor: Juan Jesús Vega
Fecha: 30 de Noviembre de 2004

Este documento puede ser copiado en cualquier otro sitio web siempre y cuando no se modifique su contenido sin la autorizacion de su autor y se especifique en el documento, el sitio original del documento en este caso http://siriusb.no-ip.info, el nombre de la autor(a) del documento original y el url original de donde proviene el documento.
INTRODUCCIÓN

En este documento vamos a tratar de describir el proceso de instalación y compilación de la plataforma de desarrollo JAVA nativo para FreeBSD, que se encuentra en /usr/ports/java/jdk14, así como su integración en los principales navegadores web, tales como Konqueror, Mozilla, Netscape, Firefoxa.. y finalmente su integración en la suit ofimática OpenOffice en su última versión (1.1.3); antes de nada hemos de conocer el tipo de licencia dada por SUN a sus productos, y por tanto la necesidad de incorporar "a mano" aceptando las licencias de los productos que necesitaremos descargar previa compilación de JAVA; por tanto, comenzamos con la descarga manual de los archivos necesarios para su compilación:
Descarga de ficheros necesarios

Descargamos de la web de SUN el fichero j2sdk-1_4_2_05-linux-i586.bin o bien de aquí
Descargamos de la web de SUN el fichero bsd-jdk14-patches-6.tar.gz o bien de aquí
Descargamos de la web de SUN el fichero j2sdk-1_4_2-bin-scsl.zip o bien de aquí
Descargamos de la web de SUN el fichero j2sdk-1_4_2-src-scsl.zip o bien de aquí

Todos estos ficheros han de ser colocados en /usr/ports/distfiles
Consideraciones previas a la compilación

Deberemos tener instalada y habilitada la compatibilidad con Linux

Para lo cual nos aseguraremos de que el módulo Linux.ko está presente en nuestros módulos activos,consultando al kernel mediante el comando kldstat y que está activado revisando el archivo /etc/rc.conf verificando que se encuentre presente la línea linux_enable="YES". En caso negativo, recurriremos al cd1 de FreeBSD para la instalación del port linux_base o bien mediante la instalación común a través de internet.

Deberemos tener montado el linprocfs o bien --como recomendación-- tenerlo activo en el fstab

Para lo cual y como superusuario (root), ejecutaremos el siguiente comando:

# mount -t linprocfs linprocfs /compat/linux/proc

o bien lo dejaremos permanentemente montado --ya que la ejecución posterior de java así lo requiere-- añadiéndo la siguiente línea a /etc/fstab

linproc /compat/linux/proc linprocfs rw 0 0

volveremos a ejecutar el comando kldstat para comprobar que tenemos cargados los módulos linux.ko y linprocfs.ko y a continuación el comando mount para comprobar que tenemos correctamente montado el sistema linprocfs.
Compilación de JAVA

Situados en el directorio de compilación /usr/ports/java/jdk14 ejecutamos el comando make. Tras hora y media larga en un AMD XP 2800+ 1024MB RAM DDR 400MHz corriendo en un SATA 120Gb el proceso concluirá satisfactoriamente; así pues, calculad en función de vuestra máquina. Tras lo cual, ejecutaremos el comando make install y testearemos la correcta versión instalada mediante la ejecución de javavm -version y deberemos ver el equivalente en vuestras máquinas a:

$ javavm -version

java version "1.4.2-p6"Java(TM) 2 Runtime Environment, Standard Edition
(build 1.4.2-p6-siriusb_11_nov_2004_11_17)Java HotSpot(TM) Client VM
(build 1.4.2-p6-siriusb_11_nov_2004_11_17, mixed mode)

Integración con los principales Navegadores Web

Es conveniente destacar la gran facilidad de integración con los navegadores Netscape 7.1, Mozilla, Firefox y sus derivados, pues todos ellos comparten una común arquitectura en cuanto a la gestión e inserción de plugins dentro del navegador.

Si teníamos un Navegador Web ya instalado:

Deberemos indicarle "donde reside" nuestro JAVA, así como su plugin adecuado para el navegador, para lo cual necesitaremos conocer donde se almacenan los plugins de estagama de navegadores, y es en: /usr/X11R6/lib/browser_plugins por tanto, tendremos esto muy presente ya que será en esta localización donde cada vez que iniciemos nuestro navegador preferido, esté, mirará e incorporará automaticamente todos los plugins que encuentre a esa sesión iniciada. Por tanto, nuestro objetivo es enlazar el plugin /usr/local/jdk14/jre/plugin/i386/ns610/libjavaplugin_oji.so, a ese directorio en concreto: /usr/X11R6/lib/browser_plugins, conocido esto, procederemos mediante la ejecución de:

ln -s /usr/local/jdk14/jre/plugin/i386/ns610/libjavaplugin_oji.so /usr/X11R6/lib/browser_plugins

y comprobaremos que está correctamente cargado, en la sección "Help" -->"about plugins" del navegador

En el caso particular de Konqueror: Es quizás la integración más sencilla, ya que se realiza mediante entorno gráfico. Deberemos ejecutar Konqueror (se instala por defecto con el escritorio KDE) , y en: "Preferencias" --> "Configurar Konqueror" --> "Java y Javascript" deberemos marcar "Activar java globalmente" e indicarle la ruta de donde se encuentra nuestro binario java instalado, que es en /usr/local/bin/javavm

En el caso de NO poseer ningún navegador web, no hay que realizar nada en especial, ya que como he comentado anteriormente, la integración es total, y al compilar o añadir mediante el sistema de paquetes, un nuevo navegador, esté, detectará la existencia de JAVA y la integrará directamente en su compilación.
Integración con la suite ofimática OpenOffice

Es reseñable la importancia de tener instalado JAVA antes de compilar o añadir mediante el sistema de paquetes, la suite ofimática OpenOffice, ya que si no lo hacemos estaremos limitando en gran medida a dicha suit. De igual manera es reseñable la facilidad y total integración de este port de JAVA para FreeBSD con la suite OpenOffice, ya que en la instalación de OpenOffice tán solo deberemos marcar el campo "instalación con JAVA" en el proceso de instalación (una vez ya compilada), -- No confundir el proceso de compilación e "instalación" con el proceso GRÁFICO y posterior, de la instalación de la suit-- y especificar como directorio de trabajo JAVA (el directorio donde tenemos instalado JAVA) que es: /usr/local/jdk14. Con este paso empezará el proceso de instalación gráfico de la suit a nuestro sistema con todas sus funcionalidades activadas.

Referencia:
Como instalar JAVA (JDK1.4.2-p6) en FreeBSD
sun jdk 1.6 under FreeBSD 8.1

Introducción a TimeStamping o Sellado de Tiempo - Parte II

Continuando con el Sellado de Tiempo, esta vez he realizado una interpretación y resumen de la RFC 3161 y RFCs asociadas.

Introducción

El sellado de tiempo nació, ya hace cientos de años, por la necesidad de las personas de demostrar autoría de sus teorías y descubrimientos. Hoy en día su aplicabilidad es más amplia pero su principio es el mismo, dar fe de la existencia de un dato desde un determinado momento en el tiempo.

La RFC 3161 confeccionada por IETF (Internet Engineering Task Force) define la implementación del protocolo de Sellado de Tiempo. Es decir, la forma en que se debe realizar el proceso, los medios y el contenido de los mensajes que se manipularan en una operación de Sellado de Tiempo. La RFC es ampliamente usada y es la base de otros estándares de sellado de tiempo, por lo que el buen entendimiento del mismo, asegura en gran medida, una buena comprensión de los restantes.

¿Que es el sellado de tiempo?

El Sellado de Tiempo es un servicio, que permite dar fe de que un dato ha existido desde un momento determinado en el tiempo y que el mismo no ha sido alterado.
En el proceso de sellado de tiempo, según el esquema y la norma que se utilice, actúan mínimamente dos partes, un SOLICITANTE y una AUTORIDAD DE SELLADO DE TIEMPO, TSA por su acrónimo en ingles, que actúa como una tercera parte de confianza (TTP).

¿Cuál es la función de la Autoridad de Sellado de Tiempo?

La función de la Autoridad de Sellado de Tiempo (TSA) es sellar un dato para dejar evidencia, indicando, que el dato ha existido antes de un tiempo particular. Esto puede ser usado, por ejemplo, para verificar que una firma digital fue aplicada a un mensaje antes de que el certificado correspondiente fuera revocado, así permitir a un certificado de clave publica revocado, ser usado para verificar firmas creadas antes del tiempo de revocación. Esta es una operación importante de la infraestructura de clave pública (PKI).
La TSA tiene que firmar cada uno de los mensaje de sellado de tiempo con una clave reservada precisamente para este propósito. Una Autoridad de Sellado de Tiempo (TSA) puede tener distintas claves privadas, por ejemplo: para ordenar diferentes políticas, diferentes algoritmos, diferentes tamaños de claves privadas o para incrementar la performance. El certificado correspondiente tiene que contener solamente una instancia de “extended key usage” como se define en la RFC2459 sección 4.2.1.13.

¿Cuáles son los requisitos necesarios para una TSA?

Como lo indica la RFC 3161, los requisitos de la Autoridad de Sellado de Tiempo (TSA) son los siguientes:

• 1.Usar una fuente de tiempo digna de confianza.
2.Incluir un valor de tiempo fiable, en cada respuesta (TimeStamp Token).
• 3.Incluir un entero único, para cada nuevo TimeStamp Token generado.
• 4.Producir un TimeStamp Token, para cada requerimiento valido recibido de un SOLICITANTE.
• 5.Incluir dentro de cada TimeStamp Token un identificador único para indicar la política de seguridad, por la cual el token fue creado.
• 6.Solamente un sellado de tiempo, tiene la representación de un hash de dato.
• 7.Examinar el OID de la función hash de un solo sentido, resistente a colisiones y verificar que la longitud del valor hash es consistente con el algoritmo de hash.
• 8.No examinar la huella (valor hash del dato) a ser estampado, de ninguna manera (otra verificación que no sea chequear su longitud, como especifica el punto anterior).
• 9.No incluir ninguna identificación de la entidad SOLICITANTE, en el TimeStamp Token.
• 10.Firmar cada TimeStamp Token usando la clave generada exclusivamente para este propósito y tener la clave indicada para el correspondiente certificado.
• 11.Incluir información adicional en el TimeStamp Token, si son consultadas por el SOLICITANTE usando el campo “extension”, solo para las extensiones que son soportadas por la TSA. Si esto no es posible, la TSA debe responder con un mensaje de error.

¿Como se realiza el proceso de Sellado de Tiempo?

Como primer mensaje de este mecanismo, una entidad SOLICITANTE requiere un TimeStamp Token, enviando una solicitud, un TimeStampReq, a la TSA. El TimeStampReq es una estructura de datos formada por los siguientes campos:

• version: define la versión del timestamp requerido.
• messageImprint: el OID del algoritmo hash y el valor hash, del dato a ser sellado.
• reqPolicy: si es incluido, indica la política de la TSA bajo la cual el TimeStamp Token debe ser generado.
• nonce: si es incluido permite al cliente verificar la puntualidad de la respuesta, cuando no esta disponible un reloj de forma local.
• certReq: si esta presente, indica si la respuesta debe o no incluir el certificado público de la TSA.
• extension: es un campo reservado para incluir información adicional al requerimiento en el futuro.

Los requerimientos o mensajes viajan por la red, por alguno de los protocolos de internet, como: HTTP, Socket TCP, Email y FTP.
Como segundo mensaje, la TSA responde enviando una respuesta, un TimeStampResp, a la entidad SOLICITANTE. EL TimeStampResp es una estructura de datos formada por los siguientes campos:

• PKIStatusInfo: es otra estructura de datos interna, que contiene información sobre la presencia del TimeStamp Token. También posee información de depuración en el caso de errores.
  
• TimeStampToken: es otra estructura de datos interna, definida por la RFC 5652- Cryptographic Message Syntax, que contiene los datos (el valor hash del requerimiento) firmados digitalmente por la TSA y el tiempo en el cual el TimeStamp Token fue creado (genTime). Esta estructura es compleja.
  

Al recibir la respuesta, la entidad SOLICITANTE, debe verificar el campo estado de error (PKIStatus), retornado en la respuesta. Sino existen errores, esta debe verificar varios campos contenidos en el TiemStamp Token y la validez de la firma digital del TimeStamp Token. En particular, se deberá verificar que lo que fue sellado corresponde a lo que fue solicitado para ser sellado (messageImprint == hasedMessage). El SOLICITANTE debe verificar que el TimeStamp Token contiene el certificado identificador de la TSA (Chain TSA Certificates), el valor hash correcto y el OID correcto del algoritmo hash. A continuación deberá verificar la puntualidad de la respuesta verificando el tiempo incluido en la respuesta, contra una referencia confiable de hora local. Si cualquiera de las verificaciones falla, el TimeStamp Token debe ser rechazado.
Dado que el certificado de la TSA pudo haber sido revocado, el estado del certificado deberá ser chequeado (CRLs), para verificar que el certificado es valido.
Luego la aplicación cliente debe chequear la política, para determinar si esta corresponde con el token que fue emitido para la aplicación.

¿Que estándares se pueden utilizar?

Dentro de los estándares que definen como implementar el sellado de tiempo se encuentran:
Internet X.509 Public Key Infrastructure Time-Stamp Protocol.
ANSI ASC X9.95 Standard.
ISO/IEC 18014.
Restricciones de seguridad ETSI TS 101 861.

¿Que guías existen para la creación de políticas TSAs?

Existe documentación que se puede referenciar a la hora de confeccionar políticas para Autoridades de Sellado de Tiempo.
RFC 3628 - Policy Requirements for Time Stamping Authorities (TSAs).
ETSI TS 102 023 - Policy requirements for time-stamping authorities

Referencias

RFC 3161: http://tools.ietf.org/html/rfc3161
RFC 5652: https://tools.ietf.org/html/rfc5652
RFC 3628: http://www.ietf.org/rfc/rfc3628.txt
ANSI ASC X9.95: http://en.wikipedia.org/wiki/ANSI_ASC_X9.95_Standard
Trusted timestamping: http://en.wikipedia.org/wiki/Trusted_timestamping#Classification

Introducción a TimeStamping o Sellado de Tiempo - Parte I

El timestamping es un servicio que se utiliza como una entidad externa de confianza, su funcion es dar fe, de que un dato ha existido desde un determinado momento en el tiempo, y que el mismo no ha sido modificado, esto se consigue a través de la respuesta de la TSA (Autoridad de Sellado de Tiempo). Dicha respuesta es asociada posteriormente por el requestor (solicitante del sellado de tiempo) al dato que se quiere dar fe de su existencia.

El sellado de tiempo es descrito por la RFC 3161 - Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). La RFC describe los aspectos generales del protocolo, requerimientos de la TSA (Autoridad de Sellado de Tiempo), formato de los mensajes, como se deben realizar las transacciones, métodos de transporte y consideraciones de seguridad.
Este servicio se puede utilizar con datos que han sido firmados digitalmente o no. Ya que lo que se utiliza es su huella (valor hash) que se obtiene de aplicar una función hash a los datos o conjunto de datos que se quieren estampar.

Algunas de las cosas sobre las que se debe tener claridad para evitar confusiones son:

• El documento a estampar no viaja hasta la autoridad de sellado de tiempo, solo lo hace su digesto (valor del hash) a través de un mensaje de requerimiento, TimeStampReq.
  
• Una de sus funciones es determinar la existencia de un dato desde un instante en el tiempo, cuando dice dato, dice cualquier tipo de datos, inclusive una firma digital.
  
• TimeStamping es un servicio que puede ser transportado por varios protocolos de internet como: Email,HTTP y TCP.
  
• La respuesta de la TSA, el TimestampResp, es una estructura de datos la cual contiene otras estructuras de datos, como por ejemplo el TimestampToken. Este ultimo a su vez, en uno de sus campos, contiene firmado digitalmente (con la clave privada de la TSA) el valor hash del dato que fue enviado previamente por el requestor (quien solicita el sellado de tiempo). Y el campo "genTime", el tiemstamp (YYYYMMDDHHMMSS.Z) del momento en que se realiza el sellado

Cosas que me parecieron, importante a tener en cuenta son:

• El master clock o fuente de tiempo para la TSA debe ser de referencia legal para la región de la misma. Es decir, un master clock certificado por algún organismo nacional o internacional. Los instrumentos de mayor precisión, considerados de straum 1 dentro el protocolo NTP, pueden ser GPS de gran exactitud
• Cada dato que llegue a la TSA debe ser firmado digiltamente con su clave privada.
• El algoritmo que genera el hash de los datos debe ser de un solo sentido (inyectivo), bien conocido y resistente a colisiones.
• Una TSA puede tener varias firmas digitales dependiendo de la cantidad de políticas que se posean en la misma.
• Las respuestas TimestampResp, poseen una estructura de datos opcional ,PKIFailureInfo, la cual puede brindar información muy valiosa a la hora de detectar errores.
• La clave de firma de la TSA, debe ser lo suficientemente larga para asegurar un ciclo de vida mas bien largo. Aquí se debería considerar o evaluar cada cierto tiempo, la evolución de la tecnologías que hagan mas eficiente ataques de diccionarios, de colisión y otros que vayan surgiendo en el tiempo.
• Las ventanas de tiempo entre una solicitud y una respuesta deberían considerarse a la hora de detectar ataques Man in the Middle

Por ahora, esto es lo mas importante que me ha quedado de la RFC, seguiré ampliando en otro post.