Medina, Gastón Nicolás INGENIERIA EN COMPUTACION

Medina, Gastón Nicolás INGENIERIA EN COMPUTACION
U.N.C. Facultad de Cs. Exactas, Físicas y Naturales Proyecto Integrador: Construcción de Driver de usuario para dispositivo Encrypted PinPad utilizando Desarrollo Conducido por Modelos Medina, Gastón Nicolás INGENIERIA EN COMPUTACION Córdoba

Contenidos Presentación del Proyecto Integrador
Descripción, motivación, objetivos, alcance. Características de los elementos del Sistema Terminal Kiosk, Driver, Teclado Encriptado (Epp) y Aplicación Cliente Genérica (ACG) Protocolos de Comunicación Metodología de Desarrollo Patrones de Seguridad, Políticas de Seguridad y Construcción de Modelo Final del Sistema Herramientas Utilizadas Demostración de los Productos Finales Conclusiones del Proyecto Integrador Preguntas Agradecimientos En esta presentación, veremos: de q se trata el proyecto, una descripción general, motivación …. Dividiremos el proyecto en 2 etapas: Características de los Componentes del Sistema El entorno donde se encuentran insertados, las especificaciones que tenían q cumplir cada uno de los productos que construí y la manera de comunicar todos estos elementos entre si Metodología implementada para el Desarrollo del proyecto Los procesos que la componen, las herramientas que se utilizaron, las ventajas y el porq CONTENIDOS | INTRODUCCIÓN | KIOSK | DRIVER | EPP | ACG | PROTOCOLO |

Introducción Descripción de Proyecto
Solución de software para la integración de un teclado encriptado (EPP) a aplicaciones para terminales Kiosk. Problema presentado por empresa Mediterránea S.A. a Neosur S.A. Driver Encrypted Pin Pad (EPP) No disponible en el mercado. No proporcionado por fabricante. Requerimientos específicos para prestar servicios a aplicaciones de Terminales Kiosk. Aplicación Cliente Genérica (ACG) Aplicación Cliente del Driver EPP. Validación y testing de todas las funcionalidades que el Driver del dispositivo EPP soporta. Explicacion de cómo surge el proyecto CONTENIDOS | INTRODUCCIÓN | KIOSK | DRIVER | EPP | ACG | PROTOCOLO |

Introducción Motivación Importancia del Proyecto Alcance del Proyecto
Solución de administración de dispositivos en Kiosco (Kiosk) No existente en el mercado. Importancia del Proyecto Entidades Financieras (Bancos) Millones de usuarios Información critica Alcance del Proyecto Driver dispositivo EPP (Encrypted Pin Pad) Aplicación Cliente Genérica (ACG - Testing) CONTENIDOS | INTRODUCCIÓN | KIOSK | DRIVER | EPP | ACG | PROTOCOLO |

Introducción Objetivos Principales Secundarios
Construir Driver para dispositivo EPP Construir ACG para testing de utilidad para simular diferentes sistemas clientes consumidores del Driver. Secundarios Utilizar un método conducido por Modelos Utilizar patrones de seguridad en etapas tempranas del proceso de diseño. CONTENIDOS | INTRODUCCIÓN | KIOSK | DRIVER | EPP | ACG | PROTOCOLO |

Terminal Kiosk Dispositivo independiente y de auto-servicio.
Utilizado para proveer un servicio particular a su usuario. Beneficios: Comodidad a sus usuarios. Costos reducidos. Generalmente se ubican en aéreas públicas (centros de compras y bancos). CONTENIDOS | INTRODUCCIÓN | KIOSK | DRIVER | EPP | ACG | PROTOCOLO |

