El 15 de abril fui invitado a una presentación técnica en el Instituto de Prácticas Bancarias y Financieras en Quito, con el objeto de mostrar el estado del arte en técnicas de virtualización y aprovechamiento de hardware utilizando software libre, de código y estándares abiertos y sus capacidades de interoperatibilidad.

Entre los participantes había unos 50 representantes de empresas, consultoras y estudiantes universitarios, que asistieron a la actividad para ver la comparativa de interoperatibilidad que preparé junto a Pablo Toapanta, quien es un reconocido profesional en tecnologías Microsoft en Ecuador.

Preparé unas láminas guía muy básicas con el propósito de presentarle a los participantes la idea de que no todo es virtualización, sino que antes de considerar la virtualización (y algunos temas más complejos como cloud o utility computing) hay muchos pasos a tomar en cuenta como la emulación y la clusterización.

Si bien hice un gran énfasis en la capacidad de paravirtualizadores como Xen, resaltando algunos casos de uso importantes como el trabajo de Joanna Rutkowska con Qubes, los escenarios de interoperatibilidad que preparé fueron esencialmente con Sun VirtualBox, y no me queda ninguna duda de que el producto es muy completo, fácil de usar y flexible para entornos altamente complejos, con el impacto en performance asociado a esta técnica de virtualización.

Utilizando solamente un cable Ethernet entre dos laptops, una con Microsoft Windows Server 2008 utilizando HyperV y otra con Debian GNU/Linux utilizando VirtualBox, y en menos de una hora preparamos y mostramos estos escenarios:

• Linux como un miembro de dominio utilizando Kerberos y Samba, iniciando sesión en un Active Directory de Microsoft Windows Server 2008
• Linux como un servidor de recursos compartidos, específicamente impresoras, utilizando IPP y drivers Postscript, con lo que logramos imprimir desde Microsoft Windows Server a la impresora virtual PDF de CUPS
• Linux como un proveedor de aplicaciones Web y de administración accesible vía RDPv5, totalmente ‘consumible’ desde Windows de forma nativa
• Linux como un host de Microsoft Windows 7 y Microsoft Windows Server 2003, utilizando RDPv5 para acceso único, o bien Terminal Services con SeamlessRDP para integración total con el escritorio Linux

También presentamos escenarios ‘no-interoperables’ como por ejemplo Android corriendo como una máquina virtual en Linux, o clústeres de Microsoft SQL Server usando HyperV. Pero, sinceramente, creo que la gente fue a ver que podíamos hacer en cuanto a interoperatibilidad, y a eso dedicamos la mayor parte del tiempo.

La importancia de estos escenarios radica en que no sólo son el resultado de una hora de preparación sino que en los últimos dos años me he enfrentado profesionalmente en varios proyectos en Venezuela y Ecuador a estos casos. Por ejemplo, ayudé a la Compañía Anónima Nacional de Teléfonos de Venezuela, CANTV, a implementar Canaima GNU/Linux 2.0 en sus estaciones de trabajo corporativas (unas 15 mil) utilizando SeamlessRDP para aplicaciones legadas que no pueden ejecutar en Linux, o al Complejo de Refineración de Paraguaná, una de las refinerías más grandes del mundo, a implementar máquinas virtuales para migrar parcialmente servicios de su infraestructura local, como impresoras auditadas o metadirectorios.

Otra ventaja de este enfoque comparado con los procedimientos tradicionales, tipo receta, en los que instalamos “Linux como un controlador de dominio”, “Windows como host de Linux”, etc., es que la virtualización y el incremento en la adopción de estándares abiertos de la industria da por sentadas muchas cosas fácilmente como por ejemplo integración del DNS, DHCP, NTP, aplicaciones vía HTTP/S, etc.

Pasé un excelente rato dando la presentación, el público estuvo muy interesado, tuve la oportunidad de poner en práctica de forma muy ágil muchas técnicas interesantes y la interacción con Pablo fue excelente, ¡buen trabajo!

