-[ 0x02 ]------------------------------------------------------------------- -[ La hoja rasca ]---------------------------------------------------------- -[ FCA00000 ]-------------------------------------------------------SET-28-- La hoja-Rasca (NdB.1) (Nota del Biografo. Este articulo esta repleto de referencias literarias. Cuando lo considere oportuno introducire una anotacion del tipo NdB.1 que quiere decir 'Nota del Biografo. 1' En este caso, hace un juego de palabras con la obra de Gabriel Garcia Marquez - La hojarasca , y el tema principal: los cartones de rascar) Saludos, lector Voy a contar una historia. Es posible que estes cansado de que te cuenten historietas, pero quizas esta te resulte interesante. Se dice que parte de las historias son contadas para beneficio del lector, y otra gran parte se narran para satisfaccion del autor. Si esta consigue despertar tu interes, me sentire recompensado. Esto trata sobre la creacion de scratchcards, que son esas tarjetas de carton con un cuadro gris que se rasca con una moneda y muestran un numero que escribes en tu movil con tarjeta pre-pago y te proporcionan mas saldo para tus llamadas telefonicas. Asi que si no te interesa el tema, ahora es el momento de parar de leer. Mi nombre es... pensandolo bien, el nombre es uno de tantos hechos circunstanciales que no definen una vida, y, todo hay que decirlo, yo no tengo nombre. Lo que me diferencia de los demas es mi numero: 15212055 No te dice nada? Y si te digo que es un NSCR te aclaro algo? Bueno, ya veo que tendre que empezar desde el principio. Para que estes prevenido, alguna de la nomenclatura que usare es en idioma frances, ya que es en este lenguage en el que fui creada. Y algunos terminos son en danes, o en ingles, para acabar de completar mi bagaje. Toda explicacion llegara en su momento apropiado. Yo soy una tarjeta de recarga de tarjetas telefonicas de pre-pago y naci en una empresa telefonica que llamaremos TelCo para mantener el anonimato. Tecnicamente se llaman scratchcards, pero yo prefiero llamarlo cartoncillo, dejando el termino 'tarjeta' para la tarjeta SIM que se usa dentro del telefono movil. Para que no te pierdas, esto es un esquema del largo camino que he recorrido. Los numeros serviran para referencias en el texto con el formato *xy* 12 17 13 01 11 TARJETA MODULO KEY:SI Secuencia KEY:SC-->-SEGURIDAD-<->-SEGURIDAD 14 | | CREACION CNET: MSc TARJETA | | SEGURIDAD | 02 | IMPRESION +-BLDTK----\ 04 05 | | +-15212051.HDR->-NCSR->-CREATION.EXE-<->-API 18 v 03 / CNET CNET MODULO / | SEGURIDAD / | CNET: MSi / | | /08 v ^ / | | V | v / | 20 | / 07 06 | DESCRIFRA.EXE---<------<------<--tickets.CHI (NSCR & CS) CNET | | v 21 v 23 | IMPRESION------->-------->--------ACTIVACION----------+ TARJETAS 24 | | | v | 22 v ____ | 25 | ENTREGA AL __/ \__ BASE DATOS | DISTRIBUIDOR /54 IN \ TARJETAS | | \ /\ | 26| v \________/ \53 ^50 v 30 | \ | | CLIENTE-----<----SMS---<--------TRANSACCION | | CONFIRM. _/ | | | | 52 43/| ^ v | | / | | 51 27 | 32+--IVR->-\ FTP/XML v +----->----ARCHIVADO 31+--SMS->--\ 41 | 42 | | 33+--WEB->---\ ^ GEM 44 v | \ 40 | DRIVER 56 | | FIREWALL->-+ ^ DATA_WAREHOUSE 34+--ATM-->---/ | 15 35+PAGO_SEGURO v KEY:SV 45 | 19 | 16 API MODULO TARJETA CNET-<->-SEGURIDAD-<-SEGURIDAD CNET: MSv VALIDACION Lo primero que yo recuerdo es que el departamento de provisionamiento informo que el stock de tarjetas de recarga de 15 euros estaba cercano a agotarse y era necesario crear nuevos cartoncillos. La persona encargada del proceso de generacion consulto *01* en un ordenador un numero correspondiente a la ultima secuencia que fue seleccionada para crear tarjetas de 15 euros, y este numero llamado TK15 resulto ser 2161. Incremento el numero en 1 para obtener 2162, y averiguo que el numero de serie de la ultima tarjeta de 15 euros generada era 15212050. Asi que lanzo un programa llamado BLDTK *02* con los parametros BLDTK 2162 15212051 25 Esto genero *03* el fichero 15212051.HDR con las siguientes lineas: Activation information for batch 2162 with external \ serial numbers: 15212051 - 15212075 Credit: 1 Expiration date: 31-12-2005 Logo: front15.gif back15.gif Esto es bastante facil de entender: genera un fichero en el que se archiva el numero de tarea, los numeros de serie *04* que van a ser generados (yo entre ellos, la 4 hermana de 25) y la fecha en la que dejaremos de ser validas. Un poco cruel, saber la fecha de tu muerte, no? Despues introdujo en un lector de tarjetas GEM GCR4000 una tarjeta microchip con un algoritmo de seguridad. Para generar esta tarjeta, alguien de TelCo (lo mismo pasa con Amena o Telefonica o Vodafone o Telecel), junto con alguien de la empresa que fisicamente imprime los cartoncillos (imprentas Perez) , contactaron con alguien de la empresa fabricante de tarjetas chip (Schlumberger o RegieT o Oberthur o Microelectronica Espaniola o DeLaRue o GemPlus en mi caso) y cada uno eligio una semi-llave *11*13* aleatoria de 16 cifras para obtener dos clave publicas, y sus correspondientes privadas, las grabaron respectivamente en sendas tarjetas, y se volvieron a sus oficinas. El responsable de TelCo se queda con *12* la tarjeta MSc, Modulo de Seguridad de Creacion, que sirve para que el operador de servicios genere los codigos cifrados. Por su parte, el de la imprenta se queda con *14* la tarjeta MSi, Modulo de Seguridad de Impresion (un poco si' que impresiona, la verdad) que le permite descifrar el codigo para imprimirlo en los cartoncillos. Tengo que decir en este punto que en realidad se crearon 2 tarjetas identicas con el codigo MSc, y otras con el MSi ; por seguridad, supongo. Dias mas tarde, el de la imprenta fue con otro encargado de TelCo, pero del departamento de tarificacion, e hicieron algo parecido, esta vez re-usando la misma semi-llave de la tarjeta de impresion pero otra semi-llave *15* para el encargado de seguridad de TelCo. Con esto, el chico de TelCo obtuvo *16* una tarjeta MSv, Modulo de Seguridad de Verificacion, que permiten al servidor de pre-pago verificar la validez de un codigo introducido por el usuario del cartoncillo (scratchcard). TelCo mando hacer 12 copias de la tarjeta de verificacion para poder usarlo en varios ordenadores. Notar que la creacion de codigos en un proceso bien planeado (cada 2 semanas, en funcion de la demanda) pero el uso de nuestos codigos puede ocurrir en cualquier momento. 'Eu nao si cuand iste fado ya andaba pel seu pe' (NdB. Fado portugues llamado 'Coracao bateu tres veces'. Saludos para los vecinos peninsulares). El algoritmo *17*18*19* para crear estas claves es propiedad (secreta) de la CNET, que es una empresa del grupo de FranceTelecom establecida en el poligono tecnologico ANTICIPA ubicada en la ciudad de Lannion, en la Bretania francesa. Si es necesario se pueden volver a generar las claves sin mas que usar de nuevo las semi-llaves anteriores. Por eso es imprescindible que ninguna de las partes conozca las otras semi-llaves, ni mucho menos al que ha sido testigo de estas transacciones: el encargado que trabaja en GemPlus. Seria catastrofico que alguien metiera en el ordenador del pobre Gilles Mxxxxxx un troyano que capturara estas claves cuando esta grabando las claves para los algoritmos en las tarjetas chip. Este algoritmo no se puede saber ni siquiera consiguiendo una de las tarjetas chip porque son del tipo microprocesador. Es decir, tienen un puerto de transmision de datos pero no es posible acceder a la memoria interna; solamente llamar a funciones de su EPROM. O pensabas que no se impondria ninguna medida ni se limitarian las metas? (NdB. Werther. Fausto. Momentos despues de firmar el pacto con el diablo) Estas semi-llaves se almacenan en un lugar seguro en las respectivas empresas. Pero sigamos con la historia mas reciente. Como iba diciendo, el operador de TelCo mete su tarjeta con el codigo SC en el lector GEM GCR400, tambien conocido como GemPC400. A continuacion se lanza *05* el programa CREATION.EXE con los parametros CREATION.EXE [nbr_cert] [tickets.CHI] donde nscr es el primer numero de serie (15212051) nbr_cert es la cantidad de codigos que hay que generar (25) tickets.chi es el fichero *06* en el que se guardan los datos. Tambien llamado Key File. Este programa CREATION.EXE pregunta entonces el puerto serie en el que esta conectado el lector de tarjetas. Esto quiere decir que, para mayor seguridad, el programa no puede generar los codigos por si solo. Si fuera asi, cualquiera que consiguiera el programa podria generar los codigos, aunque no se si le serviria para algo. Volveremos sobre esto mas tarde. El programa usa librerias PC/SC para hablar con el firmware GemCore que constituye el Sistema Operativo del microchip insertado en la tarjeta. Este GemCore no es mas que un subconjunto de PC/SC para T=0. En detalle, escribe los digitos de las semi-llaves en la llamada zona de aplicacion, luego escribe mi NSCR, invoca a la funcion para obtener un numero unico CRCHI mediante el correspondiente APDU (Application Protocol Data Unit) y al final lee ese numero de otra zona de aplicacion. Mas informacion en la guia del programador de GemPlus Block Protocol, que es muy buena y explica todo muy clarito. Asi, en tickets.chi nos encontraremos los numeros de serie NSCR, Numero de Serie du Code de Rechargement) y unos codigos cifrados correspondientes a cada uno de nosotras, llamado CRCHI en frances: Code de Rechargement CHIfree. Algo asi como un checksum. O sea, que CREATION.EXE sigue este proceso: -contacta con el lector de tarjetas -toma el primer numero NSCR (Nume'ro de Se'rie de Rechargement) -lo transmite por el puerto serie -el lector de tarjetas recibe el numero y lo pasa a la tarjeta chip -la tarjeta chip toma la clave MSc de su memoria EPROM -con el algoritmo secreto de la CNET, genera el CRCHI -devuelve la respuesta del lector -se devuelve la respuesta al programa -se escribe una linea -repite el bucle hasta llegar a nbr_cert Cada linea de este fichero tickets.CHI es de la forma __NSCR__ ______CRCHI_____ donde NSCR es el conocido numero de serie de recarga, de 8 caracteres CRCHI es el checksum del NSCR con el MSc. Mide 16 caracteres 0-9a-f Por ejemplo: 15212051 0473a25f34cf4369 15212052 988e5d240f583904 15212053 8e3c3d7558a4c8c1 15212054 ec5ebb7c4314cd59 15212055 2006f0aafab2e3e1 <- este soy yo, y mi CRCHI :-) 15212056 3ea91dbfd76a9b77 15212057 ac83a61fa1e80ac0 15212058 867684b29fbf67b6 15212059 e973a6efc9ba529e 15212060 4140a96d4312d2ab 15212061 9595861dc28135c9 15212062 04283f03a9a78ae2 15212063 058631367d6cd092 15212064 71e274fb54322b12 15212065 a67836bece7002bb 15212066 11d8dc99f4ca9a7a 15212067 4c3adac480521ca1 15212068 d282ffb796f82cfb 15212069 6e1f8bd30441a7e4 15212070 4003ed236881406b 15212071 c1c2846fd0822a4a 15212072 af943481c222a429 15212073 adb948928993286b 15212074 c03461e96493304c 15212075 ad45eb2305ae53c4 Ahora mis hermanas y yo viajamos *07* en este fichero hasta el centro impresor de los cartoncillos. Ya que el fichero va cifrado con la clave privada de TelCo, el impresor puede validar que no ha sido alterado durante el transporte. Pero como ademas va cifrado con la clave publica del impresor, solamente este es capaz de descrifrarlo. Asi que el metodo de transporte no tiene que ser extremadamente seguro. Junto al fichero tickets.CHI tambien se incluye *08* el 15212051.HDR para que el impresor sepa el logotipo que tiene que imprimir. Alli se dispone de otro lector similar. El operario inserta su tarjeta con *13* la clave SI, y ejecuta *20* el programa DESCRIFRA.EXE DESCRIFRA.EXE [tickets.CHI] [tickets.txt] que genera el fichero con nuestros codigos de recarga CR=cifrado_de(CRCHI+SI) siendo SI es la clave privada del impresor. O sea, que el CR es un codigo de 14 cifras que depende de mi NSCR (8 cifras) y del CS (6 cifras) de TelCo, llamado Certification de Se'curite'. El fichero tickets.txt tiene lineas de la forma __NSCR__ ______CR______ Por ejemplo 15212051 93173315351389 15212052 05896547629373 15212053 04594573188781 15212054 52578139228235 15212055 34486099807180 <- yo y mi CR 15212056 20641924779614 15212057 27265102941052 15212058 77252813875000 15212059 43139429899575 15212060 57997726163756 15212061 15316677348969 15212062 59367855905272 15212063 83320479763941 15212064 33740343554093 15212065 12539147294601 15212066 83389286361786 15212067 59410246187835 15212068 30397282743583 15212069 77720196088271 15212070 54497437840091 15212071 16424947727102 15212072 22043037428193 15212073 00529361704611 15212074 30722895604436 15212075 25207789615235 Este CR es el que merece la pena. Vale su peso en oro, mas o menos. A continuacion imprime *21* los cartoncillos con un disenio basado en front15.gif y back15.gif, que resultan ser la cara y el reves con el anagrama de TelCo y un valor de 15 euros, con unos huecos para imprimir los codigos. Al combinarlo, resulta asi: +-----------------------------------------------+ | | | 34486099807180 | | TTTTT | | T 1 55555 | | T E L C O 11 5 | | T 1 5555 | | 1 5 | | SMS:969696969 111 5555 IIIIIIII | | VOZ:969696966 15212055 | +-----------------------------------------------+ Aunque el formato puede cambiar, seguro que aparece mi CR. El resto de los datos dependen de la operadora telefonica. Por ejemplo, conozco primas segundas mias en las que el CR aparece en dos casillas: una con 8 digitos y otra con 6, para dar 14. Aunque mide lo mismo que el NSCR + CS, no es lo mismo; no te confundas. En mi caso, tambien aparezco yo misma. No por nada, pero para darme un poco del reconocimiento debido. En este cartoncillo tambien aparezco yo, aunque esto no es necesario. Al fin y al cabo, la informacion util -lo unico que transmite el usuario- es el CR. Justamente encima mio aparece un codigo de barras IIIIIIII que es siempre el mismo para todas las tarjetas hermanas. O sea, que hay 25 tarjetas con este mismo codigo de barras, que, como podeis suponer, incluye el numero 2162 (la secuencia unica, para los olvidadizos). Yo se que todos hemos ido a parar juntos al mismo distribuidor, asi que no me he separado de mis hermanas hasta que no he sido adquirida por un ansioso comprador. Esto tiene un simil con los hogares de adopcion que prefiero no recalcar. Otras primas lejanas mias aparecen tambien con un codigo de barras individual y unico para cada uno de ellas. Seguramente forman parte de alguna elite. El codigo de barras puede estar en formato code39, 2of5 interleaved, EAN8 o EAN13, para que nos puedan leer con un lector de codigo de barras. Esto es util cuando somos vendidas en los supermercados; asi saben que tienen que reponer existencias, con lo cual otras primas salen a la luz. Supongo que huelga decir que el dibujo impreso es el de 15 euros, que son precisamente los 2 primeros digitos de mi nombre. No es casualidad. Otras de mis parientes fueron impresas en cartoncillos junto con otro codigo diferente: NSTE , Numero de Serie de Ticket Externe. No esta relacionado con el NSCR ni el CR, y su utilidad responde a las necesidades de gestion del proveedor de servicios. Permite identificar cada cartoncillo. Se compone de 8 cifras, aunque para imprimirlo se le anteponen 3 cifras 'ytn' siendo y codificacion del generador del ticket: 1 para GEMPLUS, 2 para RegieTt tipo de ticket: 0 para 15 euros, 1 para 30, 2 para 50 version: 1 para antes de 1998, 2 para despues de 1998 Para generar estos NTSE se toma un numero secuencial que simplemente se va incrementando, pero en el fondo lo unico que hace falta es que sea unico. Para mi, este codigo es 14980126 para dar 1014980126. Me pregunto si de verdad se han generado 14.980.125 tarjetas antes que yo. Asi que ya estoy fisicamente impresa en un cartoncillo, con una capa de pintura plateada recubriendo el CR secreto, y envuelta en un plastico transparente sellado. Lo siguiente que recuerdo es que nos metieron en una caja oscura, y cuando vi la luz de nuevo estaba pasando a *22* las manos de un distribuidor dentro de una tienda de articulos de informatica y consumo. Pero antes de continuar debo explicar que tambien segui otro camino: en algun momento, posiblemente cuando estaba siendo empaquetada o enviada a la tienda, el responsable de la imprenta *23* notifico a TelCo que habiamos sido impresas. Este intercambio se produjo a traves de un fichero con el formato: TYPE_REG (2) tipo de registro; siempre 20 COD_OPE (3) codigo identificador de operacion efectuada: 110=creacion 112=re-creacion 210=suspension 211=restablecimiento tras suspension 310=retrasado 311=supresion 312=utilizacion 313=fin de validez NSTE (8) numero de serie externo de cartoncillo NSCR (8) numero de serie de codigo de recarga DATE_VALID(6) fecha YYMMDD de fin de validez TYP_TR (3) tipo de ticket de recarga : ytn STAT_TR (3) estado del ticket de recarga NUM_CLI (10) numero fiscal de empresa cliente (TelCo) NUM_APP (10) numero fiscal de empresa proveedora (impresor) DATE_CRE (10) fecha YYMMDDHHMM de creacion del cartoncillo Por supuesto que no le comunico los CRs, pues eso romperia totalmente la seguridad, pero como TelCo ya tenia tambien nuestros NSCRs, esto le sirvio de confirmacion que nos habian impreso satisfactoriamente, asi que nos metio *24* en el sistema a partir de la primer columna del fichero tickets.CHI, introduciendonos en *25* la base de datos de tarjetas. Es decir, que me converti en un registro en la tabla cardstable, que tiene la siguiente estructura: serial_number(CHAR 8) -> el NSCR, no se porque no usan su nombre real reloading_code(CHAR 14) -> en principio vacio. Cuando me usen, valdra el CR validez_dt(DATETIME) -> fecha de validez credit(INTEGER) -> cantidad de euros que recargare validez_periodo(DATETIME) -> periodo de validez que extiendo el telefono operacion(INTEGER) -> lote, logo, y operacion comercial status(INTEGER) -> 1-disponible 2-expirado 3-anulado 4-usado msisdn(CHAR 10) -> numero del subscriptor que me ha usado reloading_dt(DATETIME) -> fecha de recarga, cuando me usen Esta tabla contiene siempre la informacion mas reciente de las tarjetas para poder consultarla en cualquier momento. Asi se explica que tanto los campos serial_number como reloading_code sean unicos. Con esto tambien *27* se registro la transaccion en el archivo, que es otra tabla llamada cardslog, con la misma estructura. Esta tabla mantiene todos los hechos sucedidos a una de nosotras. Esto explica que normalmente aparecemos en 2 registros: uno con status=1 y otro con status=2, 3, o 4. El registro con status=1 tiene vacios los campos reloading_code y msisdn, mientras que si status=4 entonces esos valores tienen datos. Pues ya estamos listas para ser usadas. No hube de esperar mucho tiempo para que me sacaran del envoltorio con el objeto de cumplir *30* con mi cometido. El propietario del telefono con tarjeta de prepago rasco el codigo secreto, edito un SMS con destino 969696969 en el que yo (bueno, mi CR) era el unico y principal protagonista y me envio *31* en mi nuevo viaje. Al aterrizar en un SMSC (Short Messages Service Center) fui metido en una maquina muy grande de Nokia en la que coincidi con otros muchos mensajes, pero como yo iba dirigida a un telefono especial interno de TelCo no me dejaron ir muy lejos y fui exportada a un fichero de texto en el que se indicaban la fecha de recepcion, el numero de telefono MSISDN del usuario que envio el SMS, y la informacion que habia escrito: si no se habia equivocado al teclear, este seria el CR adecuado. Alli me encontre con primas mias y cuatro hermanas, esperando a ser procesadas. Me contaron que habian llegado por otros medios. Por ejemplo, mi hermana 15212052 dice que su propietario habia llamado *32* al telefono 969696966 donde una voz mecanizada IVR (Interactive Voice Response) habia indicado que dijeran los numeros secretos, y el usuario dijo, uno por uno: 05896547629373. Menos mal que le pidio confirmacion, porque las 3 primeras veces habia algun numero que el sistema no habia identificado correctamente. Su historia de como habia ingresado en la red inteligente (IN-Intelligent Network) era apasionante, sobre todo la comunicacion con protocolo SS7 entre el SSP y el STP y el SCP. Si tengo tiempo la contare mas tarde. La otra hermana 15212053 me dijo que su usuario tambien la adquirio en la tienda pero como el telefono no lo tenia alli sino en casa de su padre habia decidido *33* conectarse a la pagina web de TelCo para escribir el numero de telefono y el numero secreto 04594573188781. La seguridad que ella vio por el camino durante la Internet le parecio bastante baja, pero ella lo unico que deseaba era llegar al destino y reunirse con nosotras; la seguridad intermedia solo tenia que garantizar que su NSCR y CR llegaban y nadie los modificaba o detenia. El momento de ser verificada todavia no habia llegado, asi que el unico riesgo que habia es que un usuario metiera numeros aleatorios para ver si alguno funcionaba. Mas tarde nos enteramos que esto resulto fatal para otro usuario que lo intento antes. El procedimiento de recarga a traves de *34* cajeros automaticos ATM no usa scratchcards ni codigos de recarga CR asi que no se como funciona, aunque seguramente sigan otro proceso diferente hasta el final, cuando el importe es aniadido al saldo del usuario, ya que no es posible inventarse un CR. Lo mismo sucede con otros metodos *35* de pago seguro en los que solo es necesario una tarjeta de credito. Mencionar que existe y esta alojados en un servidor propio de TelCo, pero no usa de codigos para los CR asi que se sale del ambito de mi vida. Una vez juntas todas *40* en un fichero de texto dentro de esa maquina dedicada con formato propietario de Nokia, apenas esperamos unos segundos para que *41* una sesion FTP nos transfiriera a nosotras hasta otra de TelCo. 'At rejse er at leve' (NdB. Viajar es vivir. Dicho popular en Dinamarca debido a H.C.Andersen) Hay otra posibilidad *42* para pasar a la red interna, y es usando HTML/XML. Para ello la maquina de Nokia se conecta *43* a odin.telco.com al puerto 8006 y empezar a hablarle en el lenguaje que entiende: XML El formato DTD para recargar se llama ODINXmlReq.dtd y es (parcialmente): Por ejemplo: Y el DTD de la respuesta se llama ODINXmlRes.dtd y es: Por ejemplo: Los codigos de error son: 0099 TimeOut 0100 Usuario invalido 0150 XML mal formado 0155 XML no valido 0160 Error comunicando con IN 0170 Incapaz de procesar comando 0190 Privilegios insuficientes 0191 Usuario desconocido 1001 MSISDN invalido 1005 Cantidad invalida 1010 MSISDN desconocido 1011 Imposible incrementar cantidad 1021 Cuenta prohibida F=retenida (Frozen) D=en espera (Dormant) A=Activa S=suspendida 1022 Codigo de Recarga ya usado 1023 Codigo de Recarga no activado 1100 Error general Ya sea por un metodo o por otro, la cosa es que por fin habiamos traspasado el firewall, siendo succionadas hacia la intranet. Que diferencia de trato, chica. Si en el mundo exterior todo eran barreras y confirmaciones, en la intranet pasamos a un ordenador con Linux 2.4.57 (puedes creerlo?) llamado odin.telco.com -juego de palabras entre el dios escandinavo y 'Output Driver for Intelligent Network'- que tenia *44* un programa Java que leyo las lineas, aislo mi CR y lo mando por el puerto serie mediante *45* protocolo PC/SC a un lector de tarjetas que tenia insertada *15* la tarjeta con la clave de verificacion SV, y el programa *19* grabado en el microchip interno a la tarjeta verifico que el checksum era correcto, extrayendo a su vez el NSCR, que el programa Java le devolvio al Linux, en un proceso similar al que tuve cuando fui creada o me imprimieron. Por fin estabamos verificadas y autorizadas! A partir de ahora el proceso es sencillo, pero muy importante: Usando de un driver JDBC usamos una cadena de conexion del tipo "jdbc:oracle:thin:@10.0.0.1:1521:SCRATCH;User=SYSTEM/MANAGER" para engancharnos *50* con la base de datos ORACLE de todas las tarjetas donde se actualiza la tabla cardstable: UPDATE cardstable SET reloading_code='34486099807180', status=4, reloading_dt=SYSDATE, validez_periodo=SYSDATE+180, msisdn='609696969' WHERE serial_number='15212055' AND status=1 y similarmente inserta *51* un nuevo registro en la tabla cardslog. Esto hace que se envie *52* un mensaje al cliente propietario del telefono en el que se le indica su nuevo saldo, y la validez: 180 dias mas. Otras bases de datos obtendran la informacion replicando esta tabla. Pero no les esta permitido actualizarla. There's always something left behind... never mind. (NdB. Cancion 'My favourite dress' del grupo 'The Wedding Pressent') Lo que pasa es que el importe total de credito del usuario esta en otra base de datos mucho mas importante: la base de datos de facturacion. Pero yo no llegue hasta esta tabla final; considera que yo soy solo un incremento del credito, y el valor total esta relacionado con otros procesos; por ejemplo puede incluir ofertas y campanias especificas que hagan que el incremento sea mayor que los 15 euros iniciales. Asi que ya toda la informacion esta registrada en la organizacion de TelCo. El ultimo punto *53* es decirle a la red inteligente este nuevo saldo. La IN tiene *54* unos nodos llamados SCP (Signal Control Point) con unas bases de datos en los que se almacenan unos cuantos numeros de telefono y el saldo disponible. El SSP (Signal Control Point) es un switch telefonico que se encarga de originar, terminar, o intercambiar llamadas. Esta equipado con SS7 (Signaling System 7) que es el protocolo que le permite conectarse con otros nodos de la red inteligente para procesar los servicios. Cuando el usuario pretende efectuar una nueva llamada el SSP recibe la notificacion y se comunica con el STP (Signal Transfer Point) que enruta el mensaje (intencion de establecimiento de llamada) hacia el SCP, quien en ese momento averigua el saldo disponible (quizas preguntandolo a otros SCP, si no posee la informacion de ese subscriptor concreto) para permitir la llamada, o devolver un mensaje de denegacion del servicio, quizas consultando con otro SCP cual es el mensaje que hay que decirle al usuario. La red inteligente esta constantemente comunicada con la base de datos masiva que se encuentra en los ordenadores servidores principales de TelCo. A traves de CAMEL-2 (Customized Applications for Mobile network Enhanced Logic) otras redes de otras empresas telefonicas nacionales e internacionales pueden saber si la persona puede establecer llamadas y recibirlas estando en Roaming. Tipico ejemplo del camello que sube al tranvia en Grenoble y este le muerde la pierna. (NdB. Superlopez 20) Ya casi al final de todo este proceso, los datos de creacion de mi NSCR, la impresion de mi cartoncillo, mi adquisicion, mi activacion, el MSISDN del usuario, el IMSI , las fechas de recarga e incluso los datos de las llamadas realizadas y SMS enviados van a parar *56* a un sistema enorme de DatawareHouse que analiza los comportamientos de los clientes para ofertar otros servicios, evitar que huya a otro operador, creacion de planes nuevos, analisis de tiempos y cualquier idea que se le ocurra a los directivos que velan por el negocio de TelCo. Durante mi larga vida he pasado por situaciones de riesgo en la que pensaba que si alguien me robaba o me duplicaba seguramente el sistema se volveria loco al ver que estaba siendo usada varias veces. Veamos cuales han sido estas ocasiones y lo que los chicos de TelCo hacen para evitar estos intentos de fraude. Lo que siempre hay que tener en cuenta es que la propia TelCo tiene que generar los NSCR y activarlos en sus bases de datos y meterlos en la red inteligente. Existen muchos codigos validos desde el punto de vista del checksum (CR), pero solo algunos de ellos estan activos en la base de datos. Se llama a esto la barrera de activacion interna en la empresa (IHAW, In House Activation Wall). El otro aspecto que no hay que perder de vista es que el numero de telefono esta controlado en todo momento por TelCo y cuando sospecha algun fraude puede impedir/cortar la llamada y otras cosas peores. Acojonao? Pues espera que ahora te detallo lo que pueden hacer. Esto se denomina sistema de activacion retroactiva (BAS, Back Activation System), aunque la mayoria de las veces se usa para des-activacion. Solo por curiosidad, vamos a ver lo que puede hacer el BAS. Esta informacion ha sido obtenida por comentarios informales asi que no pude verificar si estos procedimientos se aplican o no. En todos los casos se genera una alarma que mas tarde una persona puede -o no- comprobar. Caso 1) Un usuario intenta usar un CR que no verifica el checksum. No sucede nada. Caso 2) Un usuario introduce un CR incorrecto por tres veces. Se asume que no ha escrito bien el SMS pero se empenia en mandarlo. No sucede nada. Ya llamara a TelCo si quiere. Caso 3) Un usuario usa en pocos minutos distintos CRs incorrectos. Posiblemente se trata de alguien que quiere pasarse de listo. No aguantaremos sus insolencias, te lo prometo. (NdB. Romeo y Julieta. Primera frase: 'Gregory, on my word, we'll not carry coals'). Se lanza otra alarma, y se puede: 1) Anular todo su saldo - posiblemente sea poca cantidad. 2) Cancelar su numero de telefono (que , por otra parte, ha sido otorgado por la propia TelCo) 3) Dado que es un telefono pre-pago, quizas no existan otros datos del cliente tales como direccion, nombre, ... ; pero en el caso de que existan, se contacta con el usuario advirtiendole. 4) Como tambien se conoce el numero de serie IMEI del telefono (no solo de la tarjeta SIM), se introduce en la base de datos mundial de telefonos fraudulentos y nunca mas se puede volver a usar ese telefono. 5) Mediante la triangulacion definida por las antenas, y aplicando un simple calculo de GIS (Sistema de Informacion Geografica) se averigua con una precision de 2 metros donde esta el sujeto en todo momento, aunque este radio es mayor en zonas con menos antenas. Deja volar tu imaginacion para imaginar lo que puede pasar. Incluso dias mas tarde del intento de fraude. (Particularmente no me creo que TelCo llegue a este extremo) Caso 4) Un usuario especifica un CR que ya habia sido usado. Una o mas veces. No sucede nada. Se asume que alguien ha encontrado un cartoncillo por la calle y esta intentando usarlo otra vez. Pobre diablo. Caso 5) Varios usuarios usan el mismo CR en un corto periodo de tiempo. El primero funciona pero para los siguientes el CR ya ha sido usado. Esto es un claro ataque. Se aplica el caso 3 a todos ellos. Caso 6) Un usuario utiliza CR incorrectos que se distinguen en 1 o 2 cifras. 1) Si se intenta menos de 3 veces se asume que es un usuario torpe. 2) Si se intenta mas de 5 veces se asume que es un ataque de prueba/error y se aplica el caso 3. Caso 7) Un usuario usa distintos CR correctos en un corto periodo de tiempo. Aunque esto es perfectamente legal, resulta sospechoso que haya comprado varias tarjetas, en vez de comprar una con el precio total. Caso 8) Un usuario carga una cantidad excesiva de dinero. Aunque esto tambien es perfectamente legal, levanta sospechas. TelCo no quiere que nadie tenga demasiado dinero en una tarjeta pre-pago. Por cierto, el limite real esta en 99.999.999 unidades. Si la unidad es centimos de euro, el limite es casi 1.000.000 euros. Caso 9) Si las tarjetas han sido robadas en la tienda, los CR se marcan con status=3 (anulado). El uso de cualquiera de estas tarjetas dispara una alarma que conlleva la anulacion inmediata del numero de de telefono, al igual que BAS.3.2 Otros factores que disparan alarmas son: -medio de uso: las alarmas provenientes de intentos a traves Web se analizan con mas detenimiento, por ser cuna habitual de individuos peligrosos. Algo habran hecho para merecer ese castigo, mi Senior. (NdB. Don Quijote. Replica de Sancho cuando don Quijote pretende liberar a los galeotes) -ubicacion geografica: los intentos fallidos desde zonas deprimidas economicamente son mas propensos a recibir mayores castigos. Como nota curiosa, los intentos realizados en areas incluyendo centros comerciales tambien son de alto riesgo, mientras que las zonas residenciales son de pefil de bajo riesgo, y, por consiguiente, las sanciones son menores. -el momento del dia: por lo que oido, durante la maniana se producen muchos mas casos del tipo 1 y 2 y 6.1 que en otros momentos del dia, porque las amas de casa van a recargar sus moviles, y se equivocan al teclear. Si quieres te lo crees. Voy a detallar los momentos en los que algun hacker de los que hay por el mundo podria haber corrompido los datos y las medidas que evitaron que tuviera exito. El primero sucedio cuando se generaron las tarjetas chip con los codigos. Aunque las semi-llaves hubieran sido robadas no se podria hacer nada porque no se sabe el algoritmo que se usa para generar los NSCR. Si asaltante supiera el algoritmo y ambas semi-llaves seria capaz de obtener un CR a partir de un NSCR. No le serviria inventarse un NSCR y generar su CR, pues esto chocaria contra el IHAW, pero aun asi el ataque esta claro: ir a una tienda, solicitar una tarjeta como yo que tenga el NSCR impreso. Me mira pero no me compra, aunque memoriza mi NSCR. Vuelve a su guarida para calcular el CR, y usarlo. Cuando un comprador legitimo me compre resultara que el codigo ya ha sido usado, y posiblemente el ingenuo se estrelle contra el BAS. Incapaz de saber que ha sido victima de un fraude seguramente formara un caso 4. Si consigue convencer al servicio de atencion al cliente de TelCo -al fin y al cabo, el usuario posee el NSCR y el cartoncillo original- le devolveran el dinero y al autentico defraudador le aplicaran BAS.3 ; quizas BAS.3.4 Una alternativa a esta es comprar un cartoncillo, y suponer que los restantes que han quedado en la tienda tienen NSCR secuenciales con el que ha adquirido. Pero esto es BAS.7 Otro momento de panico sucedio cuando se ejecuto el programa CREATION.EXE para generar la lista. Supongamos que el programa tiene un troyano que manda la lista de NSCR y CRCHI a un malvado. Sin los CRs no valen de mucho. Mas interesante seria si incluyera en tickets.CHI siempre un NSCR constante, del que el atacante supiera el CR. Por supuesto que alguien notaria que la lista tiene un numero que no va en secuencia, pero ademas el sistema no podria introducir en la base de datos un NSCR que existia, de cuando tickets.CHI fue generada anteriormente. IHAW again. Mas tarde viajo en el fichero tickets.CHI hasta el impresor. Si alguno de los codigos fuera alterado por el camino, el impresor no podria descifrarlo con la clave publica del MSc y sabria que algo raro estaba sucediento. Bondades del sistema de claves publicas y privadas. Si el impresor decidiera imprimir alguna tarjeta con un CR que no pertenece a ningun NSCR de la lista, simplemente no estaria en la base de datos. De bruces contra el IHAW. Otra cosa seria si usara un codigo ya impreso anteriormente, o duplicara una tarjeta, usando una para su propio provecho. Alguien sufrira un BAS.5 Notar que los CR que se pueden usar nunca esta en poder del MSc , y solo llega hasta el MSv cuando alguien me intenta usar. El ataque que definitivamente funciona es interceptar los CR cuando estan en las oficinas del impresor. Esto incluye desde el momento en que DESCRIFRA.EXE genera mi CR hasta el momento en que se recubre con pintura plateada la zona del cartoncillo en la que esta impreso el CR. Por ejemplo, un operarios que trabaja en la fotocomposicion. BAS.5 Y es que el siglo veinte es un despliegue de maldad insolente. (NdB. Referencia al tango 'Cambalache'. Un saludo para los portenios) Pero esto forma parte del procedimiento fisico de seguridad que tenga establecido el impresor dentro de sus oficinas. El ultimo ataque fuera de la zona No-Desmilitarizada, es decir, antes del firewall, se podria llevar a cabo con un spoofing (alteracion de la personalidad) del servidor de TelCo que recibe las peticiones. No hay que pensar solo en suplantar al servidor web que permite que los usuarios escriban su MSISDN y mi CR, sino tambien sniffeando y anulando al servidor SMSC de mensajes SMS (ya se, es un reto muy grande) o al servidor al cual se conecta el sistema bancario cuando el usuario recarga su tarjeta pre-pago desde un cajero. Tambien quedaria impresionante suplantar el IVR. Vamos, llama a TelCo y diles que deseas alquilar el numero de telefono 969696966, veras cuanto se rien. Dentro de la Intranet de TelCo el unico ataque puede efectuarlo un trabajador descontento o un troyano (control remoto). El fichero en el que me encuentro, junto con algunas de mi hermanas y primas, esta en un fichero de un SCP propiedad de Nokia, que tiene un sistema operativo completo, con conectividad FTP y HTTP, lo cual permite que la maquina Linux lo recoja. Recuerda que el malvado simplemente ha generado una peticion para que su MSISDN sea recargado, en virtud de un CR mas falso que una moneda de 7 euros, pero que intentara parchear algun sistema para que sea aceptado como bueno. Yo, desde el primer momento que vi a aquel CR ya presentia que no era de buena familia. Por supuesto no tiene sentido modificar el fichero recibido antes de procesarlo, pero, que pasaria si el Servidor de Transacciones (el Linux troyanizado, para los que se han perdido) decidiera que ese CR concreto le ha caido bien, y no necesita pasar por la validacion? Al igual que los otros CR correctos, lo mete en la base de datos de recargas exitosas junto con el malvado CR, e incrementa el saldo. Pero esto solo funciona la primera vez, porque si este metodo se usa otra vez con el mismo CR, resultaria que estaria duplicado, y saltaria otra alarma. Como tenemos el MSISDN, pasamos a BAS.5 La solucion estaria en transformar el CR malvado en otro CR. Pero si se elige un numero aleatorio (total, ya ha pasado la verificacion) hay otro mecanismo de alarma: los CR almacenados en la tabla cardstable se pueden verificar una y otra vez, y, dado que hay varios servidores de transacciones redundantes (cada uno con su propio lector de tarjetas, aunque todos con la misma copia de la tarjeta microchip) lo mas seguro es que se haga una auditoria cada mes y se detecte que hay un codigo incorrecto. Entonces si que saltan las alarmas de verdad ! Asi que la unica posibilidad que le queda es usar un CR que todavia no haya sido usado. Esto es imposible, pues el modulo MSv no puede calcular un nuevo CR; solo puede verificar. Si alguna de nosotras tiene la mala suerte de ser robada en la tienda, Telco puede anularme buscando mi NSCR (no mi CR, pues al no haber sido usada no posee todavia ese dato) y poniendo status=3 (anulada). Lo mismo sucede si me pierdo por el camino, si alguna de nosotras ha tenido algun problema a la hora de ser impresa (ej. los numeros salen borrosos), si el propietario de la tienda decide anular el pedido, o mil circunstancias mas. Una cosa que le paso a una conocida mia es que fue adquirida, rascada, y al intentar activarla resulto que el telefono no era de pre-pago sino de contrato. El incremento de saldo no se realizo porque no tenia sentido, el CR fue registrado como status=4 (usado) pero a la hora de hacer los informes de TelCo ese numero de telefono no aparecia en la lista de telefonos validos. La solucion fue marcarlo como anulado. El recargo fue deducido de la factura del cliente del mes siguiente. Otro cliente satisfecho. Como veis, el control del fraude es una tecnica ampliamente estudiada e implementada en TelCo, y por extension, en cualquier compania telefonica que sepa lo que le interesa. Asi que espero que te haya parecido interesante mi vida y no se te ocurra intentar enganyar al sistema. -------------------------------------------------------------------------- -Ya, ya, todo esto esta muy bien, pero seguro que existe algun metodo secreto para obtener nuevos codigos para recargar tarjetas de pre-pago . Vamos, no seas rata y dimelo, que no te cuesta. -No has entendido nada de nada, verdad? Bueno, aqui tienes algo que quizas te sirva. Ejecutalo y dejame en paz. Pero si te pasa algo yo no soy responsable. /* La ejecucion de este programa puede tener consecuencias desastrosas */ /* ASEGURATE QUE ENTIENDES LO QUE HACE ANTES DE PONERLO EN MARCHA. */ #include #include char TK15[]="02161"; char HalfKey[]={0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16, 17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,255}; int nbr_cert=25; int _system(char *i) { return(HalfKey[*i]^TK15[*i%5]); } char MSc[]={83,94,66,54,66,50,33,32,40,53,37,98,154,31,53,15,86,243, 76,20,84,252,76,26,35,138,14,22,193,94,255,32,0}; char MSi[]={83,94,66,22,10,16,81,93,83,80,66,50,198,35,76,90,220,32, 24,34,174,32,49,92,188,82,83,92,131,25,254,33,0}; char MSv[]={85,81,89,89,17,126,93,17,83,95,68,91,84,88,85,85,65,17, 88,80,84,83,49,183,249,242,14,18,250,99,253,34,0}; main() { int i=0; for(i=0;i<32;i++) { MSc[i]^=TK15[i%5]; MSi[i]^=TK15[i%5]; MSv[i]^=TK15[i%5]; } printf("------------------------------------------------------- \n"); printf("| NSCR | CRCHI | CR | \n"); printf("------------------------------------------------------- \n"); for(;nbr_cert>0; nbr_cert--) { for(i=0;i<32;i++) HalfKey[*i]^=TK15[*i%5] printf("%16i" ,system(MSc)); printf("|"); printf("%16i" ,system(MSi)); printf("|"); printf("%16i" ,system(MSv)); printf("\n"); } } *EOF*