Cifrado de baja energía de Bluetooth y seguridad de datos

Necesito enviar algunos datos confidenciales a través de una conexión de datos Bluetooth Low Energy (BLE) entre un teléfono inteligente (iOS y Android) y un dispositivo integrado (chip CC2540).

Dado que no considero que el código de la aplicación en los teléfonos esté a salvo de la piratería informática, necesito confiar en la seguridad de BLE para obtener mi paquete cifrado entregado desde el servidor al dispositivo una vez y una vez (debo asumir que cualquier segundo intento Para entregar el paquete, debe ser de un atacante).

He estado navegando por la red hace unos días, para averiguar si mis datos son seguros y bajo qué condiciones. Lamentablemente no he sido capaz de llegar a una respuesta sencilla a mis preguntas.

  1. ¿Mis datos son seguros si emparejo el teléfono con el dispositivo? – Supongo que si, aunque entiendo que el proceso de emparejamiento en sí es defectuoso, por lo que es teóricamente posible para algunos hombre en el medio (MITM) para oler las claves de cifrado durante el proceso de emparejamiento y así comprometer la conexión.

  2. Necesito que cada dispositivo se empareje con varios teléfonos (pero sólo se comunica uno a la vez). ¿Cuál es el número máximo de emparejamientos pr. ¿dispositivo? – desafortunadamente necesito emparejar un número bastante grande de teléfonos a mi dispositivo (s).

  3. ¿Puedo quizás conseguir los datos del emparejamiento (llaves a largo plazo etc.) del dispositivo y almacenarlo en una cierta memoria externa, para aumentar este límite.

  4. ¿Puedo hacer una conexión de datos segura al dispositivo sin emparejar, o tal vez re-emparejando cuando necesito hacerlo? – ¿Qué tan seguro es este procedimiento con respecto a los ataques MITM?

No puedo encontrar ningún documento que responda a estas preguntas sin ambigüedad. Cualquier ideas o punteros serán bienvenidos.

Aquí están mis dos centavos:

  1. AFAIK, BLE proceso de emparejamiento / cifrado no es defectuoso. Sin embargo, hay tres niveles de protección MITM disponibles con cifrado:

    • Ninguno, esto utiliza una clave conocida == 0, por lo que si un intruso captura todos sus paquetes en el proceso de emparejamiento, puede seguir su conexión cifrada.
    • Baja protección MITM, esto es cuando se utiliza una clave de entrada de entrada de usuario para emparejamiento, con clave <1.000.000. Aquí el espía sólo tendría que probar un millón de llaves.
    • Alta protección MITM, utilizando una llave fuera de banda. Esto daría una fuerza completa de 128 bits para su cifrado, y un intruso necesitaría saber la clave para seguir la conversación, incluso si captura todo el proceso de emparejamiento. Como no hay un método de intercambio de claves en BLE (aunque al menos), el punto más débil aquí sería la distribución de claves, pero ese sería el mismo problema que cuando se tiene una capa adicional de cifrado en el nivel de aplicación.
  2. Esto depende de la implementación. Su dispositivo no tiene obligación, es decir, establecer una relación permanente con el anfitrión. Si los dispositivos no se unen, no hay estado que diga acerca de conexiones anteriores (aparte de los datos intercambiados, pero que es el dominio de la aplicación, no la pila BLE). Si los dispositivos no están enlazados, tendrían que volver a emparejarse la próxima vez que se conecten para intercambiar datos protegidos. Si los dispositivos están enlazados, la conexión cifrada se puede continuar sin interacción entre la aplicación y el usuario, con el mismo nivel de seguridad que anteriormente. Para los dispositivos de conexión única, la vinculación no tiene sentido, por lo que puede tener una implementación sin estado sin restricciones en el número de dispositivos conectados. Para multiple-times-connect, también podría tener una implementación sin estado, dependiendo de cómo distribuir / almacenar la clave (s) que es independiente de BLE. La disponibilidad de las diferentes opciones aquí depende de la implementación de la pila BLE / dispositivo que está utilizando, aunque la especificación permite todo esto.

  3. Si usted enlaza y por lo tanto cambia las llaves a largo plazo etc, éstas pueden, dependiendo de la implementación de BLE que usted está construyendo encendido, ser almacenado lo que usted tiene gusto.

  4. Como dije debajo de 2., usted puede establecer una conexión segura (cifrada) sin la vinculación. Luego, los dispositivos deben volver a emparejarse la próxima vez que deseen establecer una conexión segura. Si no desea / no puede emparejar por alguna razón, entonces puede tener sólo la comunicación de texto plano.

