El cifrado (encryption) en un sistema P25 o DMR se aplica transmisión por transmisión, por parte del radio que está hablando, lo que significa que un grupo de habla (talkgroup) es tan seguro como el peor programado de sus portátiles. Cuando un solo radio sale en claro, el audio suena exactamente igual para todos los demás en el grupo, y dependiendo de cómo estén configurados los radios receptores, o nadie se da cuenta o la unidad en claro deja de escuchar el grupo de habla sin que nadie lo note. Este artículo cubre nueve formas en que esto sucede, cómo se ve y se escucha cada una al aire, y la auditoría de registros de llamada que encontrará la mayoría de ellas en una tarde.
- El cifrado se aplica por transmisión, por parte del radio que habla
- Seleccionable, fijo, y qué hace un radio receptor con audio en claro
- Rekeys perdidos, claves muertas y el radio del cajón
- Cargas de programación y posiciones de consola
- Patches: la fuga que el despacho crea a propósito
- Cifrado que no es cifrado, y flotas que no coinciden
- La auditoría de registros de llamada
- Qué debe decir el procedimiento operativo estándar
- Qué hacer en su agencia
- Puntos clave
El cifrado se aplica por transmisión, por parte del radio que habla
Un grupo de habla (talkgroup) es una dirección. En un sistema P25 troncalizado (trunked), le indica a la infraestructura qué suscriptores deben recibir un canal y qué radios deben abrir el silenciador, y no lleva ninguna propiedad criptográfica propia, porque el núcleo del sistema conmuta una llamada en lugar de protegerla. La protección, cuando existe, se aplica dentro del radio transmisor antes de que el audio llegue al aire, y cada radio receptor debe entonces decidir qué hacer con lo que recibe. Ese único hecho arquitectónico es la razón por la cual un grupo de habla etiquetado SECURE en su mapa de flota puede transportar tráfico que cualquiera con un escáner puede escuchar.
La interfaz de aire (air interface) de P25 transporta el estado de cada transmisión dentro de la propia transmisión. El análisis de seguridad de P25 publicado en el USENIX Security Symposium en 2011 por Sandy Clark, Matt Blaze y sus coautores describe el encabezado como contenedor de un Message Indicator, que es el vector de inicialización y tiene 72 bits de ancho pero efectivamente 64, junto con un Algorithm ID de ocho bits y un Key ID de 16 bits, y señala que las transmisiones enviadas en claro fijan esos campos en todo ceros. Un radio que habla en claro sobre un grupo de habla cifrado no está haciendo nada que el protocolo considere un error, así que nada la rechaza, nada registra una excepción, y la infraestructura la transmite de la misma manera que transmite todo lo demás.
La consecuencia práctica es que la seguridad de un grupo de habla la determina el radio peor configurado que esté afiliado a él, y la falla ocurre por transmisión y no de forma permanente. El mismo portátil puede estar seguro el martes y en claro el miércoles porque un switch se movió dentro del bolsillo del equipo de protección personal, y puede estar seguro en la pulsación de un supervisor y en claro en la siguiente pulsación de la misma unidad si el operador movió algo entre una y otra. Una auditoría construida alrededor de preguntar si un radio está cifrado no va a encontrar esto, porque la versión respondible de la pregunta es qué fracción de las transmisiones de ese radio en ese grupo de habla durante los últimos treinta días salió protegida.
Lo que escucha el resto del grupo depende de su propia programación. Si los radios receptores están configurados para aceptar audio sin cifrar en ese grupo de habla, la transmisión en claro suena por el altavoz de forma idéntica a cualquier otra transmisión, y la fuga resulta invisible para las personas mejor ubicadas para detectarla. Si los radios receptores están configurados para rechazar audio sin cifrar, lo silencian, lo que significa que la unidad en claro está transmitiendo hacia un vacío y nadie en el grupo lo escucha en absoluto. Ambos resultados provienen de la misma condición subyacente, y la mayoría de las agencias con las que he tratado nunca han decidido por escrito cuál de las dos quieren.
Seleccionable, fijo, y qué hace un radio receptor con audio en claro
La guía de programación publicada por los sistemas estatales es consistente en el vocabulario aquí. Tanto el documento de mejores prácticas de cifrado del Michigan Public Safety Communications System como las guías de programación de cifrado de la Indiana Integrated Public Safety Commission describen tres estados de activación de cifrado para un grupo de habla dentro de un archivo de programación del radio (codeplug): clear (en claro), donde el cifrado está apagado y no se puede activar; selectable (seleccionable), donde el usuario puede activar y desactivar el cifrado con un switch, un botón o un menú; y strapped o secure strapped (fijo o fijo seguro), donde el grupo de habla siempre está cifrado y el usuario no puede desactivarlo. La guía de Indiana recomienda secure strapped para los grupos de habla que siempre estarán cifrados, poniendo como ejemplo los grupos tácticos, de narcóticos y SWAT, y recomienda que un grupo de habla que realmente necesite ambos modos se programe dos veces, una vez como clear strapped y otra como secure strapped, en lugar de dejarlo seleccionable.
Selectable es donde vive la transmisión accidental en claro. En las diapositivas que Matt Blaze presentó ante la Information Security and Privacy Advisory Board federal en octubre de 2012, describió los radios como típicamente configurados con un switch de dos posiciones que controla el cifrado de salida, describió ese switch como frecuentemente marcado de forma poco clara y fuera de la vista, y dijo que la selección por parte del usuario era la configuración estándar en ese momento. Si esa sigue siendo la configuración estándar en su flota es una pregunta para su propio codeplug y no para una presentación de catorce años de antigüedad, y vale la pena revisarlo grupo de habla por grupo de habla en lugar de asumirlo. Al aire, esta falla es silenciosa, porque la transmisión lleva audio normal e ID de unidad normal, y la única indicación local está en el radio de la persona que la causó.
El lado de recepción es la decisión que la mayoría de las agencias nunca tomaron deliberadamente. Un radio puede configurarse para abrir el silenciador con tráfico en claro sobre un grupo de habla seguro, en cuyo caso el grupo sigue funcionando y la exposición queda oculta, o puede configurarse para descartar el tráfico en claro en ese grupo de habla, en cuyo caso la exposición se detiene y la unidad infractora queda efectivamente fuera del aire para su tripulación. La segunda opción es una condición real de seguridad del oficial, porque un agente que transmite una ubicación o una solicitud de apoyo hacia un grupo que lo ha silenciado no tiene forma de saber que su tráfico no llega a ningún lado, salvo que nadie le responde, y la respuesta humana natural ante la falta de respuesta es repetir la transmisión en lugar de cambiar de radio.
Los nombres de estos ajustes, dónde se encuentran dentro del software de programación, y cuál es su valor predeterminado varían según el fabricante, el modelo y la versión de firmware, y no voy a afirmar un valor predeterminado para ningún proveedor aquí porque no puedo verificarlo en una flota que no puedo ver. Lo que sí puedo decir es que usted puede determinarlo en veinte minutos con dos radios, un grupo de habla de repuesto y una prueba supervisada en su propio sistema, y que la respuesta pertenece a su documentación de programación de radios en una sola oración, para que el próximo técnico no tenga que redescubrirla.
Aceptar audio en claro en un grupo de habla seguro mantiene a la tripulación hablando y oculta la fuga, mientras que rechazarlo detiene la fuga y saca del grupo a una unidad que funciona, sin avisarle. Ninguna de las dos opciones es automáticamente correcta, y la decisión le corresponde al jefe operativo y no a quien haya construido el codeplug. Escriba qué comportamiento usa su flota, por qué, y a qué grupos de habla se aplica, y luego pruébelo en un radio de repuesto para que la documentación coincida con el hardware.
Rekeys perdidos, claves muertas y el radio del cajón
Las claves de cifrado en un sistema P25 se manejan con más piezas móviles de las que la mayoría de la gente fuera del taller de radio se imagina. El estándar publicado de recarga de claves por el aire (over-the-air rekeying) del sistema estatal de Iowa describe el arreglo con claridad: una clave de cifrado de tráfico (traffic encryption key) es lo que codifica la transmisión, se almacena contra un número de identificación de clave y un número decimal de ubicación de almacenamiento, y un suscriptor que actualiza sus claves por el aire se autentica ante la instalación de gestión de claves (key management facility) usando una clave de cifrado de claves (key encryption key) única que le fue asignada, ya sea por la instalación o por un técnico de confianza usando un dispositivo de carga de claves (key fill device). Cada uno de esos elementos es algo que puede estar mal en un radio mientras está bien en los otros cuatrocientos.
La recarga de claves por el aire solo alcanza a los radios que están encendidos, afiliados y dentro de cobertura durante el proceso, razón por la cual los productos de instalación de gestión de claves anuncian capacidad de almacenar y reenviar (store and forward), como lo hace Motorola Solutions en su ficha técnica publicada para la ASTRO 25 key management facility. Los radios que se quedan afuera son previsibles: el de repuesto en la cajuela del jefe de batallón, el prestado que salió con un reservista, los radios de la caché en el remolque, y el portátil del miembro que estuvo dos semanas de vacaciones. El documento de mejores prácticas de cifrado de Michigan también señala un ajuste del codeplug al que llama retención infinita de claves (infinite key retention), y establece que si no está seleccionado, el radio pierde todas sus claves al retirar la energía, lo que convierte una batería agotada en un evento de claves en lugar de un evento de batería.
Lo que realmente hace un radio cuando no tiene una clave válida para un grupo de habla secure strapped es el comportamiento más importante de todo este artículo que no le voy a afirmar aquí, porque varía según el fabricante, el modelo y la configuración, y equivocarse en cualquiera de los dos sentidos es peor que admitir la incertidumbre. Las posibilidades incluyen negarse a transmitir, transmitir con un tono de error, silenciar el grupo de habla por completo, o en algunas configuraciones, caer de vuelta a claro. Pruébelo usted mismo con un radio de repuesto y una prueba supervisada al aire, obtenga la respuesta por escrito de su administrador de sistema o del soporte técnico de su proveedor, y escriba la respuesta en su documentación de programación con la fecha y la versión de firmware con la que se probó, porque puede cambiar con una nueva versión de firmware.
Los radios de repuesto, de caché y prestados merecen un responsable con nombre solo por esta razón. Un radio que nunca fue cargado con claves, uno que fue cargado desde un dispositivo de carga de claves con material del año pasado, y uno que fue programado desde un codeplug más antiguo con el grupo de habla dejado en claro, se van a comportar de forma diferente y van a fallar de maneras que el usuario no puede diagnosticar a las tres de la mañana. La solución es administrativa y no técnica: que la misma persona que ejecuta el rekey lo haga contra una lista de inventario que incluya todos los radios que no están en servicio diario, y que firme la lista.
Cargas de programación y posiciones de consola
Una carga de codeplug a toda la flota es la forma más eficiente de romper el cifrado de un grupo de habla, porque aplica el mismo error a todos los radios a la vez y llega con la autoridad del taller de radio detrás. Los mecanismos son ordinarios: un cambio de plantilla que revierte el atributo de cifrado de un grupo de habla a claro, una asignación de clave que no se traslada cuando un grupo de habla se copia entre zonas, un número de ubicación de almacenamiento que fue renumerado del lado del sistema pero no en la plantilla del suscriptor, o un técnico que construyó el nuevo codeplug a partir de un archivo archivado en lugar del actual. Ninguno de estos se anuncia, y el radio vuelve de la programación con una apariencia normal en la pantalla.
La única detección confiable es una prueba supervisada al aire después de la carga, antes de que los radios vuelvan a servicio. Tome dos radios del lote, colóquelos en el grupo de habla afectado, transmita, y confirme en un tercer radio y en una posición de consola que la transmisión se muestra como cifrada, luego confirme en la dirección inversa. Esa prueba toma unos cinco minutos por grupo de habla y pertenece al procedimiento de programación como un paso obligatorio con una línea de firma, y no como algo que los técnicos concienzudos hacen por su cuenta. Si su flota es lo suficientemente grande como para que las cargas salgan por lotes, la prueba se hace en el primer lote y otra vez en el último, porque los lotes no siempre se construyen a partir del mismo archivo.
Las posiciones de consola son una categoría propia porque el despacho habla más que cualquier unidad de campo y su tráfico es el más sensible del sistema, ya que lo agrega todo. Una posición de consola con la clave equivocada cargada, con el mapeo de grupo de habla equivocado, o con un ajuste de transmisión que envía en claro, va a filtrar de forma continua y va a filtrar la versión resumida de los eventos en lugar de un fragmento. La ficha técnica publicada por Motorola para la consola MCC 7500 describe el cifrado y descifrado ocurriendo dentro de cada posición del operador de despacho, y describe que la consola provee indicadores y alertas cuando el modo de la consola no coincide con el de una llamada recibida, y cuando se está armando un patch o un grupo de selección múltiple entre una mezcla de recursos en claro y seguros. Cito esto como un ejemplo de lo que una consola puede estar construida para hacer, y no como una descripción de la suya, y lo correcto es preguntarle a su proveedor de consola y a su administrador de sistema, por escrito, qué alertas tienen realmente sus posiciones, si están habilitadas, y dónde se muestran.
La alerta de consola tiene un segundo modo de falla que no tiene nada que ver con el software, que es que una alerta que aparece en la esquina de una pantalla en una posición ocupada durante el cambio de turno es una alerta sobre la que nadie actúa. Si su consola sí levanta una indicación de discordancia, el supervisor de turno necesita saber cómo se ve, qué significa y qué hacer al respecto, y esa instrucción cabe en un boletín de entrenamiento y cinco minutos de una reunión de turno que usted ya realiza.
Patches: la fuga que el despacho crea a propósito
Enlazar (patch) un grupo de habla cifrado con uno en claro mueve el audio, y el audio que sale de un patch por un recurso en claro queda en claro sin importar cómo haya llegado, porque el patch conecta la conversación y no la protección. La ayuda mutua es donde esto sucede, ya que el socio de ayuda mutua está en un sistema distinto o carece de la clave, y el despachador que resuelve el problema inmediato de dos agencias que no pueden escucharse está haciendo exactamente para lo que se compró la consola. La exposición no es tanto un error del despachador como la ausencia de una regla que le diga qué recursos pueden enlazarse y quién lo autoriza.
La guía de patching publicada por el Iowa Statewide Interoperable Communications System Board deja explícito el problema de visibilidad. Describe un enlace por software (soft patch) como uno iniciado desde la consola de despacho y manejado dentro del núcleo del sistema troncalizado y el canal de control del sitio, sin requerir hardware adicional, y establece que no requiere ningún cambio en la operación de las unidades en el campo y se realiza sin ningún aviso a los usuarios. Un enlace físico (hard patch), en el mismo documento, es uno construido con equipo físico de puerta de enlace (gateway) y radios de suscriptor, usado para conectar sistemas de radio diferentes, y que un técnico de la unidad de comunicaciones puede armar en un incidente. En ambos casos, el usuario de campo escucha su propio grupo de habla funcionando con normalidad y no tiene indicación de que su tráfico también va hacia otro lado.
La política sobre patches es corta y es exigible. Nombre los roles autorizados para crear un patch que involucre un recurso cifrado, que normalmente es un supervisor de despacho o un líder de la unidad de comunicaciones en un incidente, y no cualquier posición del piso. Exija que la creación de un patch mixto de claro y seguro se anuncie en el grupo de habla cifrado, para que los usuarios en él sepan que su tráfico está saliendo del grupo, que es el único paso de este artículo sobre el que el personal de campo puede actuar por sí mismo. Exija que los patches queden registrados con la hora, los recursos, quien lo solicitó y quien lo autorizó, y que cada patch tenga una condición de desmontaje declarada, porque el patch que nadie se acuerda de deshacer es el que sigue funcionando cuando el canal táctico vuelve al uso rutinario.
La guía de programación de Indiana aborda el problema desde el otro lado y recomienda no cifrar en absoluto los grupos de habla que se usan para interoperabilidad, algo que vale la pena considerar antes de recurrir al patch como respuesta permanente. Si existe un grupo de habla táctico regional para que cuatro agencias trabajen juntas, cifrarlo y luego enlazar alrededor de las agencias que carecen de la clave produce menos seguridad que dejarlo en claro y disciplinar lo que se dice en él, y produce ese resultado mientras todos los involucrados creen lo contrario.
Las agencias escriben procedimientos de patch que cubren cómo armarlo y no dicen nada sobre cómo termina. Todo patch que involucre un recurso cifrado necesita una condición de desmontaje declarada y registrada al momento de crearse, ya sea el fin del incidente, el fin del turno o una hora específica, y un supervisor responsable de verificarla. Un patch que queda activo después del incidente lleva tráfico sensible rutinario hacia un recurso en claro durante horas, y no va a aparecer como una llamada en claro en su auditoría porque las transmisiones en sí estaban cifradas.
Cifrado que no es cifrado, y flotas que no coinciden
Algunas agencias que auditen esto van a encontrar que la respuesta a si su cifrado está activado es que nunca tuvieron ninguno. El modo Basic Privacy de DMR es un aleatorizador (scrambler) y no un cifrador (cipher), y las descripciones técnicas al respecto son poco favorables: la documentación del decodificador de Wavecom describe el modo básico como el uso de un scrambler, lo llama simple y débil, y señala que el mismo texto plano siempre produce el mismo texto cifrado, que es la propiedad que lo hace analizable. El resumen del Crypto Museum sobre DMR establece que, por defecto, DMR no es seguro y que la escucha no autorizada es más compleja que con FM analógica en lugar de estar impedida, ya que existen receptores comerciales capaces de decodificar un flujo DMR. La inversión de voz analógica pertenece a la misma categoría desde hace décadas, ya que invertir el espectro de audio hace que el habla sea ininteligible para un oyente casual y reversible para cualquiera que quiera revertirla.
La respuesta a nivel de estándares sobre P25 es inequívoca. La Office for Interoperability and Compatibility del Department of Homeland Security, en su declaración publicada de los requisitos de cifrado para la evaluación de cumplimiento de P25, establece que el algoritmo de cifrado estándar de P25 es AES 256 y que el documento TIA-102.AAAD-B Block Encryption Protocol, publicado originalmente en julio de 2002, define AES 256 para P25. L3Harris hace el mismo señalamiento en su documento técnico publicado sobre cifrado P25, describiendo AES-256 como el cifrado estándar para las comunicaciones de voz de P25 y el único algoritmo aprobado para comunicaciones federales sensibles pero no clasificadas, y nombra las dos preocupaciones con el cifrado no AES como una falsa sensación de seguridad y una pérdida de interoperabilidad entre agencias. La guía de usuario publicada del sistema estatal de Tennessee exige AES-256 para el cifrado interoperable en ese sistema y establece que el uso de ADP queda a discreción de la agencia socia, pero no cumple con las mejores prácticas ni con los estándares federales.
Las flotas mixtas en proveedor y en generación fallan en la capa del algoritmo mucho antes de siquiera llegar a las claves. El documento de DHS establece el requisito en una línea: todo radio dentro de un grupo debe usar el mismo algoritmo de cifrado y la misma clave, y aunque las claves coincidentes se pueden cargar en las unidades de suscriptor de forma sencilla, el mismo algoritmo debe estar presente en cada unidad antes de que se pueda cargar clave alguna. Una agencia que compró portátiles capaces de AES para el equipo táctico y dejó DES o un algoritmo propietario del fabricante en los móviles más antiguos, tiene un grupo de habla que ninguna cantidad de gestión de claves puede volver uniformemente seguro, y el síntoma en el campo es un subconjunto de unidades que no puede escuchar a otro subconjunto de unidades por razones que parecen de cobertura.
DMR no tiene un único algoritmo obligatorio para seguridad pública como sí lo tiene P25, y lo que soportan sus radios DMR va desde basic privacy, pasando por esquemas propietarios del fabricante, hasta AES, dependiendo del fabricante, el modelo y lo que se haya licenciado en él. Antes de afirmar que su flota DMR está cifrada bajo un estándar de seguridad pública, obtenga por escrito de su proveedor el algoritmo específico y la longitud de clave para cada modelo que posee, y verifíquelo contra la documentación actual de la DMR Association y del fabricante, y no contra una ficha técnica del año en que los compró.
La auditoría de registros de llamada
Todo lo anterior es detectable, y el método de detección más útil no cuesta nada más que una tarde del tiempo de alguien. El estado del cifrado viaja con cada transmisión, lo que significa que un sistema troncalizado que registra eventos de llamada tiene, en principio, un registro de si cada transmisión individual en cada grupo de habla estuvo protegida o en claro, junto con el ID del radio que la envió y la hora en que ocurrió. Extraiga un mes de registros detallados de llamada (call detail records) para sus grupos de habla seguros y cuente las transmisiones que salieron en claro. Si el número es cero, usted ha documentado que su cifrado está activado, algo que puede entregarle a un jefe que lo haya preguntado. Si no es cero, los mismos registros le dicen qué radios lo hicieron, cuándo y con qué frecuencia, y esa lista es su orden de trabajo.
Si su sistema en particular expone ese campo en sus herramientas de reportes, cómo se llama, y por cuánto tiempo se conservan los registros son preguntas para su administrador o gerente de sistema y no para mí, y varían según el fabricante y la versión del sistema. Pregunte específicamente si el registro de evento de llamada incluye un indicador de cifrado o de protegido por llamada, pregunte cuál es el período de retención, y pregunte quién tiene los derechos de cuenta para correr el reporte, porque en un sistema regional o estatal compartido, la respuesta suele ser que el gerente de radio del condado puede obtenerlo pero nunca lo ha pedido. Si usted está en un sistema alojado o compartido, la solicitud puede necesitar pasar por el organismo de gobernanza del sistema, y vale la pena hacer esa solicitud por escrito para que quede constancia de la respuesta.
Lea los resultados con cuidado, porque el conteo bruto sobreestima y subestima de maneras predecibles. Los grupos de habla programados dos veces, una vez como clear strapped y otra como secure strapped, según el patrón que recomienda Indiana, van a mostrar llamadas en claro que son completamente correctas. Las transmisiones de prueba del taller de radio, los anuncios de consola y las unidades de ayuda mutua que operan bajo una excepción documentada aparecen de la misma manera. Ordenar por ID de radio en lugar de leer cronológicamente es lo que hace útil el reporte, ya que una falla de configuración genuina se concentra en un puñado de IDs de unidad que generan tráfico en claro de forma consistente, mientras que un movimiento accidental de switch aparece como una o dos llamadas de un radio que por lo demás está limpio. Atienda primero las concentradas, retire esos radios, y revise el estado de cifrado del grupo de habla en el codeplug, las claves realmente cargadas, la fecha de la última programación y la fecha del último rekey.
Los sistemas convencionales no le ofrecen esto, ya que no hay un controlador que escriba eventos de llamada, y el sustituto es la escucha monitoreada periódica de sus propios grupos de habla por una persona autorizada, más lo que capture su grabador de registro (logging recorder). Pregúntele a su proveedor del grabador si el estado de cifrado de cada transmisión se captura como metadato de la grabación, porque una transmisión en claro que fue descifrada en la consola y una transmisión en claro que nunca estuvo cifrada suenan idénticas en el archivo, y la diferencia solo vive en el metadato, si es que vive en algún lado. Esto se aplica únicamente a su propio sistema y su propio tráfico, y nada de esto se extiende a monitorear las comunicaciones de otra agencia.
Vale la pena hacer la auditoría con una periodicidad y no una sola vez, y mensual es una cadencia razonable para la mayoría de las agencias, porque es lo suficientemente corta como para que una mala carga de codeplug se detecte en cuestión de semanas y no después de que alguien fuera de la agencia se dé cuenta. El producto terminado es un número dentro de una agenda que ya existe, que es el conteo de transmisiones en claro sobre grupos de habla seguros del mes, con los IDs de radio anexados, reportado a la reunión permanente que ya revisa temas de comunicaciones. Nadie necesita un comité nuevo para esto, y un rubro que ha marcado cero durante seis meses y de repente deja de hacerlo es la señal que este proceso fue construido para detectar.
Los radios muestran una indicación de seguro en la pantalla, y muchos se pueden configurar para dar un tono de advertencia en una transmisión en claro. La presentación de Blaze en 2012 ante la Information Security and Privacy Advisory Board federal señaló que el ícono de pantalla y el LED suelen quedar fuera del campo de visión del operador cuando se usa un micrófono de bocina o un auricular, y que el pitido de advertencia configurable para transmisiones en claro en los radios que su equipo examinó era el mismo pitido usado para otras condiciones. En mi experiencia, los usuarios dejan de registrar ambos dentro de más o menos una semana de recibir un radio nuevo, razón por la cual el ícono es un tema de entrenamiento y la auditoría de registros de llamada es el control real.
Qué debe decir el procedimiento operativo estándar
Empiece por lo que hace un miembro cuando ocurre una transmisión en claro en un grupo de habla seguro, ya que ese es el momento en que la política realmente se usa. El SOP (procedimiento operativo estándar) debe decir que la persona que la escucha anuncia la condición en el grupo de habla en lenguaje sencillo, que el contenido sensible se detiene de inmediato y pasa a un recurso conocido como seguro o a teléfono, que el tráfico ya enviado se trata como comprometido para efectos de la operación que esté en curso, y que se notifica a un supervisor durante el turno y no al final de este. El radio del que se sospecha que transmitió en claro sale de servicio hacia el taller de radio, y alguien anota el ID de unidad, el grupo de habla y la hora, para que el taller esté resolviendo un evento específico y no un rumor.
La gestión de claves necesita un responsable con nombre, no un departamento. El documento de mejores prácticas operativas de CISA y SAFECOM sobre gestión de claves de cifrado, publicado en agosto de 2020, describe un ejemplo de un servicio de EMS de condado en el cual la gestión de claves fue asignada al departamento del sheriff, que determina qué claves se van a usar y fija el calendario de recarga de claves por el aire para todos los radios del sistema, y esa concentración de autoridad es el punto del ejemplo. Quien ocupe ese rol en su sistema es dueño del inventario de claves, de las asignaciones de números de ubicación de almacenamiento, del calendario de rekey y de la autoridad para decirle que no a una agencia socia que quiera una clave. El mismo cuerpo de guía de CISA recomienda adoptar un plan estandarizado de números de ubicación de almacenamiento para reducir conflictos, lo cual importa más para las agencias que comparten claves entre jurisdicciones.
Sobre el calendario de rekey en sí, la respuesta honesta es que el intervalo tiene que salir de lo que su sistema soporta y de lo que su organismo de gobernanza haya adoptado, y no voy a publicar un número como si algún estándar lo especificara. Lo que la guía de los fabricantes y la guía federal enfatizan consistentemente es la rotación en lugar de claves estáticas, y la capacidad de respuesta ante radios perdidos o robados, algo que la presentación de Tait ante APCO sobre gestión de cifrado P25 enumera junto con las actualizaciones programadas de claves como un beneficio de contar con una instalación de gestión de claves funcional. El rekey motivado por un compromiso de seguridad es el que importa operativamente, así que su SOP necesita una persona designada, localizable a toda hora, que pueda ordenar la inhabilitación de un radio y el cambio de una clave cuando un portátil desaparece, y necesita el tiempo objetivo para hacerlo por escrito.
El resto de la política es corto. Los radios de repuesto, de caché y prestados se cargan con claves en el mismo ciclo que los radios en servicio, contra un inventario escrito, y la persona que firma la salida de un radio firma que se verificó como seguro en los grupos de habla que va a usar. Los patches de interoperabilidad que involucran un recurso cifrado solo pueden ser creados por roles nombrados, se anuncian en el grupo de habla cifrado, quedan registrados, y llevan una condición de desmontaje. Los registros detallados de llamada de los grupos de habla seguros se auditan con una cadencia declarada por un rol nombrado, y el resultado va a una reunión permanente. Cada una de esas oraciones cabe dentro de un SOP de comunicaciones que usted ya tiene, y ninguna requiere comprar nada.
Qué hacer en su agencia
- Pida a su gerente de radio o administrador de sistema que corra un reporte de registros detallados de llamada de los últimos treinta días para cada grupo de habla que su agencia considere seguro, filtrado por transmisiones en claro, y que lleve el conteo y la lista de IDs de radio a la próxima reunión de comunicaciones u operaciones que ya esté en el calendario.
- Pregúntele por escrito a su administrador de sistema, este mes, si los registros de evento de llamada de su sistema incluyen un indicador de cifrado por llamada, cuánto tiempo se conservan esos registros, y cuál de su personal tiene los derechos de cuenta para correr el reporte, y archive la respuesta junto con su SOP de comunicaciones.
- Tome un radio de repuesto y uno en servicio y corra una prueba supervisada en un grupo de habla sensible que establezca tres cosas: si el grupo de habla está fijo (strapped) o es seleccionable, qué hace un radio receptor con una transmisión en claro en él, y qué hace un radio sin clave válida cuando intenta transmitir, y luego escriba los resultados y la versión de firmware en su documentación de programación.
- Agregue un paso obligatorio de verificación posterior a la programación, con una línea de firma, a su procedimiento de codeplug, de modo que ningún lote de radios vuelva a servicio después de una carga o un rekey hasta que dos de ellos hayan transmitido en el grupo de habla seguro afectado y hayan sido confirmados como cifrados por un tercer radio y una posición de consola.
- Pida al supervisor de despacho que confirme con su proveedor de consola qué alertas de discordancia entre claro y seguro tienen realmente las posiciones, si están activadas, y dónde aparecen en la pantalla, y luego instruya a los telecomunicadores sobre cómo se ve esa indicación y a quién se lo deben avisar.
- Escriba la regla de patches en el SOP de despacho este mes: nombre los roles que pueden crear un patch que involucre un recurso cifrado, exija que el patch se anuncie en el grupo de habla cifrado, exija que quede registrado, y exija una condición de desmontaje registrada al momento de crearlo.
- Pida a quien esté a cargo del inventario de su caché de radios que revise cada radio de repuesto, de caché y prestado contra el inventario de claves, que cargue con claves los que se hayan quedado fuera del último rekey, y que reporte el número de radios encontrados sin claves a la misma reunión que recibe el resultado de la auditoría.
Puntos clave
- El cifrado en P25 y DMR lo aplica el radio transmisor en cada transmisión, así que un grupo de habla es tan seguro como el radio peor programado que esté afiliado a él, y la infraestructura no va a rechazar ni marcar una transmisión en claro sobre un grupo de habla seguro.
- El artículo de USENIX Security de 2011, de Sandy Clark, Matt Blaze y sus coautores, reportó que tráfico sensible de aplicación de la ley federal, capturado durante dos años en varias áreas metropolitanas de Estados Unidos, se enviaba de forma rutinaria en claro pese a que los usuarios aparentemente creían que estaba cifrado, lo cual documenta que esta falla es real y no teórica.
- Los grupos de habla dentro de un codeplug son clear, selectable o secure strapped, y la guía estatal publicada de Indiana recomienda dejar fijos y seguros los grupos de habla sensibles, y programar un grupo de habla dos veces, una en claro y otra en seguro, cuando realmente necesita ambos modos.
- Que un radio receptor reproduzca o silencie el audio en claro sobre un grupo de habla seguro es una decisión de política con una consecuencia de seguridad del oficial en cualquiera de los dos sentidos; los nombres y valores predeterminados varían según el proveedor y la configuración, y el comportamiento de su flota se debe probar y documentar en lugar de asumirse.
- Lo que hace un radio sin una clave válida varía tanto según el proveedor y la configuración que debe probarse en su propio equipo y confirmarse con su proveedor, y la guía publicada de Michigan señala que sin seleccionar la retención infinita de claves, un radio pierde sus claves al retirar la energía.
- Las cargas de codeplug, las posiciones de consola y los patches de consola filtran cada uno sin ninguna indicación para el usuario de campo, y la guía estatal de patching de Iowa establece directamente que un enlace por software se crea sin ningún aviso a los usuarios cuyo tráfico mueve.
- La basic privacy de DMR es un aleatorizador y la inversión de voz analógica no es cifrado, mientras que la Office for Interoperability and Compatibility de DHS establece que el algoritmo de cifrado estándar de P25 es AES 256 según se define en TIA-102.AAAD-B, y todo radio dentro de un grupo debe llevar el mismo algoritmo antes de que se pueda cargar clave alguna.
- El control más útil por sí solo es un conteo mensual de transmisiones en claro sobre grupos de habla seguros, extraído de los registros detallados de llamada, ordenado por ID de radio y reportado a una reunión que ya existe, porque los íconos y tonos de advertencia del radio dejan de ser percibidos por los usuarios en cuestión de más o menos una semana.
Escríbame a través de la página de contacto. Leo todos los mensajes.
