28 dic 2011
23 dic 2011
Rsync falla con tareas programada CRON !!!
/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.
6 dic 2011
Sistemas de Monitoreo de Infraestrucutura.
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:
21 nov 2011
DigiNotar Certificate Authority breach
Via: Cert INTECO Gathering
10 nov 2011
Oracle Distributed Recovery process
determine which version of the data to display for a query.
3 nov 2011
Oracle Backgroung Process !!!
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.
1 nov 2011
Oracle 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.
27 oct 2011
Oracle RDA (Remote Diagnostics Tools)
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
#> 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
21 oct 2011
VMPlayer not compiling for latest Linux kernel ?
P/D: EL archivo que hay que descargar, lo subi a virustotal.com y esta limpio. No es una garantía .. pero.
7 oct 2011
VirtualBox Guest en Background
17 jun 2011
PodCasts Licenciamiento VMware vSphere y Transición a VMware ESXi
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/
8 jun 2011
¿Rebuild Index en Oracle, o no ?
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
7 jun 2011
Script para Desinstalar Oracle 10g
Oracle 11g ya dispone para realizar esta tarea.
http://pastebin.com/sCMBR6bw
31 may 2011
Manteniendo el historial Sysstat - Estadisticas del SO en Linux/Unix
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/).
6 abr 2011
Guía de iniciación de Autotools
11 mar 2011
Como instalar 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
18 feb 2011
Introducción a TimeStamping o Sellado de Tiempo - Parte II
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/rfc3161RFC 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
4 feb 2011
Introducción a TimeStamping o Sellado de Tiempo - Parte I
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
- 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.