Con estas claves se podía usar Windows Azure durante el preview de tecnología, lo cual ya venció IIRC. Windows Azure será accesible para ciertos países bajo una estructura de costos particular. Realmente para las organizaciones asumo que la ventaja competitiva de usar Azure (vs. Amazon, e.g.) radicará en la integración que ya tiene con el IDE Microsoft Visual Studio y las tecnologías asociadas al desarrollo en plataforma Microsoft. Digamos que se promete poder migrar una aplicación .NET existente a la nube.

Yo me propuse usar Windows Azure con una aplicación libre, hecha en PHP, para probar. El SDK de Windows Azure para PHP realmente son sólo unas librerías que se incluyen en un proyecto PHP. Una vez incluídas, estas librerías hacen disponibles funciones para crear, listar, acceder, agregar, modificar y/o eliminar elementos de datos en la nube como: blobs, tablas y colas. Todo esto se hace con funciones REST. El SDK necesita CURL y la librería php-curl.

Es importante resaltar que en el caso de las tablas, si bien se conoce que Windows Azure utiliza SQL Server como almacén de datos en la nube esto es transparente para el desarrollador. Simplemente se crean entities en PHP con campos arbitrarios y esos se mandan completos a la tabla; en el backoffice ya se encargará el RDBMS de crear columnas, tipos de datos y demás. Tampoco hay que saber SQL ni T-SQL para hacer consultas, sino que hay una sintaxis simplificada y además las librerías ayudan. Piense en algo como CouchDB con SQL Server como un backend.

No es de sorprender que el almacenamiento de tablas de Windows Azure presenta características en línea con tendencias alejadas de SQL como prevalencia del modelo key-value para manejadores de bases de datos en aplicaciones de alto rendimiento, con ejemplos como Facebook, eBay y Elgg y cierta orientación a un modelo de DB basado en “documentos” que realmente se tratan de estructuras de datos arbitrarias enviadas al manejador para su almacenamiento. Esto en definitiva es positivo para el desarrollador y es curioso ya que hace muy pocos años esto no estaba en el panorama.

El SDK para PHP es licenciado bajo BSD lo que lo hace software libre y de código abierto. Las librerías no las hizo Microsoft sino un tercerizador (RealDolmen) y personalmente considero que se pudo haber usado librerías de REST un poco más elaboradas. Para cuando probé Windows Azure habían proyectos para Java y Ruby, en esencia patrocinados por Microsoft. En MLs japonesas ya habían módulos (al menos para Tablas) para lenguajes como Perl.

Un ejemplo muy sencillo para empezar con tablas sería (y aquí más ejemplos):

require_once 'Microsoft/WindowsAzure/Storage/Table.php';

$svc = 'table.core.windows.net';
$act = 'act'; # el prefijo de *.table.core.windows.net que crean en la página, identifica al 'usuario'
$key = 'key'; # una clave binaria en base64 que generan en la página, completa la credencial

$storageClient = new Microsoft_WindowsAzure_Storage_Table($svc, $act, $key);
$result = $storageClient->createTable('PrimaTabla');

$result = $storageClient->listTables();
foreach ($result as $table)
{ echo 'Tabla: ' . $table->Name . "\n"; }

Los drawbacks que veo radican en la ubicación geográfica de las infraestructuras físicas que se están utilizando, y obviamente el impacto estratégico que tiene en algunas aplicaciones, así como las amenazas tradicionales para aplicaciones sensibles de servicios de cloud computing. Sin embargo, es bueno saber que es posible desarrollar en PHP (y otros lenguajes de stack abierto, FWIW) usando Azure como backend y sin estar atado a un IDE o a un software de gestión de ciclo de vida específico.

Yo ya había utilizado OpenLDAP extensivamente en entornos empresariales, incluso en convivencia con Microsoft Active Directory cuando trabajé en el Centro de Cómputo de EDELCA, la principal empresa eléctrica en Venezuela. Ese setup ahora está utilizando 389 (antes Fedora Directory Server) para sincronizar claves con MSAD para más de 17 mil personas y centenares de miles de objetos, y a pesar de que lo había visto funcionar bajo cargas muy inusuales, y usábamos clusters con distribución geográfica, yo también tenía la duda de los números.

