Algoritmo de Luhn para la validación IMEI: cómo funciona el dígito de control

Estás configurando un sistema automatizado para validar números IMEI procedentes de una plataforma de gestión de dispositivos. 10.000 entradas. Algunas son claramente incorrectas — una errata, un marcador de posición 000000000000000, un valor pegado con espacios. ¿Cómo filtras la basura sin llamar a una API por cada entrada? El algoritmo de Luhn. 10 líneas de código, ejecución en milisegundos, y has eliminado el 95% de los IMEI inválidos antes de cualquier solicitud de red.

Esto no es un ejercicio teórico. Cualquier equipo que gestione flotas de dispositivos — plataformas MDM, operadores de telecomunicaciones, sistemas de seguros, plataformas de mercado secundario — se enfrenta a este problema a escala. Entender cómo funciona el algoritmo de Luhn, y cuáles son sus límites, es un conocimiento fundamental para cualquiera que construya sobre datos IMEI.

¿Qué es el algoritmo de Luhn?

El algoritmo de Luhn — formalmente conocido como fórmula de Luhn o algoritmo módulo 10 — fue creado por Hans Peter Luhn, ingeniero en IBM. Lo patentó en 1954, originalmente como un mecanismo sencillo de protección contra errores accidentales de entrada de datos en números de identificación.

El algoritmo nunca fue concebido como una medida de seguridad criptográfica. Su propósito era preciso y práctico: detectar los errores de transcripción humana más comunes — un dígito incorrecto, dos dígitos adyacentes intercambiados — antes de que un número sea procesado más adelante en la cadena.

Esa simplicidad práctica lo hizo omnipresente. Hoy, el algoritmo de Luhn está integrado en:

• Números de tarjetas bancarias (Visa, Mastercard, American Express) — un número válido según Luhn es un requisito previo antes de cualquier intento de autorización bancaria
• Números IMEI — exigido por la Recomendación ITU-T E.118 y aplicado por la GSMA para cada dispositivo móvil vendido en el mundo
• Números de Seguro Social canadienses (SIN)
• Algunos números NPI (National Provider Identifier) en el sistema de salud estadounidense
• Números ICCID en tarjetas SIM

Para los IMEI en particular, la especificación Device Check de la GSMA exige que todos los IMEI de 15 dígitos lleven un dígito de control Luhn válido como condición de integridad básica. Cualquier dispositivo que falle esta verificación es estructuralmente inválido.

El algoritmo es computacionalmente trivial: O(n) donde n es el número de dígitos. En hardware moderno, validar 10.000 IMEI tarda menos de un milisegundo. Esto lo convierte en un filtro previo ideal antes de cualquier llamada a una API externa.

El algoritmo de Luhn paso a paso

Recorramos el algoritmo usando el IMEI real 356938035643809.

Este IMEI se descompone así:

• Carga útil de 14 dígitos: 35693803564380
• Dígito de control: 9

El objetivo es verificar que el dígito de control 9 es correcto.

IMEI:      3  5  6  9  3  8  0  3  5  6  4  3  8  0  9
Posición: 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1

Paso 1 — Doblar cada segundo dígito desde la derecha.

Empezando desde la posición 2 (penúltimo dígito), doblar cada dígito en posición par (desde la derecha). Las posiciones impares permanecen sin cambios.

Posición:  15 14 13 12 11 10  9  8  7  6  5  4  3  2  1
Dígito:     3  5  6  9  3  8  0  3  5  6  4  3  8  0  9
¿Doblar?:   -  x  -  x  -  x  -  x  -  x  -  x  -  x  -
Resultado:  3 10  6 18  3 16  0  6  5 12  4  6  8  0  9

Paso 2 — Restar 9 de cualquier valor doblado superior a 9.

Esto equivale a sumar los dos dígitos del resultado (por ejemplo, 10 da 1+0=1, 18 da 1+8=9).

10 → 1
18 → 9
16 → 7
6  → 6
12 → 3
6  → 6
0  → 0

Secuencia actualizada: 3, 1, 6, 9, 3, 7, 0, 6, 5, 3, 4, 6, 8, 0, 9

Paso 3 — Sumar los 15 dígitos.

3+1+6+9+3+7+0+6+5+3+4+6+8+0+9 = 70

Paso 4 — Verificar la divisibilidad por 10.