Voy a tomar una puñalada en este.

1) Mi comprensión del proceso de emparejamiento es la misma. Si los datos fueran lo suficientemente sensibles, añadiría una capa independiente de cifrado de mi propio en mi aplicación …

2) Para las conexiones, el protocolo BLE está limitado a un host por dispositivo al mismo tiempo, incluso cuando la conexión no está vinculada / emparejada. La única manera de que un solo dispositivo establezca una conexión a más de un host al mismo tiempo es si el dispositivo de alguna manera 'pretende' ser múltiples dispositivos. Si esto se puede hacer o no será dependiente del hardware y definitivamente no es una de las maneras estándar de utilizar un dispositivo. Incluso si puede engañar al hardware para que lo haga, puede encontrarse con problemas inevitables como la ocurrencia de intervalos de conexión (casi) superpuestos, lo que puede provocar la pérdida de datos e incluso conexiones establecidas.

Otra forma de que un dispositivo se comunique con varios hosts es desconectarse regularmente y permitir que otro host establezca la conexión. AFAIK, no hay un soporte de protocolo especial para esta técnica, por lo que más allá de tal vez utilizando la publicidad dirigida puede no tener mucho control sobre qué host se conecta a continuación y cuando lo hace.

Véase también la Sección 4.1.2 del Volumen 1, Parte A de la especificación bluetooth "Core_V4.0" (por ejemplo, desde aquí https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737 )

3) Probablemente sí, los detalles variarán según el proveedor, pero con las limitaciones mencionadas anteriormente.

4) Puede establecer una conexión sin vinculación / emparejamiento. Esta conexión permitirá la comunicación, pero será de texto sin ninguna seguridad. AFAICS, la única manera de hacer esto es utilizar su propia protección de datos en el nivel de aplicación.

Supongo que el dispositivo CC2450 utiliza la pila TI. Una buena documentación sobre el comportamiento de la pila CC2540 se encuentra en la Guía del usuario del Kit de desarrollo CC2540 . Es probablemente la mejor documentación después de las especificaciones 4.0 de bluetooth.org

  1. El pin de 6 dígitos utilizado en el proceso de paring potects contra MITM – hay una ventana de 30 segundos para la entrada de PIN.

  2. La pila TI limita el número de dispositivos emparejados a 8 o menos. Es debido a la CPU y el rendimiento de cifrado / recursos necesarios para restablecer las conexiones.

  3. Desplazar las claves de cifrado del dispositivo BT es un riesgo para la seguridad. En general, la gestión de claves es el talón de Aquiles de todo el cifrado.

  4. No habrá cifrado de lectura / escritura característica sin enlace. Consulte la sección 4.6.1 de la guía del usuario de TI, de acuerdo con las especificaciones de Bluetooth 4.0.

  • ¿Qué sucede mientras se mueve la aplicación a la tarjeta SD en Android
  • ¿Cómo puedo verificar / confiar en la ubicación de un dispositivo iOS o Android desde el servidor?
  • Proveedor de seguridad de registro de Android
  • El uso de preferencias compartidas para el inicio de sesión persistente, ¿es esa vulnerabilidad?
  • ¿Cuál es la forma más segura de autorizar a un usuario en Android?
  • Hacer una aplicación de Android que no se puede desinstalar / eliminar
  • El juego de Android sigue siendo hackeado
  • ¿Dónde almacenar un token JWT?
  • ¿Existe una manera de almacenar de forma segura los datos de usuario en un dispositivo Android?
  • Android en la aplicación de facturación: proteger la clave pública de la aplicación
  • Prácticas recomendadas para registro de cuentas / cantar / autenticar en aplicaciones para dispositivos móviles
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.