Decidí probar esto en varios frentes. El primero, generar LDIFs muy grandes, y averiguar cuánto representarían en disco una vez almacenados en Berkeley DB, suponiendo que se fuera a utilizar ese popular backend para OpenLDAP. Esto nos daría una idea, exceptuando índices y optimizaciones, de los requerimientos en memoria de un producto como OpenLDAP en escenarios muy grandes. El segundo frente estaba limitado a las pruebas de tiempo de respuesta de la aplicación ante escenarios de búsqueda.

La razón por la que pruebo búsquedas es porque esta es la aplicación más común de un directorio LDAP. Mis pruebas fueron locales usando TCP/IP porque, aparte de contaminar los tiempos, en mi experiencia los tiempos de respuesta de un directorio LDAP, cuando está networked, se diluyen en los tiempos de procesamiento de la aplicación; en EDELCA preparé un informe que estudiaba la razón de un problema con GNOME Evolution en el cual el autocompletado tardaba varios segundos en responder, aunque en trazas de red se evidenciaba que el directorio LDAP había respondido en milisegundos (un bug en la aplicación) Imagine otro escenario: en la firma y la comprobación de firma de una infraestructura de llave pública dependiente de LDAP, ¿será el tiempo de respuesta de LDAP determinante cuando estamos potencialmente sobrecargando al cliente calculando hashes para la firma de un documento?

Por esto, el tiempo de respuesta local vs. networked no sería un indicativo de la experiencia del usuario final con el directorio, en parte el motivo de la preocupación del cliente. Además hay proxys en LDAP (montamos uno en PDVSA CRP, junto con Penrose como integrador de directorios, o como lo llaman en el mercado, un virtual directory) y estrategias de infraestructura para atacar esto de manera estructural.

Como no quería pasar seis meses de mi vida diseñando experimentos y ya que supuse que nadie iba a estar demasiado interesado en los resultados, dejé de lado algunos escenarios de borde y preparé un par de scripts, en Perl como es natural, para escribir LDIFs muy rápido y para consultar LDAPs muy rápido. Utilicé threads en Perl para su implementación (quería consultar en paralelo), aunque estoy prácticamente convencido por Luis Muñoz, Alejandro Imass y Ernesto Hernández-Novich de no repetir el uso de threads jamás.

De allí nació un pedestrian LDAP tester, que luego extendí a un stresster de MTAs a través de SMTP y a uno de procesos de autenticación en aplicaciones Web utilizando WWW::Mechanize. Esto es porque el proyecto con PDVSA involucraba las tres cosas: implementamos un cluster de Zimbra Collaboration Suite Community y 389 (FDS) utilizando Debian GNU/Linux en ocho servidores con Xen y NFSv3 para un poco más de 25 mil cuentas, a la fecha 18 meses en producción. Voy a subir los otros scripts pronto, pero vamos con los findings de LDAP, de mi nota informal de Julio 2008:

Cargar 200 mil registros (un LDIF de 66 MB.) en la base de datos tiene una representación en BDB de unos 928 MB. Asumamos que requeriríamos, worst case scenario ese espacio en memoria, sin índices ni los registros de replicación. Cargar esos 200 mil registros en OpenLDAP (slapadd) se toma entre 135 y 180 minutos aproximadamente. Afortunadamente la carga se hace sólo una vez. Indizar la base de datos (slapindex) es relativamente rápido y el tiempo se mantiene igual con 1 mil o 200 mil registros. Esto es lógico y bueno.

Hice una búsqueda similar a una consulta de una libreta de direcciones popular. Esa búsqueda generó 15 mil resultados (el número de resultados se puede restringir en OpenLDAP, pero a efectos de la prueba lo desactivé) — en mis pruebas, 100 clientes consultando paralelamente por TCP/IP y obteniendo los 15 mil resultados, sin limitar los atributos más allá de las ACLs se tomó:

real    0m12.048s
user    0m10.413s
sys     0m0.768s