Si la suma total es divisible por 10, el IMEI es válido.

70 mod 10 = 0 → Válido ✓

Calcular el dígito de control (modo generación):

Si tienes una carga útil de 14 dígitos y necesitas calcular el dígito de control:

Suma de 14 dígitos (tras doblado) = 61
Dígito de control = (10 - (61 mod 10)) mod 10 = (10 - 1) mod 10 = 9

Por qué detecta la mayoría de los errores

Un solo dígito transpuesto cambia la suma de Luhn en una cantidad no nula que casi nunca es un múltiplo de 10. Más precisamente:

• Cualquier error en un solo dígito siempre se detecta (tasa de detección del 100% para transposiciones de un solo dígito)
• Intercambios de dígitos adyacentes (por ejemplo, 35 convirtiéndose en 53) se detectan en la mayoría de los casos — la única excepción es intercambiar dos dígitos idénticos, que no cambia nada
• Corrupción aleatoria — tasa de detección de aproximadamente el 90% para errores de múltiples dígitos aleatorios

Lo que Luhn no puede detectar: cualquier manipulación que produzca intencionalmente un dígito de control válido, o cualquier corrupción fortuita que preserve la divisibilidad por 10.

Estructura del IMEI — qué significa cada parte

Un IMEI es un número de 15 dígitos definido por ITU-T E.212 y gestionado por la GSMA. Está estructurado en tres campos contiguos:

TAC — Código de Asignación de Tipo (dígitos 1 al 8)

El TAC identifica el tipo de dispositivo: fabricante y modelo. Es asignado por la GSMA durante la certificación del dispositivo. Los dos primeros dígitos del TAC históricamente identificaban el organismo notificador (por ejemplo, 35 fue asignado originalmente al British Approvals Board for Telecommunications), aunque la asignación moderna de TAC ha evolucionado.

Ejemplo: 35693803 pertenece a un modelo Samsung. Los fabricantes reciben bloques de TAC y deben registrar cada modelo antes de la venta. Una búsqueda TAC puede indicar el fabricante, el nombre del modelo y, a veces, las bandas de frecuencia compatibles.

Número de Serie — SNR (dígitos 9 al 14)

Seis dígitos que identifican de forma única la unidad específica dentro de un TAC dado. Los fabricantes los asignan secuencialmente en la mayoría de las líneas de producción, aunque algunos usan esquemas aleatorios para evitar la enumeración de unidades. Existen hasta 1.000.000 de números de serie posibles por TAC.

Dígito de Control (dígito 15)

El dígito final, calculado mediante el algoritmo de Luhn sobre los 14 dígitos anteriores. Su único propósito es la detección de errores. No contiene información sobre el dispositivo.

Patrones IMEI inválidos comunes

Más allá de fallar la verificación Luhn, ciertos IMEI estructuralmente válidos son semánticamente inválidos por convención:

Patrón	Razón
000000000000000	Marcador de posición — usado por dispositivos restablecidos de fábrica, emuladores y máquinas virtuales
111111111111111	IMEI de prueba — pasa Luhn pero nunca es un dispositivo real
123456789012345	Valor de prueba secuencial
490154203237518	IMEI de prueba comúnmente usado en entornos de desarrollo
Cualquier valor de menos de 15 dígitos	Estructuralmente malformado

Un validador robusto debe marcar todos estos patrones además de la verificación Luhn.

Implementar la verificación Luhn — ejemplos de código

Python

def luhn_check(imei: str) -> bool:
    digits = [int(d) for d in imei if d.isdigit()]
    if len(digits) != 15:
        return False
    check_sum = 0
    for i, d in enumerate(reversed(digits)):
        if i % 2 == 1:
            d *= 2
            if d > 9:
                d -= 9
        check_sum += d
    return check_sum % 10 == 0

Uso:

>>> luhn_check("356938035643809")
True
>>> luhn_check("356938035643800")
False
>>> luhn_check("000000000000000")
False

La función elimina primero los caracteres no numéricos, lo que maneja correctamente entradas como "35 693803 564380 9" (con espacios). Devuelve False para cualquier entrada que no tenga exactamente 15 dígitos tras la eliminación, y luego aplica la verificación Luhn.

JavaScript