Driver o Controlador de Dispositivos
Definición: Sistema de software que le permite a aplicaciones de alto nivel interactuar con un periférico de entrada y/o salida. Propósito: Simplifica su programación. Dispositivos Drivers Computadora Un Driver o Controlador de un dispositivo de hardware, es un sistema de software que le permite a aplicaciones de alto nivel interactuar con un periférico de entrada y/o salida. Para focalizar este concepto sobre este proyecto, por un lado se tiene el dispositivo auxiliar e independiente, como es el caso del EPP, conectado físicamente a la CPU de una computadora (por ejemplo a través del puerto USB) y por el otro se tiene una aplicación de alto nivel que quiere hacer uso del dispositivo. Para vincularlos se construye un Driver, que presenta a la aplicación de alto nivel una abstracción del hardware y proporciona una interfaz para poder utilizarlo de manera amigable. Cuando una aplicación de alto nivel invoca una rutina del Driver, éste es el encargado de generar y enviar los comandos necesarios al dispositivo de hardware para efectuar la acción requerida. dependientes y específicos para cada Sistema Operativo. El propósito de construir un Driver para un dispositivo de hardware es simplificar su programación, actuando como una capa de abstracción entre el dispositivo mismo y aplicaciones de alto nivel. De este modo, una aplicación de alto nivel puede ser construida de forma independiente del dispositivo de hardware, donde el Driver estará a cargo de interpretar y traducir comandos de alto nivel en comandos de bajo nivel, específicos de un dispositivo de hardware, de la manera en que este último los requiera CONTENIDOS | INTRODUCCIÓN | KIOSK | DRIVER | EPP | ACG | PROTOCOLO |

Driver o Controlador de Dispositivos
Diseño Modularizado Capa Lógica Capa Física Modos de Ejecución Modo Kernel Modo Usuario Driver Aplicación de Usuario Capa Lógica Dispositivo Electrónico Capa Física PC Sistema Operativo – Kernel Servicios del Sistema Operativo Aplicaciones espacio de usuario El diseño de un Driver puede modularizarse en dos capas, una capa lógica y una capa física. La capa lógica se encarga de procesar los datos enviados por la aplicación de alto nivel y requeridos para controlar un dispositivo específico. Por otro lado, la capa física se comunica directamente con la instancia del dispositivo [Microsoft, DD]. En una secuencia de ejecución convencional, todas las peticiones que realiza la aplicación de alto nivel al Driver, descienden por la capa lógica, se procesan, continúan por la capa física y se comunican finalmente al dispositivo. Inversamente, las respuestas del dispositivo circulan desde la capa física, se procesan y continúan por la capa lógica hacia la aplicación de alto nivel Un Driver puede ser construido tanto como parte del kernel del Sistema Operativo o separadamente como módulo recargable. La ventaja de estos últimos, es que pueden ser cargados solo cuando son necesarios y luego descargarse, ahorrando memoria de kernel Un Driver puede ser escrito en modo kernel (versión Nivel 0) o en modo Usuario (versión Nivel 3) (ver Figura 2.MT - Anillos de Privilegio). Sin Embargo, cuando un Driver en modo kernel falla, por ejemplo por sobrescribir la memoria del kernel o de otro proceso de usuario, puede tirar abajo un Sistema Operativo entero, mientras que una falla de un Driver en modo Usuario causa generalmente, que se caiga el proceso mismo, dejando al Sistema Operativo intacto; permitiendo al usuario restaurar el Driver nuevamente Ventaja de estabilidad del sistema Desventajas: Por otro lado, las transiciones de modo Usuario a modo kernel y viceversa, suelen imponer una sobrecarga de rendimiento; lo que hace no recomendable la construcción de un Driver en modo Usuario para requerimientos de baja latencia y alto rendimiento Nivel 0 Nivel 1 Nivel 2 Supervisor Usuario 1 2 3 Nivel 3 CONTENIDOS | INTRODUCCIÓN | KIOSK | DRIVER | EPP | ACG | PROTOCOLO |

Dispositivo Encrypted PinPad - EPP
Dispositivo de encripción multipropósito. Teclado de alta durabilidad, resistencia a vandalismos. Modelo KY3688/B. Cumple con los estándares: “VM PCI certification” “China Banking system certification” “CE” “IP64” Servicio de Seguridad Norma DES SO (igual a ANSI X3.92) 3DES ANSI X9.52 PIN ISO9564-1/2 (igual a ANSI X9.8) e IBM3624 MAC ISO8732 (igual a ANSI X9.9) Seguridad general PCI CONTENIDOS | INTRODUCCIÓN | KIOSK | DRIVER | EPP | ACG | PROTOCOLO |