Lo cual es más que aceptable. Ahora bien, el uso en memoria RAM del servicio está en los 640 MB. de memoria virtual y casi 200 MB. en memoria residente. Esto representa el 15% de la memoria del servidor que utilicé, un HP Integrity descontinuado para 2008, que tiene 2 GB. de RAM. Al introducir índices, estos se cargan en memoria, así como el número de objetos que se quiere tener en caché (yo coloqué 50 mil) por lo que habría que pensar en al menos unos 4 GB. de RAM para un volumen así.

Creando índices para los atributos cn, sn, givenName y mail, y ajustando un poco los parámetros de configuración de BerkeleyDB (tabulado del FAQ-O-Matic) la indización se toma un tiempo bastante mayor, para un tiempo de respuesta con la misma búsqueda no mucho menor:

real    0m10.540s
user    0m8.593s
sys     0m0.480s

Por lo que, en general, optimizar poco los índices tendría mucho impacto en las cargas y poco impacto en las búsquedas: si vas a indizar, indiza todo lo que quieras y puedas. Lo otro crítico de optimizar es el DBCONFIG; para 2008, y gracias en parte al oscurantismo de Oracle, era más arte que ciencia. El FAQ-O-Matic de OpenLDAP, como siempre, da la mejor información, ver los artículos 1072, 1075, 42, 738 y 893.

Now for the goodies, hay tres scripts que publiqué en mi carpeta de CPAN. El primero genera LDIFs, de forma muy básica, entradas tipo libreta de direcciones (plt-ldif-generator); el segundo hace las consultas con threads (plt-bambam) y el tercero es una muestra del patrón de uso del tester (plt-usage-pattern), en shell script.

Necesita un Perl razonablemente moderno, compilado con soporte para threads, la librería de Threads de Perl y el módulo Net::LDAP. Un aptitude install libthreads-perl libnet-ldap-perl es suficiente. El primer script también espera que usted provea un root.ldif (el nombre se puede cambiar en el código) con la entrada base del directorio (dc=foo,dc=bar; por ejemplo) y un model.ldif que tenga la entrada modelo con tags que el script sustituirá (obvio, puede usar un LDIF prehecho), algo como:

dn: cn=#CN#,dc=foo,dc=bar
objectClass: top
objectClass: inetorgperson
uid: #USER#
cn: #CN#
sn: #SN#
givenName: #FN#

Importante: como ya dije antes, algunos casos de uso están fuera de la prueba que realicé, en la mayoría de los casos porque no impactan la prueba sensiblemente (por ejemplo, autenticar las conexiones usando credenciales, cifrado con TLS/SSL y otros, no sería un problema grave) aunque sí podría nombrar algunos elementos que influyen en el performance cuando se lleva OpenLDAP a la práctica en escenarios distintos al trivial, como por ejemplo el uso de muchos schemas y de atributos divergentes en las entradas del directorio, sobrecargar el servicio con temas administrativos como largas ACLs dinámicas y sobre todo altos niveles de verbosidad y overlays de terceros. Afortunadamente, ninguno de estos es un must para un setup grande de LDAP. El código de mis scripts también debe tener bugs y está terriblemente documentado, pero le cumple el propósito perfectamente.

Desde hace un año he estado trabajando con OpenTSA, un conjunto de parches a OpenSSL para incorporar soporte al estampillado de tiempo en la popular suite de criptografía de llave pública.

Muy a grandes rasgos, el estampillado de tiempo llena una necesidad corporativa e individual de certificar que una data existía a partir de cierto momento en el tiempo. Adicionalmente, al estar involucrado en una infraestructura de llave pública, nos trae las ventajas de la autenticidad y la integridad. Lamentablemente, hoy en día organizaciones en todo el Mundo hacen inversiones de varios cientos de miles de dólares en tecnología para estampillado de tiempo.

Hace un año OpenTSA tenía muchos problemas, ya que se necesitaba bastante OpenSSL-fu para parchar la popular y sobre todo ubicua suite de criptografía. En distribuciones mainstream como Debian tenemos gran cantidad de software que se enlaza con OpenSSL y con muchas otras cosas (p.ej., Apache con MySQL y Postgres… out of the box) y eso dificulta mucho la accesibilidad de las tecnologías que van saliendo.