function luhnCheck(imei) {
  const digits = imei.replace(/\D/g, '');
  if (digits.length !== 15) return false;
  let sum = 0;
  for (let i = 0; i < 15; i++) {
    let d = parseInt(digits[14 - i]);
    if (i % 2 === 1) { d *= 2; if (d > 9) d -= 9; }
    sum += d;
  }
  return sum % 10 === 0;
}

Pipeline de validación masiva (Python)

def validate_imei_batch(imei_list: list[str]) -> dict:
    KNOWN_INVALID = {"000000000000000", "111111111111111", "123456789012345"}
    results = {"valid": [], "invalid_format": [], "invalid_luhn": [], "known_bad": []}
    for raw in imei_list:
        imei = raw.replace(" ", "").replace("-", "")
        if not imei.isdigit() or len(imei) != 15:
            results["invalid_format"].append(raw)
        elif imei in KNOWN_INVALID:
            results["known_bad"].append(raw)
        elif not luhn_check(imei):
            results["invalid_luhn"].append(raw)
        else:
            results["valid"].append(imei)
    return results

Para la validación visual de IMEI individuales, utiliza la calculadora IMEI/Luhn.

Validación Luhn vs verificación IMEI completa

Esta es la distinción más importante para interiorizar: la validación Luhn es una verificación de formato, no una verificación de dispositivo.

Un IMEI válido según Luhn te indica que el número está bien formado estructuralmente. No te dice nada sobre si un dispositivo real fue fabricado con ese IMEI, si el dispositivo está en una lista negra de red, o si el TAC corresponde a un fabricante legítimo.

Tipo de verificación	Detecta	NO detecta
Algoritmo de Luhn	Errores de transcripción, formato inválido	Dispositivo real o falso, estado de lista negra
Búsqueda TAC	Reclamación de modelo incorrecta, TAC inexistente	Lista negra, bloqueo de activación
Verificación lista negra IMEI	Dispositivos reportados robados/perdidos	IMEI falsos no reportados
Consulta EIR de red	IMEI bloqueados en ese operador	IMEI bloqueados en otros operadores

Considerando la superficie de ataque: un actor malicioso suficientemente motivado puede generar un número ilimitado de IMEI válidos según Luhn eligiendo un TAC válido, añadiendo un número de serie aleatorio de 6 dígitos y calculando el dígito de control correcto. El número resultante pasará la verificación Luhn cada vez. Por eso existe la verificación de lista negra.

La verificación de lista negra IMEI va más allá de Luhn para verificar el estado de lista negra de red en bases de datos en tiempo real.

Cuándo Luhn solo es suficiente

La validación exclusiva con Luhn es apropiada cuando:

• Estás saneando la entrada del usuario en tiempo real (validación de formulario, retroalimentación del teclado móvil)
• Realizas un filtrado inicial masivo sobre una importación grande antes de consumir cuota de API
• El sistema posterior tiene su propia capa de verificación y solo necesitas evitar que entren datos claramente malformados

Cuándo se necesita el pipeline completo

La verificación completa TAC + lista negra es necesaria cuando:

• Estás comprando o aceptando un dispositivo para reventa
• Estás procesando una reclamación de seguro que involucra un dispositivo
• Estás activando un dispositivo en una red
• Estás incorporando dispositivos a una plataforma MDM/EMM y necesitas verificar que no estén reportados como robados

La arquitectura correcta es siempre: Luhn primero (gratuito, síncrono, latencia cero), luego búsqueda TAC, luego verificación de lista negra — en ese orden. Eliminas la basura obvia a coste cero antes de gastar llamadas a API en el resto.

Conclusión

El algoritmo de Luhn es la primera y más rápida capa de validación para cualquier sistema que procese números IMEI. No es un mecanismo de seguridad — es un mecanismo de calidad de datos. Una sola implementación de la función de 10 líneas anterior, desplegada en el punto de entrada, elimina la mayoría de las entradas inválidas antes de cualquier solicitud de red.

El concepto estructural que hay que retener: Luhn valida el formato de un IMEI. La búsqueda TAC valida el origen. La verificación de lista negra valida el estado. Las tres capas sirven propósitos diferentes y ninguna puede reemplazar a las otras. En un sistema de producción que procesa IMEI a escala, las tres pertenecen al pipeline.

---

¿Qué capa de validación IMEI ha detectado más problemas en tu sistema — la verificación de formato Luhn, la búsqueda TAC o la lista negra? Comparte tu experiencia en los comentarios.