Funcionalidades: Administración de Claves Ingreso de PIN Ingreso de Dígitos Individuales Desatendidas: Generación de Nonce. Algoritmo MAC. Estas son las funcionalidades que se requieren poder ser ejecutadas por cualquier aplicación cliente que se comunique con el driver CONTENIDOS | INTRODUCCIÓN | KIOSK | DRIVER | EPP | ACG | PROTOCOLO |

Administración de Claves: Clave de Administrador Clave de Transmisión Clave de Autenticación Clave Máster Clave de Trabajo 0 a la 3: PIN. 4 a la 7: MAC. 8 a la 11: Nonce. 12 a la 15: Dígitos. Claves de Administración Claves de Transmisión Claves Maestras Claves de Autenticación Claves de Trabajo Proceso de seguridad mas importante del dispositivo El Epp posee 4 tipos de claves: clave de transmisión, clave de autenticación, clave maestra y clave de trabajo. La clave de transmisión, clave que encripta clave de autenticación y la clave maestra, es usada para descargar la clave maestra y la de autenticación. Existe solo una clave de transmisión de 24 bytes. La clave de autenticación, clave que encripta/desencripta los datos random, es usada para la autenticación segura de ambos lados. Existen 16 claves de autenticación, el cual cada una es de 24 bytes. La clave maestra, clave que encripta la clave de trabajo, es usada para descargar la clave de trabajo. La clave de trabajo es usada para encriptar los datos generales. Existen 16 claves de trabajo de 24 bytes. Cada clave maestra administra 1 clave de trabajo. Las claves de trabajo Nº 0-3 son usadas para el PIN, las claves Nº 4-7 son usadas para el algoritmo MAC, las claves Nº 8-11 son usadas para encripcion de datos y las claves Nº son usadas para la encripcion de DIGITOS. CONTENIDOS | INTRODUCCIÓN | KIOSK | DRIVER | EPP | ACG | PROTOCOLO |

Ingreso PIN Etapas: Ingreso Dígitos HOST PIN PINBLOCK ‘*’ ‘*’ ‘*’ EPP Ingresa Digito Ingresa ENTER Ingresa Digito Ingresa Digito 1.Pedido de Pin 2.Recepción de Dígitos Ocultos 3.Recepción de Pinblock HOST DIGIT DIGITBLOCK DIGITBLOCK EPP Ingresa ENTER Ingresa Digito Ingresa Digito Funcionalidades centrales de una aplicación cliente 1.Pedido de Dígitos 2.Recepción de DigitBlock CONTENIDOS | INTRODUCCIÓN | KIOSK | DRIVER | EPP | ACG | PROTOCOLO |

Aplicación Cliente Genérica - ACG
Aplicación capaz de consumir todas las funcionalidades que soporta el Driver del EPP. Testing y validación. Pertenece al producto final. Utilizada por el centro de desarrollo del cliente final como guía para la construcción de Aplicaciones de Auto-consulta especificas. CONTENIDOS | INTRODUCCIÓN | KIOSK | DRIVER | EPP | ACG | PROTOCOLO |

Protocolo de Comunicación
ACG – Driver: Modelo Cliente- Servidor. Protocolo TCP (IP:Puerto - LocalBind) [Registro] Formato de codificación de Request/Response (XML). Request (3 componentes): XML Versión Comando Parámetros EOT Length Request 0000 Requerimientos de comunicación de aplicaciones de terminales Kiosk. Todos los drivers construidos respetan este protocolo Capa Logica: ACG - Driver <?xml version="1.0" encoding="UTF-8" ?> <{comando}> <{ parámetro_x }>{value_x}</{ parámetro_x }> <{ parámetro_y }>{value_y}</{ parámetro_y }> </{comando}> CONTENIDOS | INTRODUCCIÓN | KIOSK | DRIVER | EPP | ACG | PROTOCOLO |