En Noviembre 2009, OpenSSL publicó la beta4 de OpenSSL 1.0.0, que absorbe el valioso trabajo de Zoltan Glozik y sus colaboradores. Junto a mod_tsa del proyecto OpenTSA original, hoy en día es más que feasible poner a operar un servicio de estampillado de tiempo bajo HTTP(S) POST que le permita a un/a usuario/a relativamente lego en cuanto a criptografía poder hacer estampillados de su data.

A la fecha, no existe en Debian un paquete disponible de OpenSSL 1.0.0. Un paquete de este tipo no puede entrar en una distribución no autocontenida como experimental ya que hay demasiados paquetes compilados contra la versión 0.9.8. Así que en principio hay dos formas de hacer esto: con chroots o máquinas virtuales o esperar que el paquete entre en unstable. Yo utilizo equivs para crear los paquetes de openssl, libssl0.9.8 y libssl0.9.8-dev y no romper el sistema de paquetes. Espere que paquetes como wget o curl que hacen uso extensivo desde su arranque de SSL no funcionen o tenga que recompilarlos.

No es necesario aplicar parches en OpenSSL. Ya OpenSSL 1.0.0-beta4 tiene soporte para timestamping. Lo único que se necesita compilar es mod_tsa para Apache, y como Apache y sus dependencias también dependen extensivamente de SSL, lo mejor es compilar directo httpd 2.2 desde los repositorios fuente. Finalmente se compila mod_tsa, que necesita una DB para guardar las estampillas: MySQL, PostgreSQL o Firebird. Sólo se necesita una tabla sin funciones complejas: MySQL es lo más NoSQL que es accesible colocar.

¿Cómo se usa? Cuando se tiene un archivo o una data, se aplica openssl ts para obtener el timestamping request y luego se manda a firmar el request en la autoridad de estampillado de tiempo. El emisor distribuye la estampilla junto con la data, y el/la interesado/a puede verificar la integridad y existencia de la data teniendo la data, la estampilla y el certificado de la autoridad de estampillado.

Una reflexión final: sigo abogando por el uso de GnuPG para garantizar autenticidad, integridad y cifrado en todas las comunicaciones vía electrónica. Sin embargo, GnuPG carece de mecanismos pulidos para estampillado de tiempo y aunque la mayor parte de nuestras comunicaciones las hacemos vía correo electrónico, ni siquiera allí podemos contar con las estampas de los servidores de correo intermedio. Por esto considero que enfocar el uso de OpenSSL sólo para TSA puede ser una muy buena idea, complementada con GnuPG.

Hace un poco más de un mes tuve la oportunidad de hacerme con una versión especial de la Acer Aspire 1420P. Este es un convertible Tablet PC con un CPU Intel Core 2 Duo U2300, chipset Intel Mobile GS45 Express, 2 GB. de memoria RAM en dos slots soDIMM, una pantalla HD de 11.6″ que da 1366×768 px., WWAN UMTS/HSDPA y GSM/GPRS/EDGE multibanda integrada, una Intel WiFi Link 1000 BGN, Bluetooth, HDMI, multitouch y un disco de 250 GB en 1.72 kg. de peso. Outstanding.

La laptop traía Microsoft Windows 7 Ultimate para arquitecturas de 64-bit y fue exitosamente reemplazado por Debian GNU/Linux. El procedimiento no fue tan escabroso como pensé; básicamente tuve que instalar vía USB Debian 5.0 (Lenny) y renunciar temporalmente a la mayor parte del hardware (principalmente Ethernet y WiFi) hasta que subí a un RC del kernel de Linux 2.6.32, con lo que pude usar la red y gracias a un proxy-caché APT en mi laptop principal (Thinkpad T400) subir la máquina completa a Debian Unstable (Sid) que es la distribución que uso. Todo el proceso tomó unos 15 minutos.

Si bien en el aspecto profesional he sido arquitecto de varias de las implementaciones más importantes 100% FLOSS del país (Canaima, CANTV, EDELCA y muchas otras organizaciones medianas a grandes; hoy en día calculo que habrán allá afuera unas 7 mil personas con relación directa y varios cientos de miles más indirectas) también he trabajado y trabajo en proyectos híbridos; es decir, donde coexisten tecnologías privativas con tecnologías libres y abiertas.

