Implementación de Open SSL en PalmOS

1
Implementación de Open SSL en PalmOS
Roberto Gómez, Member, IEEE1
[email protected]
Abstract-- El papel que están jugando los dispositivos PDAs en
las empresas completamente conectadas esta creciendo. De la
misma forma los requerimientos de las aplicaciones que corren en
estos dispositivos son cada vez más complejos y uno de los factores
más solicitados es el de seguridad. Uno de los principales
requerimientos de seguridad es el de confidencialidad, y uno de
los protocolos más usados es SSL. El presente trabajo presenta
una implementación de SSL en dichos dispositivos.
Index Terms-- Seguridad, PalmOS, SSL
I.
INTRODUCCIÓN
En el ámbito de la vida diaria los humanos, la comunicación
es la herramienta esencial para desarrollar todas las tareas que
realizamos cuando estas deben hacerse en paquetes, la
comunicación es la base para la subsistencia en nuestros
tiempos, ya que la mayoría de las acciones que hacemos todos
los días requieren de la interacción con nuestros semejantes.
Esta comunicación puede tener información relevante o
importante, que se necesita que sea conocida sólo por un grupo
de personas, y la única manera de comunicarse es cuando se
usa un canal no seguro. Para lograr la seguridad que deseamos
en la comunicación, debemos recurrir a la criptología y otras
mecanismos de seguridad.
En la actualidad contamos con medios de comunicación
mucho más sofisticados como lo son las redes de
computadoras, las cuales por medio de cables o antenas hacen
posible la comunicación a distancia. Con ellas podemos contar
con comunicación con otra entidad a distancias enormes, se
puede contactar a una persona o máquina aunque se encuentre
del otro lado del hemisferio en tan sólo segundos, con la ayuda
de la tecnología actual como lo es la Internet.
De la misma forma que la tecnología avanza, también se
incrementa el número de individuos sin escrúpulos que desean
aprovechar la tecnología con fines propios, usan los avances
para realizar actos dañinos e incluso criminales a otras
personas, por lo que se deben implantar esquemas de
seguridad a niveles en los que un atacante experto tenga
dificultad y le sea menos posible romper estos esquemas.
ROC&C’2004 – CP-17 PONENCIA RECOMENDADA
POR EL CAPÍTULO DE COMPUTACIÓN
DEL IEEE SECCIÓN MÉXICO Y
PRESENTADA EN LA REUNIÓN DE OTOÑO, ROC&C’2004,
ACAPULCO, GRO., DEL 23 AL 28 DE NOVIEMBRE DE 2004.
Este trabajo se llevo a cabo con el apoyo de la Cátedra de la Seguridad en
Redes.
Claro que realizar estos esquemas requiere de un gran
esfuerzo. Por eso, se deben implementar esquemas que no sólo
sean seguros, sino que sean posibles, es decir que la mayoría
de las personas puedan implementar y aprender, pero que no
puedan romper.
De los principales requerimientos que buscan los usuarios
en materia de seguridad es el confidencialidad y autenticidad.
Un usuario debe confiar en que el sitio del que esta
descargando información no es el sitio original y que la
información extraída de este sitio solo la conoce él.
El protocolo más usado en las transacciones vía web es
SSL. Este protocolo proporciona confidencialidad,
autenticidad e integridad de la información que circula por el.
Muchas servicios proporcionados a través de páginas Web
proporcionan la opción del uso de este protocolo y para otros
es obligatorio. Lo anterior nos lleva a la necesidad de que los
clientes de dichos servicios cuenten con la versión cliente de
este protocolo. El objetivo de este trabajo es proporcionar una
implementación del lado cliente de este protocolo.
El trabajo esta dividido de la siguiente forma: En la sección
dos se explica las características principales del protocolo
SSL. La sección tres abarca todo lo relacionado con desarrollo
de aplicaciones en PDAs. Los puntos importantes de la
implementación se toca en la sección cuatro y por último se
dan a conocer las conclusiones y trabajo a futuro.
II. EL PROTOCOLO SSL (SECURE SOCKET LAYER)
SSL es el protocolo de comunicación segura más conocido
y usado actualmente, SSL actúa en la capa de comunicación y
es como un túnel que protege todas la información enviada y
recibida. SSL es usado en gran cantidad de aplicaciones que
requieren proteger la comunicación, siendo más usado para
transacción a través del Web.
SSL
proporciona
confidencialidad,
integridad
y
autenticidad. La confidencialidad se da a través del uso de
algoritmos de encripción, garantizando que los datos enviados
y recibidos no podrán ser interpretados por ninguna otra
persona que no sea ni el emisor ni el receptor. La integridad
garantiza que los datos recibidos son exactamente iguales a los
datos enviados, pero no se impide que al receptor la
posibilidad de modificar estos datos una vez recibidos. Por
último la autentificación garantiza que el cliente esta
accediendo al sitio que en realidad desea, se usa un Certificado
Digital emitido por una empresa llamada Autoridad
Certificadora, este documento es totalmente infalsificable y
garantiza que el servidor es quien dice ser.
SSL v1 nunca se ha utilizado públicamente, pero Netscape
2
introdujo SSL v2 con la versión 1 de Netscape Navigator. SSL
v3 representa el estándar SSL más actual en uso (ver [1]). El
protocolo Transport Layer Security (TLS), desarrollado por el
IETF amplía el protocolo v3 de SSL con mejoras en lo que se
refiere a los aspectos de autenticación del algoritmo SSL ([2]).
El proctocolo Wireless Transport Layer Security, como su
nombre indica, constituye una versión de TLS utilizada en las
comunicaciones sin cable.
El comportamiento de SSL v3 sigue los pasos que se
describirá a continuación. Antes de que se establezca SSL, se
debe hacer una solicitud. Típicamente esto implica un cliente
haciéndo una solicitud de un URL a un servidor que soporte
SSL. SSL acepta solicitudes por un puerto diferente al
utilizado normalmente para ese servicio.
Una vez se ha hecho la solicitud, el cliente y el servidor
empiezan a negociar la conexión SSL, es decir, hacen el SSL
Handshake.
Durante el hanshake se cumplen varios
propósitos. Se hace autenticación del servidor y opcionalmente
del cliente, se determina que algoritmos de criptografía serán
utilizados y se genera una llave secreta para ser utilizada
durante el intercambio de mensajes subsiguientes durante la
comunicación SSL.
Los pasos que se siguen se pueden resumir en, client hello,
(saludo del cliente), server hello, aprobación del cliente y
verificación (ver figura 1).
cliente
servidor
client-hello
server-hello
aprobación
verificación
transmisión segura
Fig. 1. Protocolo SSL
El client hello tiene por objetivo informar al servidor que
algoritmos de criptografía puede utilizar y solicita una
verificación de la identidad del servidor. El cliente envía el
conjunto de algoritmos de criptografía y compresión que
soporta y un número aleatorio. El propósito del número
aleatorio es para que en caso de que el servidor no posea un
certificado para comprobar su identidad, aún se pueda
establecer una comunicación segura utilizando un conjunto
distinto de algoritmos. Dentro de los protocolos de criptografía
hay un protocolo de intercambio de llave que define como
cliente y servidor van a intercambiar la información, los
algoritmos de llave secreta que definen que métodos pueden
utilizar y un algoritmo de hash de una sola vía. Hasta ahora no
se ha intercambiado información secreta, solo una lista de
opciones.
Durante el server hello, el servidor responde enviando un
certificado digital el cual incluye su llave pública, el conjunto
de algoritmos criptográficos y de compresión y otro número
aleatorio. La decisión de que algorítmos serán utilizados está
basada en el más fuerte que tanto cliente como servidor
soporten. En algunas situaciones el servidor también puede
solicitar al cliente que se identifique solicitando un
identificador digital.
En la aprobación del cliente, el cliente verifica la validez
del certificado enviado por el servidor. Esto se lleva a cabo
desencriptando el certificado utilizando la llave pública del
emisor y determinando si este proviene de una entidad
certificadora de confianza. Después se hace una serie de
verificaciones sobre el certificado, tales como fecha, URL del
servidor, etc. Una vez se ha verificado la autenticidad de la
identidad del servidor. El cliente genera una llave aleatoria y la
encripta utilizando la llave pública del servidor y el algorítmo
criptográfico y de compresión seleccionado anteriormente.
Esta llave se le envía al servidor y en caso de que el handshake
tenga éxito será utilizada en el envío de futuros mensajes
durante la sesión.
En la verificación ambas partes conocen la llave secreta, el
cliente por que la generó y el servidor por que le fué enviada
utilizando su llave pública, siendo la única forma posible de
desencriptarla utilizando la llave privada del servidor. Se hace
una última verificación para comprobar si la información
transmitida hasta el momento no ha sido alterada. Ambas
partes se envían una copia de las anteriores transacciones
encriptada con la llave secreta. Si ambas partes confirman la
validez de las transacciones, el handshake se completa, de otra
forma se reinicia el proceso.
Ahora ambas partes están listas para intercambiar
información de manera segura utilizando la llave secreta
acordada y los algoritmos criptográficos y de compresión. El
handshake se realiza solo una vez y se utiliza una llave secreta
por sesión.
Una vez que se ha establecido un canal de transmisión
seguro SSL, es posible el intercambio de datos. Cuando el
servidor o el cliente desea enviar un mensaje al otro, se genera
un digest (utilizando un algoritmo de hash de una vía acordado
durante el handshake), encriptan el mensaje y el digest y se
envía, cada mensaje es verificado utilizando el digest.
Cuando el cliente deja una sesión SSL, generalmente la
aplicación presenta un mensaje advirtiendo que la
comunicación no es segura y confirma que el cliente
efectiva,mente desea abandonar la sesión SSL.
III.
PROGRAMACIÓN DE APLICACIONES EN SISTEMAS PALMOS
Es posible crear aplicaciones para dispositivo Palm usando
como plataforma de desarrollo los sistemas operativos
Windows, Mac OS, UNIX e, incluso, el propio Palm OS. Se
cuenta con la misma flexibilidad para podemos elegir el
lenguaje, desde C y C++ hasta BASIC en diferentes versiones,
pasando por Java y lenguajes menos habituales como Forth.
3
Para desarrollar cualquier aplicación en Palm OS se
necesitan varios recursos, como el Software Development Kit,
el ambiente de compilación, el generador de los recursos y
otras herramientas más, todas estas herramientas están
disponibles en Internet [3] y toda la documentación puede
encontrarse en [4]. El SDK está disponible para Windows,
Mac OS y Linux. Es decir, se puede usar cualquiera de estos
sistemas operativos como una plataforma anfitrión para el
desarrollo de aplicaciones que, posteriormente, se transferirían
y ejecutarían sobre Palm OS. Existen versiones específicas del
paquete de desarrollo para ciertas herramientas, como
CodeWarrior y PRC-Tools
Las aplicaciones desarrolladas en Palm OS estan basadas en
eventos, es decir en lo que pase en la Palm,. Los eventos son
de diferentes tipos como entrada al usuarios, notificación del
sistema, etc, por lo que se tiene que tener un control de estos y
contar con un “plan de acción” para cada uno de ellos. Se debe
tomar en cuenta todos los eventos que pueden ocurrir, por
ejemplo, puede ser que en medio de una comunicación el
usuario apriete el botón de apagado en la Palm, por lo que el
sistema se suspenderá más no se apagará, por eso es necesario
conocer como resguardar el estado de la Palm ( ver [6,7] ), o
incluso destruir toda la información.
El sistema de archivos se encuentra muy limitado, ya que se
debe limitar a usarse solo cuando el almacenaje de la
información sea mayor a 64 kbs, si no deben usarse las
implementaciones de base de datos o internas o directamente
los “chunks” en memoria.
Aunque el sistema soporta multi-hilos y procesos, el uso
interactua con un programa a la vez.
Las aplicaciones ejecutables para Palm OS se alojan en
archivos con extensión PRC. Estos archivos pueden ser
completamente autónomos o bien necesitar de alguna librería o
módulo de apoyo para su funcionamiento. Todo el proceso de
desarrollo y depuración suele efectuarse mediante un
emulador, instalando la aplicación en el dispositivo real al
final. Además de aplicaciones propiamente dichas, es posible
desarrollar conductos (conduits) para facilitar la conversión de
formatos y sincronización entre un Palm y otra plataforma,
como pueda ser Windows o Mac OS.
Se deben tomar en cuenta tres prioridades en la
programación de Palm: el espacio en el heap, la velocidad, y el
tamaño del código. Hay que considerar el tamaño de la
variables a utilizar; si es posible, manejar apuntadores y
cerrarlos, o manejar “chucks” de memoria en sus diferentes
tipos y después liberarlos.
Cada aplicación cuenta con una función PilotMan() que es
equivalente al main de los programas en C. Para lanzar una
aplicación, el sistema manda llamar PilotMain() y le envia un
código de lanzamiento. Este código especifica si la aplicación
se activará y desplegará una interfaz de usuario, o si
simplemente realizará una tarea sin desplegar nada.
En Palm OS no se pueden usar las mismas librerías que en
ANSI C, aunque en la mayoría de los casos se pueden realizar
las mismas funciones usando llamada al API de Plam OS; con
esto se supone una inversión grande de tiempo en aprender un
nuevo API o en buscar la función correcta.
IV. IMPLEMENTACIÓN SSL EN PALMOS
La implementación se desarrollo en lenguaje C y se uso el
API de Palm Os para llamar a las funciones correctamente.
Lo primero que se hizo fue la definición de todos los tipos,
así como la de todas las estructuras a usar. Estas se encuentras
especificadas en [1]. Por ejemplo para definir la estructura
ClientHello se procede de la siguiente forma:
Struct {
ProtocolVersion client_versión;
Random random;
...
} ClientHello
Como se puede apreciar, las estructuras son declaradas
exactamente igual que como se haría en C, sólo hay que cuidar
que los tipos correspondan a los deseados.
Para la conexión al servidor seguro se usaron las funciones
definidas dentro de las bibliotecas de sockets de Unix. A
manera de ejemplo en la figura 2, se encuentra el código del
envío del primer mensaje del protocolo.
Static Uint32 make connection(Char *service, Uint32 type,
Char *netaddress)
{
/* convertir servicio de string a numero */
UInt32 port = -1;
struct in_addr *addr;
UInt32 sock, connected;
struct sockaddr_in address;
if (type == SOCK_STREAM) port = atoport(service,
“tcp”);
if (type == SOCK_DGRAM) port = atoport(service,
“udp”);
if (port == -1) {
(*gErrorFunc)(“make_connection: Invalid socket type.
\n”,NULL);
return –1;
}
if (addr == NULL) {
(*gErrorFunc)(“make_connection: Invalid network
address. \n”,NULL);
return –1;
}
MemSet((Char *)&address, 0, sizeof(address));
address.sin_family= AF_INET;
address.sin_port= (port);
address.sin_addr.s_addr = addr->s_addr;
sock = socket(AF_INET, type, 0);
if (type = SCOK_STREAM) {
4
connected = connect(sock, (struct sockaddr *) & address,
sizeof(address));
if (connected < 0 ) ) {
(*gErrorFunc)(“connect \n”,NULL);
return –1;
}
return sock;
}
if ( bind( sock, (struct sockaddr *) & address, sizeof(address))
<0){
(*gErrorFunc)(“bind \n”,NULL);
return –1;
}
return sock;
UInt32 fd;
struct ClientHello hello protocol; // hacemos referencia a la
estructura
helloProtocol.client_versión = {0x01, 0x02, 0x03, ... } ; //
suponemos que alguna función lo llena
fd=make
if (write(fd, helloProtocol, sizeof(struct ClientHello)) > 0)
exito = true;
else
exito = false;
Fig. 2. Código envío primer mensaje
Como podemos ver, la implementación de la comunicación
en redes es muy parecida a la que se usa en Unix, por lo que
no represento una gran dificultad el armar el resto del
protocolo. Se uso el API de PalmOS para llamar a las
funciones correctamente, con lo que optimiza la aplicación. A
notar que, a excepción de la llamada a las librerías de Red, las
demás funciones si realizan la llamada correspondiente, por
ejemplo, memset que fija rangos de memoria en el heap
dinámico se llama en su manera correcta MemSet (como se
puede ver, la sintaxis es sensible a mayúsculas/minúsculas).
En lo que respecta a los algoritmos de cifrado se prefirió
usar las funciones de implementación definidad en GNU [8].
En [9] se presenta un análisis del desempeño de las funciones
de cifrado proporcionadas por Palm OS. Se tuvó que adaptar
el código para poder ser implementado en la Palm. La
biblioteca de encripción es una adaptación de BlowFish, hecha
por Eric. A. Young.
Se tuvo que tomar en cuenta que cuando se pasa un
apuntador a una función y luego se desea hacer copias de él en
otra función, se recurre a la memoria baja (en donde esta l
vector de interrupciones, vital para la Palm), el código con el
que se provoca el error es el siguiente:
char * texto;
Texto = FldGetTextPtr(campotexto);
Funcion Errónea(texto);
static void funcionErronea (Char *texto) {
Char *error;
StrCopy(error, texto);
}
La solución es no acceder a esta memoria, en lugar de
manipular estos apuntadores directamente creamos nuevos
“chunks” de memoria y ahí los manipulamos. El código
corregido es el siguiente:
La solución es no acceder a esta memoria, en lugar de
manipular estos apuntadores directamente creamos nuevos
“chunks” de memoria y ahí los manipulamos. El código
corregido es el siguiente:
char * texto;
Texto = FldGetTextPtr(campotexto);
Funcion Errónea(texto);
static void funcionerronea (Char *texto) {
MemHandle sinError = new MemHandle(32);
StrCopy(MemHandleLock(sinError), texto);
MemHandleUnlock(sinError);
MemHandleFree(sinError); // liberar el chunk usado
}
V. CONCLUSIONES
Se presentó una implementación del protocolo SSL para
ambientes Palm OS. A pesar de que ya existen algunas
aplicaciones que ofrecen este servicio, este es un primer paso
para la implementación de otros tipos de protocolos que
permitan la comunicación entre una Palm y un servidor.
El dearrollo de una aplicación basada en socketes es muy
similar a la usada en cualquier máquina de ambiente Unix. Lo
anterior facilitó la implementación. Sin embargo la no
compatibilidad al 100% de los tipos de variables complicó el
uso de funciones criptográficas disponibles.
El siguiente reto es poder implementar un emulador de SSH
para poder ejecutar ciertos comandos básicos desde una Palm
en un servidor tipo Unix.
REFERENCIAS
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
SSL protocol versión 3.0, Internet dratf 302, 1996
The TLS Protocol Versiob 1.0 RFC 2246, 1999
http://www.palmos.com/dev/tech/
http://www.palmoscom/dev/tech/docs
Desarrollos para Palm. Francisco Charte, Informática móvil (VI),
Pcworld, No. 175. pp. 236
Palmist: a tool to log Palm system activity, Gannamaraju, R.; Chandra,
S.; Workload Characterization,
2001. WWC-4. 2001 IEEE
International Workshop on , 2 Dec. 2001 pp.111 – 119
A checkpointing tool for Palm operating system Chi-Yi Lin; Sy-Yen
Kuo; Yennun Huang; Dependable Systems and Networks, 2001.
Proeedings. The International Conference on , 1-4 July 2001 pp:71 – 76
http://www.gnu.org
The performance measurement of cryptographic primitives on palm
devices Wong, D.S.; Fuentes, H.H.; Chan, A.H.; Computer Security
5
Applications Conference, 2001. ACSAC 2001. Proceedings 17th
Annual , 10-14 Dec. 2001 pp 92 - 101
Gomez Roberto (M’96) En 1987 recibe el título de Ingeniero en Sistemas
Electrónicos por el ITESM-CEM, Maestría en Ciencias Computacionales por
el ITESM-CEM en 1990. La Universidad Paris 8 le otorga el doctorado por su
trabajo desarrollado en el laboratorio INRIS. Es profesor investigador del
departamento de ciencias computacionales del ITESM-CEM desde 1995. Sus
áreas de interés son la seguridad informática, los sistemas distribuidos y la
criptología.