Response (4 componentes): XML Versión Comando Result Result_data Driver – EPP Puerto Rs232 (Usb Converter) SOC (Start of Command): 0x02 EOC (End of Command): 0x03 BCC: LEN ^ CMD ^ DATA <?xml version="1.0" encoding="UTF-8" ?> <{comando}> <result> <code>{errCode}</code> <message>{errMessage}</message> </result> <result_data>{data}</result_data> </{comando}> Capa Fisica: Driver - Epp SOC LEN CMD DATA BCC EOC CONTENIDOS | INTRODUCCIÓN | KIOSK | DRIVER | EPP | ACG | PROTOCOLO |

Metodología de Desarrollo
Patrones de Seguridad Políticas de Seguridad Construcción de Modelos Patrones de seguridad: Solinas afirma que “incorporar patrones de seguridad en etapas tempranas del proceso de desarrollo de software es la forma más eficaz de construir software seguro” [1]. Afirmación que justifica enunciando que “los patrones de seguridad representan las mejores prácticas logradas por la industria a fin de detener o limitar ataques; inferimos que el permitir y promover que dichos patrones guíen el proceso de desarrollo de software y la construcción de modelos de análisis, son criterios que deben estar incorporados a un método de producción de software seguro” Modelos y Politicas de Seguridad: “Los modelos y las políticas de seguridad son el punto de partida de un diseño seguro. Las políticas de seguridad son directivas de alto nivel que definen la forma en que un sistema lleva a cabo el desempeño de sus funcionalidades en su totalidad. Las políticas de seguridad determinan que estado de un sistema es un estado autorizado o un estado no autorizado.” METODOLOGIA | PATRON DE SEGURIDAD | DIAGRAMA | MODELO FINAL | DEMOSTRACION

Patrones de Seguridad “los patrones de seguridad describen problemas particulares y recurrentes de seguridad que se dan en contextos específicos, y presentan esquemas genéricos bien definidos para su solución” Presentados en formato de Templates Campos (Sinopsis, Contexto, Problema, Fuerzas, Solución) Estructura Estática (Diagrama de Clases) Estructura Dinámica (Diagrama de Secuencia) Los patrones de seguridad proveen un modelo de solución genérico de desarrollo para un problema particular. METODOLOGIA | PATRON DE SEGURIDAD | DIAGRAMA | MODELO FINAL | DEMOSTRACION

Políticas de Seguridad Asignación de Roles Administrador - Usuario Control de Autorización Claves Control de Auditoría Archivo Log Autenticación de Usuarios Administrador Autenticación de Operaciones Ingresar Pin Ingresar Dígitos Descargar Clave de Trabajo Asignación de Roles: En el sistema deben existir dos roles de usuarios cada uno con sus derechos para realizar las funcionalidades correspondientes (ver sección Administración de claves del EPP). Control de Autorización: Esta política es un caso particular de la “política de sistema cerrado”, donde nada es accesible a menos se autorice explícitamente. Un refinamiento de la “política de sistema cerrado” es la “política de menor privilegio”, que establece que sólo se debe autorizar el acceso a recursos computacionales necesarios para desempeñar las funciones que demanda la tarea a realizar. Luego, el control de autorización podrá permitir, denegar o imponer las condiciones de acceso a cualquier entidad activa (ver sección Descripción de claves). Control de Auditoría: Se debe registrar en un archivo de auditoría todo lo que se hizo en algún momento. (ver sección Especificaciones del Modelo - Auditoria). Autenticación de Usuarios: Para la ejecución de las funcionalidades de Administración de Claves el/los usuario/s debe/n ser autenticado/s (ver sección Ingreso de Claves de Administrador). Autenticación de Operaciones: Todo intercambio de información destinado a ser una operación debe ser autenticado en ambos extremos. Este proceso de autenticación de operaciones debe implementarse en las siguientes funcionalidades (ver sección Autenticación mutua y activación de clave de trabajo): Ingresar Pin (ver sección Proceso de ingreso de PIN-a) Ingresar Dígitos (ver sección Proceso de ingreso de dígitos-b) Descargar Clave de Trabajo (ver sección Descarga de clave Maestra – clave de Autenticación – clave de Trabajo) METODOLOGIA | PATRON DE SEGURIDAD | DIAGRAMA | MODELO FINAL | DEMOSTRACION

