domingo, 25 de febrero de 2018

Sobre el KCV de llaves criptográficas

El key check value (KCV), dígito de chequeo en español, es un valor generalmente de 6 dígitos hexadecimales que permiten identificar de forma inequívoca a una llave criptográfica. Durante ceremonias de llaves con oficiales de seguridad, estos comparan el KCV generado por el sistema de seguridad vs el anotado en el formulario o elemento seguro donde trasladan la llave o componentes, y si la comparación es OK, entonces se da por sentado que la llave fue cargada correctamente.

Ahora bien, si no tengo el KCV como lo obtengo?, tengo forma de generarlo luego de crear la llave?, normalmente al trabajar con un HSM Thales, Atalla, Futurex, por la misma naturaleza de estos dispositivos y procedimientos de seguridad, no puedes simplemente decir luego de un tiempo, se me olvido anotar el KCV me permites el acceso al HSM para volver a obtenerlo?, en este contexto, es ideal que sepas como se genera este valor.

En primer lugar, necesitas tener la llave o componentes que forman la llave en claro y esto es potencialmente inseguro, por lo tanto, evita este procedimientos a menos que sea tu última opción o  para un entorno de prueba.

El calculo del KCV es muy simple, se utiliza triple DES, cifrando un bloqueo de al menos 16 ceros (0) con la llave criptográfica, del resultado solo capturas los primeros 6 dígitos hexadecimales.

Ejemplo:

Llave: 0123456789ABCDEFFEDCBA9876543210

Si tienes solo los componentes en claro de la llave, primero se debe realizar un XOR entre todos componentes para formar la llave.

Nota: Para este ejercicio se utiliza una llave de doble longitud 32 dígitos hexadecimal (recuerda que no es lo mismo 3DES que llaves de doble o triple longitud)

Bloque de datos para KCV: 0000000000000000

Para calcular el KCV necesitaras de una calculadora 3DES, al final de esta entrada encontrarás un link (DES.rar.quitar, renombra extension a .rar y descomprimir).

El resultado lo puedes observar en la siguiente imagen, el KCV de la llave 0123456789ABCDEFFEDCBA9876543210 es: 08D7B4

Sino tienes la llave o los componentes que la conforman en claro, no hay forma de obtener el KCV de una llave desde un criptograma (una llave cifrada con otra), por consiguiente, necesitaras obligatoriamente pedir el acceso al HSM, para el caso de los Thales, estos disponen de comandos que permiten obtener un KCV desde un criptograma de llave, siempre y cuando haya sido generado con la llave maestra de dicho dispositivo.




Link para descargar calculadora 3DES:
https://drive.google.com/open?id=1G8qlzb7XpgfZSk-zZbEi_l3pdxpQ932c


Saludos,


domingo, 21 de enero de 2018

Usando Jira Services Desk - Parte 1

Retomando el blog, y con la promesa de agregar al menos una entrada cada dos semanas, quisiera comenzar escribiendo sobre una herramienta de gran ayuda para las áreas de operaciones, soporte y servicios TIC en general, que requieran tener seguimiento y control de las solicitudes que reciben de los usuarios de la institución o público en general al cual prestan un servicio, con garantías de ANS, escalamientos efectivos y evidencias de la atención suministrada.

Este sistema se llama Jira Service Desk, de la compañía Atlassian, el mismo gigante dueño de Bitbucket, Crucible, FishEye, Bamboo, Trello, Clover, y Jira Software.

La info oficial la puedes encontrar aquí , yo explicaré mi experiencia con la herramienta en esta entrada.

Para empezar se trata de un servicio SaaS, con todas las ventajas y desventajas que esto conlleva, a la fecha el precio por usuario service desk es de 20 USD mensuales, relativamente económico si comparamos con productos similares, por ejemplo ServiceNow (ojo este es mucho mas potente y completa suite ITSM, alrededor de 100 USD por usuario).

Cuando creamos un proyecto service desk tenemos que considerar varias premisas, no solo tecnológicas sino también de procesos, el primer caso es: Como el cliente crea las solicitudes (los famosos tickets)?, una de las características más potentes de Jira Service Desk es poder hacer la creación y alimentación de los tickets, así como recibir los comentarios y resolución respectiva, desde y unicamente el correo electrónico, el sistema es bastante versátil para la creación automatica de los casos.