Los ambientes híbridos son parte de nuestra realidad, y también son un primer paso muy importante hacia una adopción exclusiva de software libre, que pienso que continúa siendo una idea que hace mucho sentido en cualquier unidad de tecnología pública o privada hoy en día (en el sector público pienso, además, que es un deber) y en cualquier parte del globo.

Por ejemplo, hoy en día es posible plantearse seriamente escenarios de interoperatibilidad en los que el backoffice sea FLOSS y el usuario final continúe utilizando una plataforma privativa, y también es muy posible y hoy en día hay escenarios en Venezuela donde se implementa una plataforma de usuario final FLOSS y el backoffice se mantiene. También hay muchos tonos de grises entre ambos escenarios; pueden haber backoffices mixtos, end users mixtos, sólo aplicaciones de negocio, etc.

El problema radica en que tradicionalmente los desarrolladores de software privativo han utilizado estrategias para eliminar o disminuir amenazas a su dominio tecnológico en una organización. Esto impide que los responsables de toma de decisiones planteen estrategias básicas que se orienten a diversificar su plataforma usando FLOSS, con las ventajas documentadas que esto tiene.

Estas amenazas van desde el FUD (¡eso no va a funcionar! o ¡eso va a hacer lenta la red!) hasta problemas administrativos importantes como por ejemplo la suspensión de soporte o garantía o incluso (ha pasado) el aumento de costos por no exclusividad de la plataforma. Todas estas son situaciones intolerables, tergiversaciones del mercado y que rayan casi en lo inhumano de la tecnología.

Mientras estas grandes empresas deciden flexibilizar sus políticas en torno a ambientes híbridos -poco a poco y gracias no solo a su burocracia sino a su condición federada- yo aporto mi grano de arena no solo como unidad productiva sino como desarrollador independiente, que un día hace 7 años decidió dedicarse al conocimiento libre.

Es por ello que desde hace varias semanas dedico con mi equipo de trabajo una parte de nuestro tiempo a probar -en laboratorio oficial- escenarios de interoperatibilidad en conjunto con una conocida empresa de software. Es una experiencia muy interesante, esencialmente pragmática y que se diferencia mucho de lo que en algún momento hacen o hicieron Robbins, Hilf y Hanrahan.

La experiencia que he tenido en implementaciones híbridas me hace estar seguro del éxito de estos escenarios de interoperatibilidad, y con toda seguridad publicaré algunos de estos resultados. En la medida en que se avalen los resultados se podrá incrementar la adopción de FLOSS en las instituciones de cualquier tipo. Son pequeños pasos que cuentan.

Estoy seguro de que -con los valores y expectativas bien fijadas- este tipo de actividades benefician al desarrollo del FLOSS.

Es un gusto saber, por ejemplo, que bajo actividades de este tipo la gente del Proyecto Samba puede tener un controlador de dominio de confianza en redes híbridas o que gracias a un reporte de error se fuerza a una corporación trasnacional a cambiar algo para admitir la interoperatibilidad.

Viendo en retrospectiva aquella actividad del 2003 me alegro de formar parte de un movimiento tan grande de gente interesada en desarrollar su conocimiento y compartirlo con los demás. Estoy seguro de que es la vía.

En este sistema operativo los desarrolladores usaron el stack de telefonía de Qtopia (¡uno que sí funciona, aunque ahora está descontinuado!) por lo que ya no se usa gsmd. Eso complica un poco la consulta de la banda en la que opera el teléfono.

El dispositivo /dev/ttySAC0 es el módem GSM, que está en uso por parte de qpe, el demonio de telefonía de Qtopia. Por lo tanto, hay que matar qtopia y evitar reiniciarlo por illume, la GUI de ASU (Enlightenment)

Con esto se libera el dispositivo /dev/ttySAC0. Por otro lado, hay que desactivar el control de flujo por hardware para interactuar por la consola con el dispositivo:

  stty -F /dev/ttySAC0 -crtscts