Autenticación de Operaciones Autenticación mutua y activación de clave de trabajo El proceso de autenticación mutua entre Host y EPP se inspira en un trabajo propuesto por Needham, R. y Schroeder, M. [RM Needham, 1978]. Este es un patrón de seguridad conocido como patrón Authenticator. PROCESO: . En el punto de partida, A y B han intercambiado exitosamente sus claves públicas KUa y KUb. A continuación, A envía su Identificación IDA y un nonce N1, ambos encriptadas con la clave pública de B, KUb. B los recibe, desencripta la información con su clave privada, KRb y extrae N1 . Genera su propio nonce N2, lo adjunta al enviado por A, encripta ambos utilizando la clave pública de A, KUa y envía el resultado. A recibe esa información, la desencripta con su clave privada, KRa y extrae N2 y se lo reenvía a B, encriptado con la clave pública de B, KUb. Llegado a ese punto, ambos extremos han podido demostrar su identidad. El resto es simplemente enviar una clave secreta, Ks para ser utilizada en un servicio de criptografía simétrica. A le envía Ks, asegurando servicios de confidencialidad y autenticación utilizando la clave pública de B, KUb y su clave privada KRa. Hay que decir que lo desencripta con la su clave privada KRB Referencias N1-N2 Nonce IDA Identificación EKUB - EKUB Claves Publicas EKRA - EKRB Claves Privadas KS Clave Secreta Criptografía Simétrica METODOLOGIA | PATRON DE SEGURIDAD | DIAGRAMA | MODELO FINAL | DEMOSTRACION

Autenticación mutua y activación de clave de trabajo HOST EPP 1) <A_Key_No> + <S_Key_No> + <NH> 2) <NH_3des = 3DESH<A_Key_No>(< NH >)> 3) <ACK> Referencias A_Key_No Numero de Clave de Autenticación S_Key_No Numero de Clave de Trabajo NX_3des Nonce encriptado 4) <A_Key_No> + <S_Key_No> + < NK > Términos utilizados en este proceso: A_Key_No: índice indicando número de clave de autenticación S_Key_No: número de clave de trabajo. NH: nonce generado por Host para autenticarse con EPP NH_3des: NH encriptado utilizando algoritmo 3DES NK: nonce generado por EPP para autenticarse con Host NK_3des: NK encriptado utilizando algoritmo 3DES Secuencia de ejecución: Host envía comando de petición de autenticación al EPP, con la siguiente información: <A_Key_No> + <S_Key_No> + <NH> EPP recibe petición de autenticación del Host. Utiliza la clave de autenticación indicada por <A_Key_No> para encriptar con 3DES el valor < NH >; y envía este autenticador al Host, más <A_Key_No> y <S_Key_No> NH_3des = 3DESK<A_Key_No>(< NH >) Si ocurriese que la posición indicada por <A_Key_No> está vacía, el comando no podrá ser ejecutado. El Host recibe autenticador enviado por EPP Utiliza la clave de autenticación indicada por <A_Key_No> para desencriptar <NH_3des> y obtener N’H. Compara < NH > con < N’H >. Si son iguales el proceso de autenticación de EPP ha sido exitoso y se lo comunica al EPP. EPP recibe resultado de su proceso de autenticación y envía petición de autenticación al Host. Si el proceso de autenticación de EPP, iniciado por el Host ha sido exitoso, EPP envía su comando de petición de autenticación al Host, con la siguiente información: <A_Key_No> + <S_Key_No> + <NK> Host recibe petición de autenticación del EPP. Utiliza la clave de autenticación indicada por <A_Key_No> para encriptar con 3DES el valor < NK >; y envía este autenticador al EPP, más <A_Key_No> y <S_Key_No>. NK_3des = 3DESK<A_Key_No>(< NK >) EPP recibe autenticador enviado por Host Utiliza la clave de autenticación indicada por <A_Key_No> para desencriptar <NK_3des> y obtener N’K: Compara < N’K > con < NK >. Si son iguales, el proceso de autenticación de Host ha sido exitoso y se lo comunica al Host (Autenticación de Operaciones - ver sección Políticas de Seguridad-c ). Este caso es importantísimo. Habría que definir cuales son los assets que hay que proteger. Por ejemplo, la clave privada que se encuentra en el host debe estar protegida de alguna forma. Es un asset muy importante. 5) <NK_3des = 3DESK<A_Key_No>(< NK >)> 6) <ACK> METODOLOGIA | PATRON DE SEGURIDAD | DIAGRAMA | MODELO FINAL | DEMOSTRACION