Otra opción para crear los ticket, es haciendo uso del portal de mesa de ayuda que provee la herramienta, aunque es una opción más potente, porque se puede enriquecer el ticket con campos específicos del evento a reportar, al contrario de los tickets creados por e-mail, que están limitados a un asunto y cuerpo de mensaje, es el menos utilizado por los clientes.

Esto no quiere decir que deban renunciar al portal de mesa de ayuda, y aquí viene lo bueno, pueden convivir y complementarse, por ejemplo, el cliente utilizará el e-mail para el reporte de los casos, recibir comentarios y actualizaciones del ticket, y el portal para el seguimiento de todos los tickets abiertos, escribir comentarios y añadir seguidores al ticket.

Por último, para cerrar esta primera entrada sobre Jira Service Desk, cuando creamos un proyecto y configuramos la opción de recibir solicitudes por correo electrónico, el sistema ofrece dos opciones: Usar un e-mail con dominio atlassian sin inbox que se genera automáticamente para el proyecto, o asociar una cuenta de email google, microsoft, etc., recomiendo usen la segunda opcion, pues aunque el sistema cloud es bastante estable, es  una práctica sana tener un repositorio propio de las solicitudes que nos envían.

Como posiblemente tengamos varios proyectos de mesa de ayuda, una buena práctica que me ha  servido para ahorrar dinero en cuentas google, ha sido definir uno o varios alias de e-mail (grupos en google), a los que asocio el e-mail atlassian automático del proyecto y la cuenta google con inbox (no configurar esta en el proyecto jira service desk, dejar solo el e-mail automático atlassian), quedaria algo asi:

Proyectos Jira Service Desk

Mesa de ayuda servicio técnico impresora. E-mail sin inbox para reporte de casos: soporte.impresora@atlassian.com --> No hace falta compartir con el cliente.


Mesa de ayuda soporte televisores. E-mail sin inbox para reporte de casos: soporte.televisores@atlassian.com --> No hace falta compartir con el cliente.


Google Svc

E-mail: soporte@google.com

Grupos (alias): soporte.impresora@google.com, soporte.televisores@google.com  --> Estos emails serán los entregados a los clientes para el reporte de los casos.

Dentro del grupo soporte.impresora@google.com, seran agregados los e-mail: soporte.impresora@atlassian.com y soporte@google.com

Dentro del grupo soporte.televisores@google.com, seran agregados los e-mail: soporte.televisores@atlassian.com y soporte@google.com


De esta manera, cada vez que envíen un correo electrónico de soporte, se creará un ticket en Jira Service Desk y tendremos una copia en la cuenta google con inbox.





Espero sea de utilidad, un abrazo.

viernes, 28 de octubre de 2011

Diferencias entre emisor magstripe grade y full grade (Mastercard)

Este es mi segundo post, y quisiera aclarar un poco un tema que causa tanta confusión, que diferencia hay entre un emisor magstripe grade y full grade (Mastercard)?

Basicamente la diferencia esta en el procesamiento de la transacción por el emisor y la respuesta que este genera, recordando que a nivel de adquiriencia se debe estar en modalidad Full Grade, la operación viajará con los bits de EMV, campo 55 y 23 en la mensajeria, generalmente bajo estándar ISO8583, estos campos serán ignorados por el emisor Magstripe Grade (partial grade), obviamente no se incluye data emv en la respuesta de la operación. Anexo diagrama (disculpen la calidad gráfica):


 Para el caso de un emisor Full Grade, el escenario cambia con el uso de los datos emv que viajan en los bits 55 y 23 del mensaje, se procesan datos de chip (por ejemplo parametros de riesgo, validaciones)  y se envia una respuesta a la tarjeta, por ejemplo un mensaje ARPC o incluso scripts ( bloqueo de aplicación, sincronización del Pin-offline, etc.,), anexo diagrama de un emisor Full Grade.


lunes, 24 de octubre de 2011

Introducción a EMV

 
EMV es un estándar global para tarjetas de pagos de crédito y débito con base en tecnología de chip. Introducido por Europay, MasterCard y Visa en 1994.
 
EMV garantiza interoperabilidad de tarjetas y terminales.  
 
Los estándares EMV son publicados y mantenidos por EMVCo, organismo propiedad de AMEX, JCB, MasterCard y Visa.

 



¿Qué es una tarjeta con chip?

 
Una tarjeta con chip es similar a una computadora. Tiene:


Sobre el KCV de llaves criptográficas

El key check value (KCV), dígito de chequeo en español, es un valor generalmente de 6 dígitos hexadecimales que permiten identificar de form...