Yo utilicé cu para conectarme con el módem, pero pudimos hacerlo con socat o con minicom. Revisando la tabla de comandos AT que puedo pasarle al dispositivo para consultar el status, mandé:

  AT%EM=2,1

que corresponde a “Serving Cell Information”, el resultado fue:

%EM: 119,26,26,32,32,512,18,1,1,0,0,0,0,0,0,3005,0,0,2,255

siendo el primer campo devuelto (valor: 119) el canal de operación del teléfono con la red GSM con la que está asociada mi chip (Digitel, 734-02 en Venezuela)

Segun las tablas de la especificación GSM, a partir de este valor se puede calcular la frecuencia en la que opera el dispositivo, y más aun la banda de la misma. La tabla indica:

if 172 < arfcn <  252 then freq = 869 + (arfcn -127) x 0.2 MHz    # 850 band
if 511 < arfcn <  811 then freq = 1930 + (arfcn - 511) x 0.2 MHz  # 1900 band
if   1 < arfcn <  124 then freq = 935 + (arfcn * 0.2) MHz         # 900 band (original alloc)
if 974 < arfcn < 1023 then freq = 925 + (arfcn - 974) x 0.2 MHz   # 900 band E-GSM
if 511 < arfcn <  886 then freq = 1805 + (arfcn - 511) x 0.2 MHz  # 1800 band

Por lo tanto, estando el valor en 119 indica que estoy en la banda de 900 MHz., en particular en la frecuencia 958.8 MHz. Quise confirmar, sin embargo y envié el comando:

  AT%EM=2,3

este comando me arroja la misma información anterior pero con un máximo de seis celdas adyacentes. En mi caso sólo detecta cinco, y los valores para los canales que me arroja son:

  124,114,121,116,117,0

todos estos valores están dentro del conjunto de los números naturales entre 1 y 124 inclusive, por lo tanto las celdas adyacentes también están operando en 900 MHz.

Por si acaso identifiqué la red, para descartar estuviera haciendo roaming en otra red con un chip de Digitel. AT%EM=2,4 arroja:

  %EM: 3,40,734,002,95147409

Donde se aprecia el MCC 734 y el MNC 02, correspondientes a la red original de Digitel en la región Central y Capital.

Sin embargo estuve consultando datasheets de otros proveedores ya que me parecía muy 'oscuro' el mecanismo para obtener los valores, así que viendo la lista de comandos disponibles con AT+CLAC encontré:

  AT@BAND

que simplemente arroja:

  GSM 900

Resuelta esta duda, y como curiosidad, los valores que arroja el comando AT también me indican que estoy a menos de 550 metros de la base, lo cual es bastante correcto.

  System's busy, try again later or contact postmaster@fqdn

En principio, no se trata de un mecanismo asequible para el usuario final a través de las interfaces gráficas que están disponibles en el mercado para Linux, sobre todo si se quiere aprovechar en términos de seguridad el tener un segundo factor de autenticación. Esto es una lástima. El lector de tarjetas, sin embargo, sí puede usarse para otras cosas interesantes.

Supongamos que tiene una llave GPG. En este momento no importa mucho si la llave ha sido utilizada para algo útil, aunque esto tendrá algunas repercusiones en la usabilidad del factor adicional a futuro.

Su llave GPG tiene una subclave principal de cifrado, probablemente creada utilizando ElGamal y probablemente con una longitud de 2048 bits.

El objetivo de utilizar una tarjeta inteligente es eliminar la llave secreta y la subclave principal de cifrado de su llave GPG y sustituirla por tres llaves en la tarjeta inteligente que son utilizadas para cifrar, firmar y autenticar. Estas llaves se crean usando RSA y tienen una longitud de 1024 bits. Para acceder a las llaves necesita introducir un código de identificación denominado PIN. Al eliminar estos dos elementos de la llave, se fuerza a cualquier atacante a tener la tarjeta inteligente y el PIN para ejecutar cualquier acción que comprometa la llave.