Construcción de Modelos Desarrollo de un modelo contextual del dominio del sistema LEL (Léxico Extendido del Lenguaje) Escenarios Tarjetas CRC (Clase, Responsabilidad y Colaboración) Gestión de requerimientos Requerimientos Dinámicos Trazabilidad Para desarrollar un modelo contextual del dominio del sistema que le un marco a los requerimientos se propone el uso de LEL (Léxico Extendido del Lenguaje), Escenarios y tarjetas CRC (clase, responsabilidad y colaboración). Este modelo es propuesto y utilizado por Solinas en su publicación [Solinas, 2009]. Debido q Existe un alto nivel de dependencia entre un software de calidad y una correcta detección, compresión y análisis de los requerimientos funcionales de un proyecto. Por ello debe hacerse una gestión adecuada de los requerimientos y utilizarse un esquema de trazabilidad (traceability) para seguirles el rastro a lo largo de todo el ciclo de vida de desarrollo del software, recomienda Antonelli en [L., 2003]. Es necesario mantener concordancia entre los requerimientos cambiantes del cliente y los que utiliza el equipo de desarrollo, ya que los requerimientos son dinámicos. Esta sincronización se conoce como gestión de requerimientos. La trazabilidad es un atributo de la especificación de requerimientos de software (SRS). El estándar IEEE lo define como: "Una especificación de requerimientos es traceable si (i) el origen de cada uno de sus requerimientos está claro y si (ii) facilita la referencia de cada requerimiento en artefactos de desarrollo futuro o documentación.” [2] Por tanto, inferimos que la trazabilidad de requerimientos permite relacionar de manera directa las funcionalidades implementadas por el sistema con los requerimientos que las generaron, siendo identificables en todo el ciclo de desarrollo. METODOLOGIA | PATRON DE SEGURIDAD | DIAGRAMA | MODELO FINAL | DEMOSTRACION

Léxico Extendido del lenguaje (LEL) Permite capturar el lenguaje de un dominio Identificación y definición de los símbolos propios de un contexto Objetivo: Conocer el vocabulario del problema Registrar signos (palabras o frases) los cuales son peculiares a un dominio La idea bajo el LEL es muy simple, hay que preocuparse por entender el lenguaje del problema, sin preocuparse por entender el problema [Leitte, 2003]. El principal objetivo del LEL es conocer el vocabulario del problema. De esta manera constituye el primer paso en el proceso de construcción del producto de software. El LEL es una especie de glosario, ya que su objetivo principal es registrar signos (palabras o frases) los cuales son peculiares a un dominio. A diferencia del diccionario tradicional en donde cada término tiene un sólo tipo de definición, en el LEL cada signo es descripto de dos formas: a través de la noción y de los impactos. La noción es la descripción del tipo usual que da el diccionario. Es la descripción del signo por medio de sus propiedades intrínsecas. Mientras que los impactos determinan como el signo descripto se relaciona con los demás. Los impactos describen la incidencia del signo en los demás o la de los demás en el signo [L., 2003]. Sinónimos Identifica la entrada del LEL Noción Se describe que es el símbolo Impacto Se describe como repercute en el sistema METODOLOGIA | PATRON DE SEGURIDAD | DIAGRAMA | MODELO FINAL | DEMOSTRACION

LEL, Escenarios y Tarjetas CRC LEL y Escenarios se utilizan para capturar y abstraer conocimiento y comportamiento del dominio en el cual se utilizará un sistema de software. Reglas de Derivación de Tarjetas CRC de Leonardi. Obtenidas a partir de Entradas LEL y Escenarios Trazabilidad LEL Escenarios REGLAS Tarjetas CRC Cambios en el dominio del sistema? Luego de identificar todos los signos presentes en el dominio del problema, nos encontramos en posición de, por medio de los diagramas de caso de uso, desarrollar los escenarios de cada requerimiento funcional. A partir de ambos se obtienen en forma sistemática tarjetas CRC” [1]. Leonardi [Leonardi, 2001] desarrolló un conjunto de reglas para obtener tarjetas CRC a partir de LEL y Escenarios. Es decir, “cuando la realidad del dominio donde se utilizará un sistema de software cambia, el LEL y los escenarios también deben cambiar para que se mantenga consistente con el dominio que modelan. Luego, las tarjetas CRC también se deben modificar porque sus orígenes lo han hecho. Los cambios del dominio impactan en el LEL y en los escenarios. Luego se propagan a las tarjetas CRC, para proyectarlos por el resto de los productos del ciclo de vida del software”[2]. METODOLOGIA | PATRON DE SEGURIDAD | DIAGRAMA | MODELO FINAL | DEMOSTRACION

Baseline Mentor Workbench (BMW) Problema: La tarea de determinar los cambios producidos en LEL y Escenarios, seleccionar la regla adecuada y aplicarla, es una tarea ardua, propensa a errores. Solución: Automatizar el proceso de derivación de Tarjetas CRC. BMW es una herramienta que administra las entradas de LEL, Escenarios y las tarjetas CRC implementando las reglas de Leonardi. METODOLOGIA | PATRON DE SEGURIDAD | DIAGRAMA | MODELO FINAL | DEMOSTRACION

Detección de Patrón de Seguridad
No existe una técnica especifica. Tarea no automatizada Funcionalidad Encripción / Desencripción Problema Confidencialidad Solución Arquitectura Criptográfica Orientada a Objetos Genérica (GOOCA) Arquitectura de software genérica para aplicaciones criptográficas Desacoplamiento La manera de detectar o encontrar un patrón de seguridad es por medio del análisis del dominio del problema. Por medio de las Tarjetas CRC deducidas del análisis realizado sobre las entradas LEL y sus correspondientes Escenarios, se detectaron el uso de las funcionalidades Encripcion y Desencripcion para mitigar el ataque sobre la confidencialidad. La solución mas adecuada, es la solución mas segura, un patrón. GOOCA Este patrón permite diseñar una micro-arquitectura orientada a objetos para un diseño criptográfico y facilita la reutilización de estos componentes. Su aplicación tiene como objetivo lograr una transformación criptográfica exitosa y desacoplar el sistema a desarrollar de aquella transformación. Por tanto resumimos las ventajas de utilización de este patrón en dos: Se pueden obtener más fácilmente sistemas flexibles y adaptables, con requerimientos de seguridad basados en criptografía, cuando los algoritmos criptográficos son desacoplados de sus implementaciones, y a su vez éstas son desacopladas de los servicios criptográficos que utilizan. Los requerimientos de seguridad basados en criptografía son generalmente requerimientos no funcionales de aplicaciones de propósitos generales y no deberían contaminar la funcionalidad de aquellas aplicaciones. La separación explícita de aspectos en dos tipos de requerimientos facilita su lectura y reutilización. METODOLOGIA | PATRON DE SEGURIDAD | DIAGRAMA | MODELO FINAL | DEMOSTRACION

Detección de Patrón de Seguridad
GOOCA Envío con Autenticación Confidencialidad con Envío Autenticado Confidencialidad Confidencialidad con Firma Confidencialidad con Firma con Apéndice Firma Firma con Apéndice Integridad del Mensaje Confidencialidad con Integridad Patrón de diseño criptográfico y sus relaciones Estructura GOOCA Este sistema plantea, como se vio en la autenticación de operaciones, la implementación de un patrón de seguridad, llamado autenticator, para la ejecución de las funcionalidades criticas. El patrón requiere de servicios de confidencialidad Patrones de diseño criptográfico y sus relaciones METODOLOGIA | PATRON DE SEGURIDAD | DIAGRAMA | MODELO FINAL | DEMOSTRACION

Diagrama de Metodología de Desarrollo
Conocimiento Dominio de Seguridad Lenguaje + Comportamiento Conocimiento especifico del Dominio Patrones de Seguridad Problem Forces Solution Patrones de Seguridad -LEL -Escenarios -Tarjetas CRC Dominio Especifico Análisis de Patrones de Seguridad Análisis Especifico del dominio Modelo de análisis con Patrones de Seguridad embebidos METODOLOGIA | PATRON DE SEGURIDAD | DIAGRAMA | MODELO FINAL | DEMOSTRACION