Obviamente, el estado de su llave GPG antes de hacer este cambio puede (y debe) ser guardado en un dispositivo de almacenamiento externo que se resguarde físicamente de forma segura. Así podrá tener acceso a la llave secreta principal y a la subclave principal de cifrado en caso de algún problema. Esto lo puede hacer a nivel del sistema de archivos respaldando su directorio .gnupg o bien a nivel de la aplicación utilizando --export-keys y --export-secret-keys.

Otro aspecto importante a tener en cuenta es el mecanismo que utilizará para acceder a la tarjeta inteligente. Puede usar PC/SC a través del demonio pcscd, o puede usar CCID directamente de acuerdo a la implementación de GnuPG. Para usar la tarjeta con el segundo mecanismo necesita privilegios de administrador o configurar udev para otorgar permisologías a un usuario o grupo en particular.

En cualquier momento puede usar gpg --card-status para verificar no solo que el lector y la tarjeta funcionan, sino que la lógica de la tarjeta arroja datos con sentido. También puede usar gpg --card-edit para agregar información adicional de contexto, además de configurar el PIN de la tarjeta. Hay dos PIN, uno de uso cotidiano y uno administrativo. Asegúrese de estar consciente de cual PIN se le solicita para evitar bloquear la tarjeta.

Una vez que tenga todo listo, utilice gpg --edit-key LLAVE para editar su llave GPG, y el comando addcardkey para añadir las tres subclaves en la tarjeta inteligente. El orden en que debe seleccionar las claves es: autenticación, firma y cifrado, ya que GnuPG seleccionará automáticamente la última subclave creada para cifrar.

Guarde los cambios y seleccione la subclave principal de cifrado utilizando key 1. En este punto debe haber hecho los respaldos y creado las tres subclaves en la tarjeta inteligente. Ahora está listo para eliminar la subclave principal de cifrado de su llave GPG utilizando delkey y guardar los cambios en la misma. Con esto remueve una parte del material sensible de su llave GPG.

El siguiente es un procedimiento un poco extraño. Ya ha borrado la subclave principal de cifrado. Ahora quiere borrar la llave secreta de su llave GPG. Y en ambos casos quiere borrar solo la porción secreta, no la pública. La opción --delete-secret-keys de GnuPG eliminará las claves y subclaves secretas, por lo que primero debe respaldar las subclaves:

gpg --export-secret-subkeys LLAVE > sub.secring

luego debe eliminar las claves y subclaves secretas:

gpg --delete-secret-keys LLAVE

y luego debe importar las subclaves secretas:

gpg --import < sub.secring

Anteriormente dijimos que el objetivo era borrar de la llave el material secreto, y no las porciones públicas, por lo que debe importar las porciones públicas de las subclaves, siendo la forma más sencilla importar todo el keyring público del respaldo que haya realizado

gpg --import < pubring.backup

El momento de la verdad es cuando sube a un servidor de llaves públicas su llave pública incluyendo las nuevas subclaves. De hecho, el gran problema en la usabilidad de este mecanismo es que las subclaves anteriores no desaparecen de la memoria colectiva y usted depende de que todas las personas que tengan su llave pública descarguen la nueva desde los servidores, de otra forma, continuará recibiendo material cifrado usando la subclave pública anterior. Por eso recomiendo que sólo utilice este modelo de seguridad con dos factores con llaves nuevas y desde el principio.

Aparte del cliente de GnuPG en consola, también utilizo la extensión Enigmail para Mozilla Thunderbird, y ésta es lo suficientemente inteligente como para pedirme el PIN de la tarjeta inteligente para las operaciones de firma y cifrado que realizo a futuro con la tarjeta inteligente en el lector. Así mismo, necesito la tarjeta y el PIN para descifrar cualquier material sensible que hayan enviado firmado a mi subclave. Este es el nivel de funcionalidad esperado.

Como nota final, puede regenerar las subclaves de firma, autenticación y cifrado en la tarjeta. Sin embargo, mi experiencia personal con la tarjeta g10 es que debe utilizar el protocolo ccid nativo de GnuPG para acceder a la tarjeta. Para esto hay que tener privilegios sobre el dispositivo, por lo que hay un conjunto de reglas de udev disponibles para configurar los permisos a un grupo adicional.