Modelo Final del Sistema
Sistema ACG – Driver – EPP Protocolo de Comunicación d = recieve(x) send(x) Alice + send() + recieve() ACG + send() + recieve() Bob + send() + recieve() EPP + send() + recieve() Driver m = g(d) m = g(x) m = g(f(m)) x = f(m) Codificador f() Decodificador g() Algoritmo Criptográfico Transformación Criptográfica METODOLOGIA | PATRON DE SEGURIDAD | DIAGRAMA | MODELO FINAL | DEMOSTRACION

Demostración Pruebas de Aplicación Cliente Genérica – Driver – EPP
METODOLOGIA | PATRON DE SEGURIDAD | DIAGRAMA | MODELO FINAL | DEMOSTRACION

Demostración METODOLOGIA | PATRON DE SEGURIDAD | DIAGRAMA | MODELO FINAL | DEMOSTRACION

Conclusiones Productos Finales
Driver EPP (único a producción) y ACG Metodología para el modelado y gestión de requerimientos LEL, Escenarios y CRC Relación con el Cliente BMW Trazabilidad y cambios de requerimientos Modelo del sistema Integración con Patrones de Seguridad Seguridad en Etapas Tempranas del ciclo de desarrollo Reducción de Costos Solución de ingeniería de software Mejor solución Es importante destacar que los patrones de diseño recomiendan el desacoplamiento de las clases, mientras que esta metodología propone una situación opuesta. Establece que la fusión de un patrón de seguridad con el modelo del sistema no genera un objeto grueso. Sino que por ser los servicios de seguridad una función lineal (x = f(m)), no se agregan métodos al objeto que requiere de estos servicios, sino que se encapsulan en los métodos nativos del objeto. CONCLUSIONES | FUTURO | PREGUNTAS | AGRADECIMIENTOS

Futuro Seguridad no garantizada en implementación del sistema.
Gestión de requerimientos por Missuse Cases Construcción de EPP -La metodología utilizada para el modelado y gestión de requerimientos del presente sistema no asegura que su implementación corresponda con la mejor solución de servicios de seguridad -Existe otro enfoque de gestión de requerimientos planteados por Fernández en [Eduardo B. Fernández M. V., 2006] y por Alexander en [Alexander, 2003] que presentan la detección y anulación de ataques al sistema desde los casos de usos a través de lo que llaman “casos de mal uso” (missuse cases). Este enfoque no es el más adecuado para el caso particular de este Proyecto Integrador debido a que el dispositivo EPP impuso limitaciones de diseño al estar completamente acotado por no ser posible modificar su implementación. Esta metodología es una deuda de análisis y diseño que posee el presente Proyecto Integrador. Por tanto, queda para trabajos futuros el estudio, análisis, desarrollo y posible fusión de este método enunciado con la metodología implementada para el modelado y gestión de requerimientos de este proyecto. - CONCLUSIONES | FUTURO | PREGUNTAS | AGRADECIMIENTOS

Preguntas Consultas o dudas generadas en el transcurso de la presentación. CONCLUSIONES | FUTURO | PREGUNTAS | AGRADECIMIENTOS

Agradecimientos A mi Familia. Neosur S.A. Mediterránea S.A.
Director Miguel Solinas y Co-Director Pablo Passera Eduardo Gaite, Gino Turco y Emanuel Villarruel, colaboradores directos del proyecto. Todos mis Compañeros e integrantes de la comunidad de Ingeniería en Computación. CONCLUSIONES | FUTURO | PREGUNTAS | AGRADECIMIENTOS

Medina, Gastón Nicolás INGENIERIA EN COMPUTACION

Presentaciones similares

Presentación del tema: "Medina, Gastón Nicolás INGENIERIA EN COMPUTACION"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Medina, Gastón Nicolás INGENIERIA EN COMPUTACION

Presentaciones similares

Presentación del tema: "Medina, Gastón Nicolás INGENIERIA EN COMPUTACION"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback