🔒 Seguridad y privacidad

Protocolo P2P - qué se transmite y qué no

CacheEX y seguridad

CacheEX permite que peers intercambien entradas de caché CW proactivamente. Dentro de una red de peers de confianza (misma persona u organización), esto es seguro porque todos los paquetes están cifrados con la clave de sesión ChaCha20-Poly1305.

Anti-fingerprinting y Anti-DPI

• Jitter estocástico: los paquetes CMD_CARD_MAP se retrasan 50–300ms aleatorios para romper correlación temporal DPI.
• Padding aleatorio: proto_send_packet añade bytes de padding para que todos los paquetes tengan tamaño variable, imposibilitando identificar el tipo por longitud.
• Ghost UA: bytes hex configurables que imitan el patrón de otro softcam conocido.
• Silent Mode: cuando activo, no se escribe nada en consola. Los logs van solo a fichero.
• NodeID: hash de 64 bits aleatorio, regenerable desde WebIf.
• CTC (Candela Transport Camouflage): framing TLS 1.3 Application Data - para el ISP es tráfico HTTPS estándar. Implementado en R34.
• CPM (Adaptive Pulse Masking): chaff cifrado continuo cada 2–3.5s - entierra el patrón silencio/ráfaga del criptoperíodo DVB. Implementado en R35.
• TAR - Anti-DPI Suite (R37): PSN (normalización de tamaño a buckets fijos), ETJ (jitter temporal en ECMs), CTF (tráfico de fondo constante), TCR (rotación de sesión TCP). Cobertura: 100% ante DPI en tiempo real, análisis estadístico, autocorrelación temporal y metadatos de duración de sesión.

¿Puede la operadora detectar el uso de Candela?

Hay que distinguir dos capas de amenaza con vectores y soluciones completamente distintos:

Capa 1 - ISP / red: el ISP ve paquetes cifrados circulando entre nodos. Hasta R36, un DPI avanzado podía identificar cardsharing por el perfil de tráfico (tamaño de paquetes, patrón temporal, silencios, duración de sesión). Con CTC + CPM + TAR (PSN+ETJ+CTF+TCR) activos, el tráfico es indistinguible de HTTPS estándar ante DPI en tiempo real, análisis estadístico, autocorrelación temporal y metadatos de sesión. Cobertura en esta capa: 100%. El ISP no puede detectar ni bloquear selectivamente el tráfico P2P de Candela.

Capa 2 - Sistema CA de la operadora: si hay tarjeta física local, la operadora procesa internamente cada ECM que llega a esa tarjeta en su propio backend de acceso condicional. Este canal es independiente de la red y no está expuesto al ISP - no hay ningún paquete que camuflar porque la operadora es el destino legítimo. Si una tarjeta sirve muchos canales simultáneos, el volumen de ECMs en el sistema CA de la operadora es mayor que el de un suscriptor normal. Candela implementa ECM ratelimit y caché CW para mantener la tasa dentro de rangos plausibles. En modo puro P2P sin tarjeta local, esta capa no aplica - la operadora no tiene visibilidad directa.

🏗 Arquitectura interna

Flujo de una ECM de extremo a extremo

📊 Pestaña Panel (Dashboard)

Vista general del estado del sistema en tiempo real. Se actualiza cada 2 segundos mediante polling diferencial - solo actualiza la sección visible.

Barra de métricas

Barra compacta flex-wrap con widgets de estado:

Módulos (pills)

Indicadores verdes/rojos del estado de cada módulo: DVBAPI, SoftCam, StreamRelay, ACF. Verde = activo y funciónando.

Panel lateral de seguridad (campana 🔔)

El icono de campana en la barra de navegación abre un panel lateral deslizante con cuatro pestañas independientes, cada una con su propio scroll:

Clientes Conectados

Lista de peers que se han conectado a este Candela como clientes (consumen CWs). Por cada cliente se muestra: IP/usuario, tarjetas anunciadas, canal visionando, ECMs envíadas, latencia y flags activos.

Servidores Upstream

Peers a los que este Candela se conecta como cliente para pedir CWs. Muestra tarjetas anunciadas, CWs resueltas OK y latencia HLS media.

📡 Pestaña Monitor

Diagnóstico operativo en tiempo real. Muestra lo que está pasando ahora mismo en el sistema - a diferencia de Forense ACF que es para análisis histórico o dirigido.

Latencia ECM en tiempo real

Gráfico Chart.js actualizado cada 2 segundos con la latencia media de las últimas ECMs resueltas. Permite detectar degradación de rendimiento de peers upstream o saturación de la red.

Demuxes DVBAPI activos

Tabla de los demuxes que el receptor DVB tiene abiertos en este momento. Por cada demux:

Live CW Inspector

Visor en tiempo real de las CWs activas entregadas a cada demux. Muestra canal, CAID:SRVID, CW even/odd en hex, peer de origen, latencia y hop. Útil para verificar que las CWs llegan correctamente antes de que el receptor las aplique.

Actividad Interna (canales FTA)

Demuxes cuya PMT no contiene descriptores CA (sin acceso condicional). Candela los registra con CAID 0xFFFE y los muestra en la tabla igual que el resto, pero sin latencia ECM ni peer asignado. Su entrada persiste 300 segundos sin actividad (frente a 60s para canales cifrados) porque los FTA no generan ECMs periodicas.

Rastro de Origen (caché)

Para cada CW entregada, muestra su origen: caché RAM, ECM DB en disco, peer upstream, lector local (Hop 0) o SoftCam emulador. Permite identificar qué fuente está resolviendo cada canal en tiempo real.

Duración de sesión y clientes históricos

Tabla de clientes P2P conectados con tiempo de sesión activo y estadísticas acumuladas desde el arranque: ECMs servidas, CWs entregadas, FakeCWs rechazadas. Los clientes históricos (ya desconectados) se conservan en memoria hasta reiniciar.

Árbol de Saltos por Canal

Visualización del grafo de peers para cada CAID:SRVID: qué peer resuelve qué canal, en cuántos saltos, con qué latencia media. Permite identificar cuellos de botella en la topología P2P y optimizar la distribución de peers.

ECM Inspector

¿Por qué está en Monitor y no en Forense?

El ECM Inspector loguea automáticamente cada ECM: su hash, CAID:SRVID, el peer que la resolvió, la latencia y si la CW resultante fue aceptada, rechazada por FakeCW, pendiente de DoubleCheck o resuelta desde caché. Implementado con tommy_hashlin O(1) desde R32 - sin impacto de rendimiento aunque haya 1024 ECMs pendientes.

🔍 Pestaña Diagnóstico ECM

Vista centralizada del estado de descifrado canal por canal. Responde a la pregunta "¿por qué este canal no abre?" sin necesidad de revisar logs ni ficheros de configuración. A diferencia del Monitor (que muestra el flujo operativo en tiempo real), Diagnóstico ECM acumula histórico y expone la causa raíz automáticamente por cada canal.

Vista unificada de canales activos

Tabla con todos los canales que el receptor DVB ha envíado al daemon, independientemente de si están cifrados o no. Cruza los datos del DVBAPI (demux activo) con el histórico de peticiónes ECM para ofrecer una visión completa:

API: GET /api/diag/channels. Los canales FTA persisten en la tabla el mismo tiempo que los cifrados; ambos se limpian si el demux cierra.

Carga de lectores locales

Panel que muestra, para cada lector de tarjeta físico o emulador configurado, cuántos SRVIDs (canales) tiene activos en este momento y el porcentaje de uso respecto al límite max_parallel configurado. La barra de uso se pone en rojo al superar el 80%.

Si MCRR está activo, el desglose muestra qué canal está asignado a cada reader. Si un reader está al 100% de uso y hay ECMs en estado reader_ocupado, esta vista identifica el cuello de botella de forma inmediata.

API: GET /api/diag/readers.

Modo preview y sugerencias de reglas

Cuando el modo preview está activo (diag_preview_mode=1), el daemon acumula resultados por CAID:PROVID:SRVID y clasifica automáticamente cada canal:

• P: CAID:PROVID SRVID — canal que siempre resuelve en local o en caché. Candidato a regla ALLOW en candela.prio para asegurarse de que siempre se prioriza localmente.
• I: CAID:PROVID SRVID — canal sistemáticamente denegado o sin lector. Candidato a regla SKIP para descartarlo y no malgastar peticiónes ECM.
• revisar — canal inestable con resultados mixtos. Requiere revisión manual antes de crear una regla.

Las sugerencias se muestran en una tabla con botónes ALLOW y SKIP por fila. Al pulsar cualquiera de ellos la regla se añade directamente a candela.prio y entra en vigor sin reiniciar. El modo preview no modifica ningúna regla por sí solo: todo es opt-in.

APIs: GET /api/diag/suggestions para obtener la lista, POST /api/diag/suggestions/reset para limpiar el histórico acumulado.

Panel de reglas candela.prio

Vista y gestión directa del fichero candela.prio sin salir de la pestaña Diagnóstico:

• Tabla de reglas activas: tipo (ALLOW en verde, SKIP en rojo), CAID, PROVID, SRVID y comentario. Botón de eliminación por fila con efecto inmediato en memoria y en disco.
• Formulario de alta: tipo, CAID (hex), PROVID (hex), SRVID opcional y comentario libre. Al guardar la regla entra en vigor al instante.
• Aplicar sugerencias: los botónes ALLOW/SKIP de la tabla de sugerencias crean la regla correspondiente con un solo clic, sin copiar valores manualmente.

El fichero también puede editarse como texto plano desde la pestaña Editor, donde está disponible el editor de candela.prio junto al resto de ficheros de configuración.

APIs: GET /api/diag/prio (lista JSON de reglas), POST /api/diag/prio/add, POST /api/diag/prio/remove, GET /api/diag/prio/raw, POST /api/diag/prio/raw.

Estado CW y ECM PID por canal

Card que muestra, para cada canal cifrado activo, los siguientes datos en tiempo real:

API: GET /api/diag/cw_state. Los datos se obtienen cruzando el contexto de demux activo (ecm_pid) con el historial de CW del ciclo de verificación.

Actividad EMM por CAID

Las EMMs (Entitlement Management Messages) son los mensajes que el canal emite para gestionar suscripciones y renovar derechos en las tarjetas. Esta card muestra, agrupado por CAID:

API: GET /api/diag/emm_stats.

Sparklines de latencia por reader

Cada lector (NewCamd cliente, MGcamd cliente y hardware físico) almacena un ring buffer de las últimas 20 latencias medidas en cada ECM resuelta con éxito. La pestaña Diagnóstico muestra una mini-gráfica SVG por reader donde:

• El eje Y representa la latencia en ms (escala automática al rango de valores del reader).
• El color de la línea es verde (<200ms), naranja (200-500ms) o rojo (>500ms) según la media EMA actual.
• Un reader sin datos previos aparece con historial de ceros hasta acumular al menos una medición.

API: GET /api/diag/reader_latency. Devuelve un array con todos los readers conectados (tipo nc/mg/hw), su CAID, latencia media EMA y el array de historial de 20 posiciones.

Hit rate de resolución ECM

Barras proporcionales con el porcentaje de ECMs resueltas por cada vía desde el arranque del daemon: caché, lector local, red P2P, lector ocupado y denegadas. Útil para ajustar la configuración de ecm_multipath, el tamaño del caché o el número de peers activos.

API: GET /api/diag/stats. Devuelve: total, cache, local, net, busy, deny con sus respectivos porcentajes *_pct.

Eventos del sistema

Ring buffer de 200 eventos con timestamp, tipo e icono. Solo eventos relevantes para el usuario, sin ruido del log técnico:

• Canal con denegaciones acumuladas (cada 10): SID y contador.
• Lector saturado (cada 5 busy del mismo SID): identificación del cuello de botella.
• Peer conectado / desconectado: usuario e IP del peer.
• CW inválida rechazada (FakeCW detectada).

Los eventos se muestran en orden cronológico inverso (el más reciente primero) con color por tipo. API: GET /api/diag/events.

Coste en RAM: ~20 KB fijos (200 entradas × 100 bytes). Sin hilos adicionales ni polling interno.

⚙ Pestaña CSA

Control del motor de descifrado y todos los parámetros de CW/ECM/EMM. Los cambios se aplican en caliente pulsando "Aplicar Configuración CSA".

Módulos CSA

DVBAPI & StreamRelay

Control de CW y ECM

Control ECM / CW / EMM Avanzado

Parámetros numéricos

MultiPID - Descifrado paralelo de todos los CA PIDs

Toggle multipid_mode en la pestaña CSA. Por defecto desactivado (comportamiento clásico: primer CA descriptor de la PMT).

Cuando está activo, Candela parsea todos los descriptores CA de la PMT (hasta 8) y lanza ECMs en paralelo a todos los sistemas CA. La primera CW válida se entrega al receptor. Los demás intentos se descartan en cuanto llega la primera respuesta.

Útil en canales con múltiples sistemas CA simultáneos, como plataformas cable/IPTV que emiten tanto Viaccess como Nagra en el mismo múltiplex. Si el sistema prioritario no tiene lector ni peer disponible, el secundario resuelve el canal automáticamente sin intervención del usuario.

QuickECM - Timeout de respuesta ECM por CAID

Tabla configurable en la pestaña CSA. Por defecto vacía: todos los CAIDs usan el timeout global/adaptativo (ETO + client_timeout).

Permite definir por CAID:

• Intervalo ECM (ms): período esperado entre ECMs del canal. Informativo para el watchdog.
• Timeout (ms): tiempo máximo de espera de CW para ese CAID. Si se alcanza, la ECM pendiente expira y se puede reintentar. Sobreescribe el timeout adaptativo para ese CAID específico.

0 en cualquier campo = usar comportamiento actual sin modificar. Útil para operadores con ciclo ECM muy rápido (<2s) o muy lento (>15s) que provocan timeouts prematuros o esperas innecesarias.

AES-128 IPTV - Descifrado de streams IPTV y OTT

El motor CSA de Candela ya soporta DVB-CISSA (AES-128-CBC con IV derivado del TS), AES-ECB, AES-CTR y auto-detección por sync byte. El módulo AES IPTV añade la capa de configuración de claves estáticas y el fetcher HTTP/HTTPS para el caso de uso IPTV.

Fichero candela.aeskeys

Formato de una línea por canal:

Comportamiento si no hay clave

Si un canal no tiene entrada en candela.aeskeys, Candela lo trata exactamente como antes: solicita la ECM por la red P2P, el lector local o NewCamd/MGcamd. El módulo AES IPTV es una capa adicional, no un reemplazo del pipeline ECM.

Panel WebIF

La pestaña CSA incluye un panel de claves AES IPTV que muestra las entradas cargadas desde candela.aeskeys: SRVID, modo (static/url), algoritmo, estado de la clave (lista/pendiente) y URL si aplica. Un botón "Recargar fichero" recarga candela.aeskeys sin reiniciar el daemon. El endpoint es GET /api/config/aeskeys y POST /api/config/aeskeys/reload.

📸 Proxy IPTV multicast/unicast

Candela incluye un proxy HTTP compatible con la API de udpxy directamente en el daemon. Elimina la dependencia del proceso externo udpxy sin necesitar cambios en la configuración del STB.

Activación

En la pestaña CSA del WebIF, activa Proxy IPTV multicast/unicast y configura el puerto (por defecto 8088). O en candela.json:

"enable_iptv_proxy": 1,
"iptv_proxy_port": 8088

Formatos de URL soportados

Ejemplo de bouquet IPTV

Si el STB tiene en su lista de canales:

udp://@239.0.5.185:8208

Configura el STB para usar Candela como proxy udpxy y el STB pedirá:

http://ip_candela:8088/udp/239.0.5.185:8208

Candela une al grupo multicast, aplica descifrado AES-128 si hay clave en candela.aeskeys para ese stream, y reenvía el TS al STB.

Descifrado AES en proxy IPTV

Si existe una entrada en candela.aeskeys con el SRVID del stream, los paquetes TS se descifran antes de enviarse. No requiere configuración adicional - el descifrado es completamente transparente para el STB.

Estadísticas

Endpoint GET /api/iptv/streams. Campos por stream: grupo multicast, IP del cliente, nombre del canal, bytes enviados, bitrate en bytes/s y estado AES. La card de actividad IPTV/HLS aparece en el monitor del WebIF cuando hay streams activos.

🎥 Proxy HLS AES-128-CBC

Candela actúa como proxy entre el player y el servidor de streaming HLS. Los segmentos cifrados con AES-128-CBC se descifran en vuelo; el player recibe TS limpio sin necesitar soporte de descifrado propio.

Activación

En la pestaña CSA del WebIF, activa Proxy HLS AES-128-CBC y configura el puerto (por defecto 8089). O en candela.json:

"enable_hls_proxy": 1,
"hls_proxy_port": 8089

Cómo usarlo

Sustituye la URL del stream en el player:

Candela descarga el manifiesto m3u8, reescribe las URLs de los segmentos para que pasen por el proxy con el IV correcto embebido, y descifra cada segmento antes de servirlo.

Gestión de claves AES

Candela busca la clave en este orden:

1. En la caché de claves en memoria (por sesión, evita re-búsquedas)
2. En candela.aeskeys por SRVID derivado de la URL del stream
3. Descargándola desde la URI del #EXT-X-KEY del manifiesto (HTTP o HTTPS)

Cuando se descarga una clave nueva, se guarda automáticamente en candela.aeskeys para futuras sesiones.

Detalles técnicos

🔧 Pestaña Config

Configuración de lectores de tarjeta, cuentas de clientes y servidores upstream. Los cambios se guardan en config/candela.json al pulsar Guardar Config Completa.

Cards expandibles - Funcionamiento

Lectores Locales

Tarjetas físicas conectadas al equipo donde corre Candela. Soporta PC/SC (Windows/Linux), Phoenix/Dragon, y lector interno de decos Enigma2.

Sistemas CAS soportados

Campos de configuración del lector

Cuentas de Clientes

Usuarios que pueden conectarse a este Candela como clientes P2P. Cada cuenta tiene usuario/contraseña y opciones de acceso.

Servidores Upstream

Candelas remotos a los que este nodo se conecta como cliente para pedir CWs. Funciona como el "server" en CCcam/Newcamd pero con el protocolo Candela cifrado.

🔬 Pestaña Forense ACF (Arsenal Forense Candela)

Herramientas de análisis e investigación para técnicos. A diferencia del Monitor (diagnóstico pasivo), el Forense permite intervención activa y análisis dirigido.

Las herramientas forenses están organizadas en sub-pestañas para no saturar la pantalla:

Live CW Inspector

Inspecciona CWs individuales sospechosas: introduce una CW en hex y Candela analiza su estructura, calcula su CRC, comprueba todos los patrónes de FakeCW y muestra si sería aceptada o rechazada y por qué motivo exacto (capa 1/2/3).

Inspector de Payload ECM

Disección byte a byte del payload de una ECM: cabecera APDU, nanos identificados, campos de control de acceso, CRC. Permite comparar estructuras ECM entre distintos providers para identificar variantes.

Timeline Forense ECM

Vista cronológica de eventos ECM/CW con resolución de milisegundos. Muestra la secuencia temporal de peticiónes, respuestas, timeouts y cambios de CW para diagnosticar canales que intermitentemente pierden el descifrado.

EMM Vault

Captura y almacena las EMMs recibidas de la red DVB. Permite analizarlas offline para entender qué comandos envía la operadora a las tarjetas. Imprescindible para investigar actualizaciónes de tarjeta o intentos de bloqueo.

Nagra Key Calculator

Dado el RSAKey y el BoxKey de una tarjeta Nagravision 2/3 (obtenidos del decodificador), calcula los parámetros derivados que algunos providers solicitan: NUID, ECMKey, CWEKey y BoxKey extendida. Los cálculos son heurísticos - válidos para la mayoría de providers pero algunos usan esquemas propietarios adicionales.

Virtual MOSC

Clon virtual completo de una tarjeta física en memoria RAM: CAID, ProvID, UA, tiers, fechas de expiración, ATR y todas las claves CAS (RSAKey, BoxKey, CWEKey, etc.). Una vez clonada, la tarjeta virtual puede:

• Resolver ECMs como si fuera la tarjeta física - actúa como lector virtual en el pool de Candela.
• Editar tiers y fechas via /api/forensics/mosc_edit: modificar suscripciones activas, fechas y configuración del clon para pruebas de compatibilidad y análisis forense.
• Editar claves CAS directamente sobre el clon: útil para probar variantes de clave, reparar una clave corrompida o cargar claves actualizadas obtenidas por otros medios.

El clon opera completamente en RAM y no modifica la tarjeta física original. Múltiples clones pueden coexistir simultáneamente con configuraciónes distintas.

Endpoints: /api/forensics/mosc_clone, /api/forensics/mosc_state, /api/forensics/mosc_edit, /api/forensics/mosc_emm.

APDU Fuzzer & Profiler

Envía comandos APDU ISO-7816 arbitrarios directamente a un lector de tarjeta local y muestra la respuesta. Permite explorar los comandos que acepta una tarjeta, medir tiempos de respuesta y diagnosticar problemas de comunicación con el lector.

ECM Simulator / Fuzzer

Genera ECMs sintéticas con campos configurables (CAID, SRVID, nano flags, longitud) y las inyecta en el flujo de procesamiento de Candela. Permite probar el comportamiento del sistema con ECMs malformadas, fuera de rango o de providers desconocidos sin necesidad de una fuente DVB real. Endpoint: /api/forensics/ecm_sim.

CW Brute-Force

Herramienta de análisis de CWs: dado un fragmento conocido del stream cifrado y la CW candidata, verifica si la CW descifra correctamente usando el motor CSA SIMD nativo. Útil para investigar CWs parciales o verificar implementaciónes de descifrado.

🔮 CW Predictor (CWP)

Ubicación en el WebIF: no es una pestaña independiente. La tabla del CW Predictor aparece al final de la pestaña Monitor, después del ECM Inspector.

El CW Predictor aprende el ciclo de vida de las CWs por canal y lanza la petición al upstream antes de que la CW actual expire. El resultado es zapping instantáneo sin pantalla negra incluso con upstreams lentos.

Cómo funcióna

Para cada canal activo (CAID × SRVID), CWP mantiene un perfil con:

• cycle_ms - ciclo de CW medido en milisegundos (EWMA con α=0.25, actualización continua)
• last_cw_ts - timestamp de la última CW entregada
• cw_last[16] - última CW recibida (para detectar cambio de criptoperíodo)
• samples - número de ciclos medidos (mínimo 3 para activar prefetch)
• prefetch_armed / prefetch_fired - estado del prefetch en curso

El watchdog (cwp_tick()) corre cada ~500ms. Cuando detecta que ha pasado el 80% del ciclo esperado y aún no se ha recibido la nueva CW, lanza automáticamente la ECM al upstream sin esperar a que el demux lo solicite.

Límites y constantes

API

Config

✏ Pestaña Editor

Gestión de los archivos de configuración de datos que Candela lee en tiempo real.

SoftCam.Key Manager

Editor del archivo config/SoftCam.Key. Contiene las claves en texto plano para el emulador. Formato compatible con SoftCam estándar. Se puede recargar en caliente sin reiniciar usando "Recargar SoftCam".

FakeCW Blacklist

Editor del archivo config/fakecws. Lista de patrónes de CW que se rechazan siempre independientemente de la heurística. Una línea por CW en hex de 16 bytes.

Services

Editor del archivo config/candela.services. Define grupos de canales por CAID:SRVID para asignar permisos por cuenta. Formato similar a ncam.services.

SrvID

Editor del archivo config/candela.srvid. Tabla de resolución CAID:SRVID → nombre de canal. Permite que el WebIf y los logs muestren nombres legibles en lugar de IDs numéricos.

ProvID

Editor del archivo config/candela.provid. Tabla de resolución CAID:ProvID → nombre de proveedor. Complementa a SrvID: donde SrvID resuelve el canal, ProvID resuelve el nombre del operador/proveedor para ese CAID y ProvID concreto.

candela.aeskeys (Claves AES IPTV)

Editor del archivo candela.aeskeys. Contiene las claves AES-128 para descifrado de streams IPTV y OTT. Una línea por canal. Ver también el panel de Claves AES IPTV en la pestaña CSA.

Formato: SRVID_HEX CLAVE_32HEX [IV_32HEX] [algo=auto|cissa|ecb|ctr|cbc0] o SRVID_HEX URL:https://servidor/key. Usar * como SRVID para definir una clave global que se aplique a cualquier canal sin entrada específica. Si no hay entrada para un canal, el pipeline ECM normal resuelve la CW.

candela.prio (Motor de prioridad)

Editor del archivo candela.prio. Define reglas de enrutamiento ECM por CAID:PROVID[:SRVID]. Dos tipos de regla:

• ALLOW - Autoriza la ECM. Si existe alguna regla ALLOW activa, las ECMs que no coincidan con ningúna son rechazadas (modo lista blanca). Útil para limitar qué sistemas de acceso condicional se descifran.
• SKIP - Descarta la ECM incondicionalmente, sin consultar lector ni red. Útil para bloquear proveedores o canales concretos.

Formato: ALLOW|SKIP CAID:PROVID[:SRVID] # comentario. Comodines: omitir SRVID aplica la regla a cualquier servicio del CAID:PROVID; PROVID 000000 coincide con cualquier proveedor del CAID.

Las reglas se evalúan antes que los filtros por usuario. Una ECM SKIPpeada se descarta para todos los clientes, incluidos los locales (DVBAPI). El archivo se puede editar directamente desde el WebIF en la pestaña Editor o a través del fórmulario de la pestaña Diagnóstico, donde además pueden aplicarse las sugerencias del modo preview como reglas ALLOW/SKIP con un solo clic.

📋 Pestaña Log

Consola de log en tiempo real. Muestra los últimos mensajes del proceso Candela. Incluye filtrado por nivel (DEBUG, INFO, WARNING, ERROR). Los logs en consola pueden silenciarse con "Silent Mode" en Mantenimiento - en ese caso solo se escriben en el fichero de log si está configurado.

🛠 Pestaña Mantenimiento

Todas las secciones se guardan con el botón único "Guardar Config" situado al final del tab. No hay botónes por sección. Orden de secciones: WebIF y Sistema → Red P2P - Identidad y Acceso → Servidor NewCamd/MGcamd → Seguridad y Alertas → Transporte y Anti-DPI (CTC + AMPE) → Credenciales WebIF → TLS.

WebIF y Sistema

Parámetros del servidor web y comportamiento general. Cambios via /api/config/global.

🌐 Red P2P - Identidad y Acceso

Identidad del nodo en la red P2P y control de acceso. Cambios via /api/security/advanced.

🚨 Seguridad y Alertas

Control del sistema anti-brute-force, alertas automáticas y registro de actividad. Cambios via /api/security/alerts.

Gestión de peers - Permaban / Tempban

Desde el panel lateral (pestaña Alertas) se puede bloquear una IP permanentemente o temporalmente. Los peers baneados no pueden conectarse aunque tengan credenciales válidas.

Transporte - CTC (Fake TLS 1.3)

Parámetros del sistema de camuflaje de protocolo. Cambios via /api/config/csa.

Credenciales WebIF

Permite cambiar el usuario y la contraseña del WebIf en caliente sin reiniciar. Requiere introducir la contraseña actual como verificación. Tras el cambio, todas las sesiones activas se inválidan y el navegador pide autenticación de nuevo. Se guarda en config/candela.json como http_user y http_pwd.

TLS / HTTPS

Genera un certificado X.509 auto-firmado RSA-2048 SHA-256 válido 365 días usando la librería OpenSSL ya enlazada (sin dependencia de openssl en PATH). El certificado se guarda en config/candela.crt y la clave privada en config/candela.key. Tras reiniciar Candela, el WebIf arranca en HTTPS si libmicrohttpd tiene soporte GnuTLS.

Chat P2P

Cuando enable_p2p_chat=1, aparece el panel de mensajería en Mantenimiento. Características:

• Protocolo: CMD_MSG_SEND (0x20) / CMD_MSG_ACK (0x21). Solo funcióna entre peers directamente conectados (sin relay). Si el peer no está conectado, el envío falla.
• Cifrado: ChaCha20-Poly1305 sobre el canal P2P ya autenticado (ECDH X25519). Los mensajes no se almacenan en disco - solo en RAM (ring buffer 256 slots). Al reiniciar, se borran.
• Tamaño: hasta 480 bytes de texto por mensaje.
• Requisito: ambos peers deben tener R31 o posterior.
• API: POST /api/messages/send (destino + texto), GET /api/messages (lista).

Reiniciar Servidor

Reinicia el proceso Candela en caliente. En Linux usa execv() (reemplaza el proceso con los mismos argumentos). En Windows usa CreateProcess() para lanzar un nuevo proceso antes de terminar el actual. El WebIf detecta la reconexión automáticamente (~3 segundos).

Backup / Restauración

Descarga todos los archivos de configuración en un ZIP, o restaura desde uno previamente descargado.

🔐 Protocolo P2P Candela

Handshake v2 - ECDH-first

En el Protocolo v2 (R35+), el intercambio ECDH X25519 se realiza antes de envíar las credenciales. El servidor rechaza cualquier CMD_HELLO sin ECDH previo - las credenciales nunca viajan bajo la clave bootstrap conocida (0x42×32).

Nonce anti-colisión

El nonce ChaCha20 de 12 bytes usa un contador monotónico por peer (tx_nonce_ctr uint64_t, incrementado en cada proto_send_packet). Los primeros 8 bytes del nonce aleatorio se XORean con este contador en big-endian, garantizando unicidad absoluta sin depender de la suerte probabilística (birthday paradox). Se resetea a 0 en cada reconexión.

Capas del protocolo

Comandos del protocolo (CMDs)

Motor HLS (Heuristic Latency Scoring)

Cuando llega una ECM, el motor HLS decide a qué peer envíarla basándose en la puntuación compuesta de cada peer:

• Hop: peers con Hop 0 (tarjeta local) tienen máxima prioridad.
• Latencia media: peers con menor latencia histórica se prefieren. Score = (avg_latency / factor_exactitud) × penalización_miss_rate.
• Exactitud de CAID: coincidencia exacta CAID+ProvID puntúa mejor que coincidencia parcial.
• Affinity: si un peer resolvió recientemente el mismo SRVID, recibe un bonus ×4 (mismo canal = misma tarjeta).
• FakeCW rate: peers que han envíado FakeCWs reciben penalización progresiva hasta hls_penalty_until.
• Disponibilidad de CAID: solo se consultan peers que anunciaron soporte para ese CAID via CMD_CARD_MAP.

Con ecm_multipath=2 o =3 (AMPE), el motor seleccióna el top-N de peers con menor score y envía la petición ECM a todos en paralelo en el mismo tick del watchdog. La primera CW válida gana; los demás actualizan igualmente su score con sus tiempos reales. Ver sección AMPE.

🗝 SoftCam Emulator

Descifra canales por software usando claves almacenadas en config/SoftCam.Key, sin necesidad de tarjeta física. Funciona como fallback cuando no hay peers disponibles o como fuente primaria en instalaciones sin tarjeta.

Sistemas soportados

Formato SoftCam.Key

Formato estándar compatible con NCam/OSCam. Ejemplo:

Donde: F=Tipo de clave (F=BISS), 01231FFF=Identificador (SID+PID), 00=KeyIndex, seguido de la clave en hex. Las claves se cargan en memoria al arrancar y son consultables desde el Monitor.

📺 DVBAPI & StreamRelay

DVBAPI

Interfaz estándar para que receptores DVB (Enigma2, VDR, Tvheadend, DVBViewer) soliciten descifrado de canales a Candela. Candela actúa como una "cam virtual".

StreamRelay (iDVB)

Motor de descifrado CSA en tiempo real para streams TS completos. Usa instrucciones SIMD/AVX2 nativas para máximo rendimiento. Escucha en 127.0.0.1:17999 por defecto. Permite descifrar streams directamente sin pasar por el receptor DVB.

💾 Caché CW & ECM DB

Caché CW (RAM)

Las CWs resueltas se almacenan en una tabla hash en RAM indexada por el hash MD5 de la ECM. Cuando llega una ECM ya conocida, Candela responde en microsegundos sin consultar a ningún peer. El tamaño máximo es configurable (default: 2048 slots). Las entradas expiran automáticamente cuando la CW ya no es válida (una CW de DVB dura ~10 segundos).

ECM DB (disco)

Cuando está activo, guarda permanentemente las relaciones ECM→CW en el archivo config/candela.ecmdb. Permite responder ECMs conocidas incluso si el upstream está caído y la caché RAM ya expiró. Funciona como el module-emulator-ecmdb.c de NCam. Útil en instalaciones con upstreams poco fiables.

CacheEX

Extensión de caché P2P: los peers comparten entradas de caché entre sí. Cuando un peer resuelve una ECM, la entra en la caché de todos los peers conectados que tengan CacheEX activo. Reduce la latencia media en redes donde múltiples nodos ven los mismos canales.

🚫 Detección FakeCW

Candela implementa 3 capas independientes de detección de CWs falsas o corruptas. Una CW rechazada se descarta silenciosamente - no se envía al receptor DVB ni se guarda en caché.

Capa 1: Blacklist estática

Archivo config/fakecws editable desde la pestaña Editor. Contiene patrónes de CW conocidos como falsos (CWs de prueba de operadoras, patrónes de NCam, etc.). La comprobación es O(1) - búsqueda en tabla hash.

Capa 2: Heurística estructural

Analiza la estructura de la CW sin necesidad de contexto de canal. Detecta patrónes que nunca aparecen en CWs legítimas:

• Entropía baja (bytes muy repetidos).
• Mitades even/odd idénticas.
• 14+ bytes con el mismo valor (0x00, 0xFF, 0xAA, 0xCC, 0xF0).
• Secuencias incrementales o decrementales.
• Mitad even/odd con un único byte distinto.

Capa 3: Heurística dinámica

Analiza el comportamiento temporal de la CW en su contexto:

• Hop ≥ 2 + latencia < 80ms: imposiblemente rápido para una CW real pasando por 2 saltos. Indica un peer que responde sin resolver realmente.
• Ciclo SM < 6s: si dos CWs del mismo CAID:SRVID llegan con menos de 6 segundos de diferencia, una de las dos es falsa (el ciclo real de DVB es ≥10s).

✅ DoubleCheck CW

Sistema de verificación por consenso inspirado en el parche OSCam r11890+ de mejora del doublecheck. Requiere confirmación de múltiples peers antes de aceptar una CW.

Flujo de decisión

🔒 TLS / HTTPS

Generación de certificado

Candela genera un certificado X.509 auto-firmado RSA-2048 con SHA-256 usando la librería OpenSSL que ya viene enlazada en el binario. No requiere que openssl esté instalado en el sistema.

Archivos generados: config/candela.crt (certificado público) y config/candela.key (clave privada). La clave privada nunca sale del proceso - no se envía por red ni se registra en logs.

Activar HTTPS

1. Ir a Mantenimiento → TLS / HTTPS → "Generar certificado auto-firmado"
2. Candela guarda el certificado y actualiza config.json
3. Reiniciar Candela (botón en Mantenimiento o manualmente)
4. Acceder por https://ip:8080

Requisito TLS en libmicrohttpd

Para que HTTPS funcióne, la librería libmicrohttpd debe haber sido compilada con soporte GnuTLS (--enable-https). En MSYS2: pacman -S mingw-w64-x86_64-libmicrohttpd. Si la lib no tiene soporte TLS, Candela arranca en HTTP y el log indica el motivo.

🧅 SOCKS5 / Tor / I2P

Candela soporta dos niveles de proxy para tunelizar conexiónes P2P salientes: un Proxy Universal global (nuevo, recomendado) y un proxy por-servidor (legado, por compatibilidad). Ambos permiten usar Tor, I2P o cualquier proxy SOCKS sin cambios en el protocolo.

Proxy Universal (global)

Disponible en Config → Proxy Universal - SOCKS4 / SOCKS5 / Tor / I2P. Se aplica a todas las conexiónes P2P salientes que no tengan un proxy por-servidor configurado.

Proxy por-servidor (legado)

Cada servidor upstream puede tener su propio campo SOCKS5 Proxy (opc) en formato host:puerto. Si un servidor tiene este campo configurado, usa ese proxy en lugar del global. Si esta vacío, usa el Proxy Universal si esta activo.

Este metodo solo soporta SOCKS5 sin autenticación. Para autenticación o SOCKS4 usar el Proxy Universal.

Prioridad

Uso con Tor

Funcionamiento interno

1. Candela conecta al proxy en la IP:puerto configurados
2. Negocia el handshake SOCKS4 o SOCKS5 (con o sin autenticación segun configuración)
3. El proxy establece la conexión TCP al servidor Candela destino
4. Todo el trafico P2P (ChaCha20-Poly1305) fluye por el tunel desde ese momento

Consideraciones de latencia

• Tor añade tipicamente 100-300ms de latencia por hop. Puede afectar al tiempo de resolución ECM.
• I2P tiene latencia aun mayor. Recomendado solo para nodos con cache CW activo.
• SOCKS5 local o corporativo: latencia despreciable.

🔀 CAID Tunneling

El CAID Tunneling permite que Candela anuncie un CAID diferente al real cuando se conecta a un servidor upstream. Útil cuando el servidor upstream no tiene el CAID correcto pero tiene otro compatible.

Caso de uso típico

Configuración en config.json

En el WebIf → Config → sección "CAID Tunneling". Al añadir un túnel se muestra la nota: "Túnel activo - el lector anunciará ambos CAIDs en el Card Map".

Pares compatibles conocidos

Implementación

Al procesar una ECM, el motor interno comprueba si el CAID solicitado tiene un túnel configurado antes de enrutar la petición.

🔌 NewCamd / MGcamd: Compatibilidad con NCam/OSCam

A partir de R40, Candela es compatible con los protocolos NewCamd y MGcamd, los mismos que usan NCam y OSCam. Esto permite íntegrarlo en instalaciones existentes sin reemplazar toda la infraestructura.

Diferencias entre protocolos

Autenticación y cifrado (común a ambos)

El handshake sigue el estándar NewCamd:

1. Servidor envía 14 bytes aleatorios (rand14).
2. Clave de sesión: session_key[i] = rand14[i] XOR deskey[i]
3. 3DES-EDE2-CBC: key1 = session_key[0..7], key2 = session_key[6..13] (solape de 2 bytes, compatible OSCam).
4. IV = 16 bytes cero.
5. Login: cliente envía MSG_LOGIN con usuario + MD5(password). Servidor responde MSG_LOGIN_ACK o MSG_LOGIN_NAK.

Modo servidor: Candela sirve tarjetas

Candela abre un puerto NewCamd o MGcamd para que NCam/OSCam se conecten como clientes y pidan descifrado de ECMs. Útil cuando NCam/OSCam ya está instalado en el mismo equipo o en la red local y se quiere añadir Candela como fuente de CWs.

Configuración (WebIF - Clientes - Protocolo: NewCamd o MGcamd):

En NCam/OSCam configurar una N-line (NewCamd) o M-line (MGcamd) apuntando a la IP de Candela con los mismos parámetros.

Modo cliente: Candela consume tarjetas de NCam/OSCam

Candela se conecta a un NCam/OSCam existente y usa sus tarjetas para resolver ECMs. Las tarjetas recibidas por esta vía aparecen en el Card Map como hop=0, is_hw=1, igual que una tarjeta física local.

Configuración (WebIF - Servidores - Protocolo: NewCamd o MGcamd):

Apariencia en el Card Map

Las tarjetas recibidas por NewCamd/MGcamd aparecen como:

El campo hop=0 indica tarjeta de primer nivel (sin reshare). El campo hw=1 indica que el sistema la considera hardware físico a efectos de enrutamiento de ECMs.

Filtros, cuentas y rate-limiting

En modo servidor, cada cliente NCam/OSCam se identifica por el usuario autenticado en el handshake (no un usuario genérico interno). Esto significa:

• El rate-limiter de ECMs (ecm_ratelimit) se aplica por usuario individual.
• Los filtros globales de CAID/Ident/SRVID se aplican a todas las ECMs entrantes.
• Si existe en la config una cuenta Candela con el mismo nombre de usuario, se aplican sus restricciones de services y max_hops.
• La caché CW es compartida: si la ECM ya fue resuelta por otro cliente (Candela o NCam/OSCam), se sirve desde caché sin tocar el lector.
• SCC, ETS, MCRR y Coalescing se aplican igualmente sobre los lectores físicos que sirven la respuesta.

Flujo ECM en modo cliente

1. Llega una ECM para CAID X (tabla even 0x80 u odd 0x81).
2. El motor comprueba caché, lectores locales y SCC/MCRR antes de llegar al reader NewCamd/MGcamd.
3. Si hay reader conectado para ese CAID, envía el MSG_ECM y espera MSG_CW_OK.
4. La CW obtenida se guarda en caché ("NewCamd" / "MGcamd" como fuente) para peticiónes posteriores.
5. Si responde MSG_ECM_NAK, el motor escala a la red P2P Candela.

Modo Candela - Capa ChaCha20 anti-DPI (R40)

El Modo Candela añade una segunda capa de cifrado ChaCha20 sobre DES/3DES cuando ambos extremos son nodos Candela con candela_mode=1. Con NCam/OSCam el protocolo cae en modo legado sin ningúna interrupción.

Negociación CNDL

1. Cliente Candela (con candela_mode=1) añade al payload de login: CNDL[4] + NodeID[8 bytes binario] (12 bytes extra al final).
2. Servidores NCam/OSCam ignoran estos bytes extra: el protocolo NewCamd solo parsea usuario\0 md5[16], el resto es inerte.
3. Si el servidor Candela detecta el magic CNDL y tiene candela_mode=1, responde en el ACK con CNDL + NodeID del servidor.
4. Si el ACK no contiene CNDL, el cliente desactiva el Modo Candela y continúa en modo legado estándar.

Derivación de clave ChaCha20

La derivación usa los 14 bytes de session key DES (ya negociados en el handshake estándar). No hay intercambio adicional de clave: ambos extremos calculan el mismo resultado de forma independiente.

Aplicación de la capa

Tras el handshake, todos los mensajes con payload (CARD_DATA, ECM, CW) se procesan con doble capa:

• Envío: ChaCha20 (capa Candela) sobre el payload en claro, después DES/3DES (capa NewCamd).
• Recepción: se deshace DES/3DES primero, después ChaCha20.

Los contadores ChaCha20 son independientes por dirección (cm_send_ctr / cm_recv_ctr, uint32). Solo se incrementan con payload de longitud mayor que cero: los mensajes sin datos (keepalive, etc.) no consumen contador, garantizando sincronismo de ambos extremos sin intercambio de estado.

Lo que el Modo Candela consigue y lo que no

Configuración en config.json

Mejoras de calidad en servidores NewCamd/MGcamd (R41)

ECM Coalescing

Cuando varios clientes conectados al servidor NewCamd o MGcamd solicitan el mismo ECM simultáneamente (mismo CAID, SRVID y hash de payload), Candela lanza una sola resolución al lector y hace esperar al resto en un pthread_cond_t. Cuando la CW llega, todos los clientes en espera la reciben al instante.

• Pool de 128 slots compartido entre servidores NewCamd y MGcamd.
• El primer cliente que llega al slot activa la resolución; los demás esperan sin contención.
• Si el pool está lleno, el cliente resuelve directamente sin coalescing (degradación suave).

Detección y purga de CW mala

Si un cliente reenvía el mismo ECM (mismo hash MD5 del payload) en menos de 5 segundos, Candela interpreta que la CW anterior era inválida y actúa:

1. Elimina la CW mala de la caché de forma selectiva (cache_invalidate_ecm()).
2. Fuerza una nueva resolución al lector en lugar de devolver la CW cacheada.

Push proactivo de CW

Cuando la caché recibe una CW nueva (por cualquier fuente: lector local, P2P, reader NC/MG), los clientes NewCamd/MGcamd que estén esperando una CW para ese mismo servicio son notificados inmediatamente a través de un pipe(2) interno por cliente. El thread de cada cliente monitoriza el pipe en su select() principal.

• La notificación transporta CAID, SRVID y la CW (23 bytes).
• El dispatch filtra por hash del ECM del cliente: solo despierta el coal slot del cliente si corresponde al mismo ECM que está esperando. Esto evita entregar una CW de un período de cifrado diferente (odd vs. even).
• Si la CW no pasa el filtro de validez (cw_is_valid()), se descarta.

Métricas de calidad por cliente

El JSON de la API de clientes conectados (/api/peers/list) incluye para cada cliente NewCamd/MGcamd:

El WebIF muestra estos valores en la tabla de clientes conectados (escritorio y móvil): la latencia como tooltip en el badge de protocolo y los fallos consecutivos como badge rojo.

Validación por consenso en Modo Candela

Cuando Modo Candela está activo (candela_mode=1) y hay al menos 2 peers P2P Candela conectados, la CW obtenida no se envía inmediatamente al cliente. Candela espera hasta 800 ms a que la red P2P confirme la misma CW para ese servicio. Si la red devuelve una CW diferente, se descarta la CW local y se responde con NAK.

🔑 Nagravision / CAK7 / Merlin

Parámetros de tarjeta Nagra

CAK7 / Nagra Merlin

CAK7 es el protocolo de seguridad mejorado de las tarjetas Nagra Merlin modernas. A diferencia de Nagra2 estándar (solo RSA), CAK7 añade una segunda capa de cifrado AES-128-ECB sobre la CW resultante del RSA.

Flujo de descifrado CAK7

Providers CAK7 conocidos

Candela detecta automáticamente si el CAID del lector es CAK7 y aplica el descifrado CWEKey si está configurada. Sin CWEKey en providers que la requieren, la CW llega cifrada y el canal no abre.

Herramienta Nagra Key Calculator (Forense)

Dado el RSAKey y el BoxKey, calcula los parámetros derivados: NUID, ECMKey, CWEKey y BoxKey extendida. Los cálculos usan operaciónes XOR estándar de Nagra 2/3 - son heurísticos y funciónan para la mayoría de providers, pero algunos pueden tener variaciones propietarias.

🔌 Referencia API REST

Todos los endpoints requieren autenticación HTTP Basic (usuario:contraseña configurados en http_user / http_pwd). Las peticiónes POST esperan Content-Type: application/json. WebIF soporta TLS 1.3, failban íntegrado (10 intentos → bloqueo 1 hora) y rate limiting por IP.

Estado y monitoreo

ECM y CW

Configuración dinámica

Archivos de configuración

Peers y red P2P

Seguridad y control de acceso

Mensajería P2P (R31)

Módulos forenses R33+ (ETO / CWS / ERD / CFI / EFG / CWRID / EEA / ECLD)

Softcam Virtual MOSC

Auditoría y logs

Mantenimiento

🏷 Codenames de versión

A partir de R35, cada versión lleva un codename: una sola palabra en español, de temática defensiva o de infraestructura, que identifica la versión en logs y comunicaciónes. Aparece en el arranque como Candela Softcam v1.0 (R42 - Cóndor).

Versiones

📄 Campos config.json

📐 Formatos CW (64/128 bits)

Una Control Word (CW) es la clave simétrica que un receptor DVB usa para descifrar el stream. Candela maneja dos formatos según el CAS y el modo de operación.

CW estándar DVB-CSA (64 bits)

DVB-CSA1 usa las dos mitades de la CW en ciclos alternos. El descrambler hardware del receptor aplica el algoritmo CSA con la CW del período vigente.

CW extendida (128 bits)

En el protocolo Candela

CAK7 - CW cifrada

En Nagra CAK7/Merlin, la CW que sale del RSA está cifrada con AES-128-ECB usando la CWEKey del lector. Candela descifra automáticamente si CWEKey está configurada:

Detección automática en Candela

El motor DVBAPI examina el campo CA_type del ECM y el CAID del demux para determinar si usar CSA1 (8 bytes) o CSA3/AES (16 bytes). El motor CSA seleccióna automáticamente el modo correcto. El usuario no necesita configurar nada adicional.

CW Fake / CW Corruptas

Candela mantiene una lista negra de CWs conocidas como falsas o corruptas (configurada en config/candela.fakecws). Si un upstream devuelve una CW que coincide con la lista, se descarta y se marca al peer con penalización HLS. Ver sección FakeCW / CW Audit.

🔑 PFS / ECDH X25519 (Perfect Forward Secrecy)

¿Qué es PFS?

Perfect Forward Secrecy garantiza que el descifrado de tráfico pasado capturado sea imposible aunque un atacante obtenga la clave maestra en el futuro. Cada sesión P2P negocia un secreto compartido único derivado de claves efímeras X25519 que se descartan al cerrar la sesión.

Flujo de handshake ECDH (R30)

Comandos nuevos en R30

Compatibilidad

La negociación ECDH es opcional y retrocompatible. Si un peer no soporta R30, el handshake usa el método anterior (ChaCha20-Poly1305 con clave derivada de credenciales). Cuando ambos peers son R30+, ECDH se activa automáticamente.

💬 Mensajería Privada P2P

Funcionamiento

Los mensajes P2P se transmiten usando los nuevos comandos del protocolo Candela cifrados con la clave de sesión ChaCha20-Poly1305. Solo pueden intercambiar mensajes peers que ya tienen una sesión autenticada activa - no es un sistema de mensajería anónimo.

Comandos R31

API de mensajería

Activación

En Mantenimiento → WebIF y Sistema → activar enable_p2p_chat. El toggle aparece en el panel de mensajería. Si el peer remoto no tiene R31 o no tiene el chat activado, los mensajes envíados se descartan silenciosamente (no hay error).

🛡 Red P2P - Seguridad y Tommy hashlin O(1)

Fix: corrupción de config vía /api/config

En versiones anteriores, el endpoint POST /api/config aceptaba escritura directa de campos de seguridad sensibles (p2p_allowed, max_conn_ip) mezclados con la config general. En R32 estos campos se han separado a /api/security/advanced con válidación estricta de tipos y rangos, eliminando el vector de corrupción accidental o maliciosa.

Filtro triple en accept loop P2P

El bucle de aceptación de conexiónes P2P ahora aplica tres filtros antes de pasar al handshake:

1. IP whitelist/blacklist: verifica p2p_allowed si está configurado.
2. Límite por IP: cuenta conexiónes activas de esa IP y rechaza si supera p2p_max_conn_per_ip.
3. Failban: comprueba si la IP está en la lista de bans (tempban o permaban).

Conexiones rechazadas generan un evento en el audit log si está activo.

Tommy hashlin O(1) para ECMs pendientes

Hasta R31, el pool de ECMs pendientes (pending_ecms[1024]) se buscaba con O(n) scans líneales. En R32 se reemplazaron 6 bucles de búsqueda por una tabla hash incremental tommy_hashlin indexada por el hash MD5 de la ECM:

⏱ ETO - ECM Timing Oracle

El ETO registra la latencia de respuesta de cada ECM agrupada por fuente (IP del peer o etiqueta del lector) y CAID, construyendo un perfil estadístico en tiempo real que se usa como señal de seguridad para detectar upstreams degradados o comprometidos.

¿Qué mide y por qué

Perfil estadístico

Cada perfil (eto_profile_t) rastrea un par (label, CAID) con:

• n_samples - número total de muestras registradas
• sum_ms / sum_sq_ms - suma y suma de cuadrados para calcular media y σ en integer aritmética
• min_ms / max_ms - latencias extremas registradas
• hist[16] - histograma de frecuencias, 16 cubos de 100ms cada uno (último: >1500ms)
• anomaly_count / last_anomaly_ms - contador de anomalías y última latencia anómala

Límite: ETO_MAX_PROFILES=64 pares simultáneos. La detección de anomalías requiere ≥ETO_MIN_SAMPLES=5 muestras.

Integración con ERD

El módulo ERD (ECM Replay Detector) consulta el ETO mediante eto_get_mean_ms(caid) para calcular el retardo sintético adaptativo. Si no hay suficientes muestras, ERD usa el valor por defecto configurado (erd_default_ms).

API

Config

🛡 CWS - CW Consensus Shield

Las operadoras con sistemas anti-cardsharing (Movistar+, Sky, Canal+) inyectan periódicamente CWs envenenadas: respuestas que pasan el checksum DVB pero contienen bytes incorrectos que hacen que la imagen salga corrupta o en negro. El CW Consensus Shield neutraliza este ataque.

Principio de funciónamiento

Mecanismo

• Acumulador de votos - al recibir CMD_CW_RESP, antes de entregar al demux, registra la CW en un slot de votación indexado por el hash de la ECM.
• Threshold de quórum - configurable (cw_consensus_quorum, default 2). En cuanto N peers coinciden, entrega la CW ganadora inmediatamente.
• Timeout de consenso - si en client_timeout/2 ms no hay quórum, entrega la CW del peer de mayor reputación HLS.
• Penalización automática - peer que entregó CW no ganadora: -5 en avg_latency score. Tras 3 penalizaciónes → deprioritizado 60s.

Diferencia con DoubleCheck

Config y API

🎭 ERD - ECM Replay Detector

Cuando una ECM llega y ya está en caché, Candela la responde en <5ms. Las tarjetas físicas tardan ~300ms. Los operadores anti-piratería pueden detectar softcams lanzando ECMs de prueba y midiendo el tiempo de respuesta. ERD neutraliza este vector de detección.

Problema: fingerprinting por timing

Implementación no bloqueante

ERD no bloquea ni crea hilos. Al detectar un cache hit, calcula el retardo y lo registra internamente. El motor de ECMs pendientes re-evalúa cada iteración y entrega la CW cuando el timer expira. Zero overhead adicional.

Cálculo del retardo

Estadísticas ERD

Config

🪄 CFI - CAS Fingerprint Inversion

CFI es la evolución directa del ERD. Donde ERD imita el tiempo medio de la tarjeta (~300ms), CFI imita el mínimo histórico plausible - el retardo más corto que la tarjeta real ha mostrado para ese CAID. El resultado es idéntico opacidad anti-fingerprinting con latencia percibida por el usuario hasta 6× menor.

ERD vs CFI - Diferencia clave

Compensación de tiempo transcurrido

Si la ECM ya tardó más que el floor CFI (por ejemplo, un peer upstream que tardó 80ms y el floor es 50ms), CFI no añade retardo adicional - entrega inmediatamente. Esto es el modo passthrough y hace que CFI sea completamente transparente en carga de red alta.

Precedencia CFI → ERD

Cuando ambos módulos están activos, CFI tiene precedencia. ERD solo actúa como fallback si CFI está desactivado. No se acumulan retardos.

Estadísticas CFI

Config

🔒 EFG - ECM Flow Guard

Un peer legítimo puede zappear rápido por muchos canales - pero cada canal recibe solo 1-2 ECMs y luego silencio. Un peer que hace resharing mantiene varios canales con ECMs continuas cada ~10s (el crypto period habitual). EFG distingue ambos casos y protege la tarjeta física de banes por anti-cascading.

El problema: cascading detection

Los operadores rastrean cuántos SIDs distintos solicita una tarjeta en una ventana temporal. Una tarjeta que sirve muchos canales simultáneamente (resharing) genera una diversidad de SIDs estadísticamente imposible para un suscriptor legítimo. EFG detecta esto en el extremo Candela antes de que lo haga el operador.

Diferencia entre zapping y resharing

Strict Cache Mode dinámico

Cuando EFG detecta que un peer supera el límite de SIDs activos configurado, activa Strict Cache Mode: el peer solo puede recibir CWs que ya estén en caché. Las peticiónes que requieran tarjeta física son denegadas - protegiendo la tarjeta sin cortar el servicio. El modo expira automáticamente tras el período configurado.

Implementación técnica

• Ring buffer lock-free - estado embebido directamente en la estructura interna de cada peer. Sin malloc, sin free.
• O(1) hot path - efg_record_sid() es static inline. Zero overhead de llamada en el camino crítico de ECM.
• Lazy expiry - las entradas expiradas se limpian solo cuando se evalúa un nuevo SID, no en cada ECM.
• Thread-safe sin mutex - el índice de escritura usa operaciónes atómicas para ser thread-safe sin bloqueos.
• Auto-recovery - al expirar el timer de penalización, el peer vuelve a modo normal automáticamente con log de recuperación.

Config

API

🔍 CWRID - CW Replay & Injection Detector

Detecta dos patrónes de abuso de CW en tiempo real usando una ventana deslizante de hashes (SHA256 truncado a 8 bytes):

• CW Replay: la misma CW aparece asociada a ECMs distintas o canales distintos dentro de la ventana. Indica reutilización de CW pre-grabada o inyección de CW estática por un peer malicioso.
• Lateral Sharing: la misma CW se entrega a más de un SRVID diferente. Dentro del mismo canal es normal (simulcrypt); si los SRVIDs son distintos indica resharing encubierto.

Implementación

Ventana deslizante de 32 entradas. Cada entrada almacena el hash SHA256[:8] de la CW, CAID, hasta 4 SRVIDs distintos y los timestamps de primera y última aparición. Cuando la ventana está llena se reemplaza la entrada más antigua. Sin malloc: array estático.

Config

API

📊 EEA - ECM Entropy Analyzer

Calcula la entropía de Shannon de los bytes de cada CW por CAID. Una CW generada por un CAS legítimo es prácticamente aleatoria (≈8.0 bits/byte). Una CW con entropía baja indica:

• Fake CW inyectada por peer malicioso (ej: 0x00×16, 0xFF×16)
• CW mal descifrada por corrupción de clave en el CAS local
• CAS en modo de fallo devolviendo un valor fijo

El umbral de alerta es 7.0 bits/byte. Las alertas solo se emiten a partir de 5 muestras para evitar falsos positivos en el arranque.

Config

API

⏳ ECLD - ECM Chain Latency Decomposer

Registra los timestamps de las 5 etapas del ciclo de vida de cada ECM para descomponer la latencia total en sus componentes:

🛡 OLG - ECM Overlap Guard

Previene pantallas negras durante el cambio de criptoperíodo. El problema: entre que el demux solicita una nueva CW y el upstream la entrega pueden pasar entre 100ms y 2s. Si la CW anterior ya expiró, el demux queda sin descifrar y aparece pantalla negra.

Cómo funcióna

OLG mantiene una tabla de la última CW válida entregada por canal (CAID × SRVID, hasta 256 entradas). Cuando llega una ECM que no está en caché, antes de encolar la petición al upstream, OLG entrega inmediatamente la última CW conocida al demux. El demux puede seguir descifrando mientras llega la nueva CW.

Integración con Adaptive Timeout

El timeout de ECM es ahora adaptativo: usa la media ETO × 3 por CAID, con mínimo de 500ms y sin superar el timeout global. Esto complementa a OLG: los canales con upstream lento no se cortan prematuramente, y mientras el upstream trabaja el demux tiene la CW de soporte de OLG.

Config

🔒 CTC - Candela Transport Camouflage

El problema que resuelve

Los ISPs activan un modo "lista blanca" durante eventos de alta demanda (fútbol, F1, Fórmula E): en lugar de intentar leer el contenido, el DPI bloquea directamente cualquier conexión TCP cuyo perfil de tráfico no encaje en un protocolo conocido y aprobado. Alta entropía uniforme + longitud de paquetes no estándar = corte inmediato. No necesitan saber qué es. Si no lo reconocen, lo tiran.

El anti-DPI estocástico de Candela (ChaCha20, padding aleatorio, jitter, LZ4) hace el payload ilegible y dificulta la correlación, pero no resuelve el bloqueo por perfil de tráfico. CTC añade la capa de presentación que faltaba: framing TLS Application Data indistinguible de HTTPS real. Los vectores restantes - distribución estadística de tamaños de paquete, patrón temporal de ECMs, ausencia de tráfico de fondo y duración de sesión TCP - quedan cubiertos por el módulo Anti-DPI Suite (TAR), implementado en R37. Con CTC + CPM + TAR activos, la cobertura anti-DPI es del 100%.

Cómo funcióna

CTC envuelve cada paquete Candela en un TLS Application Data record estándar. Para el DPI es tráfico HTTPS/TLS estándar. El payload interno sigue siendo ChaCha20+Poly1305, con entropía indistinguible de datos TLS cifrados reales. El overhead es mínimo - unos pocos bytes por paquete más un handshake inicial.

Handshake de sesión

Al conectar, se intercambia un par ClientHello/ServerHello TLS 1.3 sintético (estructuralmente válido para DPI, no funciónal como TLS real):

• ClientHello: cipher suites TLS_AES_128_GCM / AES_256_GCM / CHACHA20, Random[32] aleatorio (distinto en cada sesión), extensiones supported_versions + supported_groups (x25519) + SNI opcional.
• ServerHello: respuesta sintética equivalente.
• A partir de ahí: framing TLS Application Data en cada paquete Candela.

Retrocompatibilidad automática

El servidor detecta automáticamente si el cliente soporta CTC mediante MSG_PEEK del primer byte de la conexión:

• 0x16 (TLS Handshake) → peer R34 o superior → ejecuta handshake → activa framing
• Cualquier otro byte → peer legacy (anterior a R34) → modo legacy sin framing, sin coordinación manual

Los clientes legacy (anterior a R34) siguen conectándose y funciónando sin cambios.

SNI - sin apuntar a dominios ajenos

Implementación técnica

• Envío: writev() scatter/gather en POSIX - iovec[0] = 5 bytes cabecera en stack, iovec[1] = payload Candela original. Cero memcpy, cero malloc.
• Recepción: máquina de estados ctc_strip() por peer - gestiona fragmentación TCP correctamente.
• Windows: buffer en stack MTU-safe (no hay writev).
• Sin OpenSSL TLS real: solo RAND_bytes ya enlazado. Cero dependencias nuevas.

Límites del diseño

Config

🔁 ECDH Rekey - Rotación de sesión cada 24h

El problema que resuelve

El intercambio ECDH X25519 genera una session_key efímera única por conexión. Si un peer permanece conectado 7 días, esa clave protege todo el tráfico de esa sesión. Si alguien compromete esa clave en memoria, puede descifrar toda la sesión pasada (sin PFS dentro de la sesión).

Solución: Rekey in-session a las 24h

El watchdog del servidor detecta automáticamente sesiones con connected_at > 86400s. La rotación se hace de forma diferente según el rol del peer:

• Peer entrante (cliente conectado a nosotros): el servidor inicia un nuevo intercambio ECDH usando los mismos comandos CMD_ECDH_INIT/RESP/ACK, pero sobre la sesión activa. La TCP no se corta. El cliente responde con su nueva clave pública. Ambos derivan el nuevo secreto compartido y activan la nueva clave sin interrupción perceptible.
• Peer saliente (servidor al que nos conectamos): se desconecta limpiamente. El watchdog de reconexión inicia una nueva sesión TCP completa, con nuevo ECDH desde cero. El servidor remoto también aplica su rekey in-session a esa nueva conexión.

Mecanismo técnico

El rekey reutiliza la misma máquina de estados ECDH de R30, extendida para sesiones activas:

1. Servidor genera nuevo par X25519 → almacena privkey en peer->ecdh_priv
2. Servidor envía CMD_ECDH_INIT (nueva pubkey) al cliente por el canal existente (cifrado con clave actual)
3. Cliente genera nuevo par → deriva secreto → guarda en pending_key (modo 1) → responde con CMD_ECDH_RESP (cifrado con clave antigua)
4. Servidor recibe RESP → deriva secreto → activa nueva clave inmediatamente → guarda antigua como residual (modo 2) → envía CMD_ECDH_ACK (cifrado con clave nueva)
5. Cliente recibe ACK con clave nueva → mecanismo Fallback AEAD activa pending_key → connected_at se reinicia → timer de 24h vuelve a cero

Guard anti-doble-envío: Si llega un tick del watchdog antes de que el cliente responda (ecdh_priv != NULL), el servidor no envía un segundo ECDH_INIT.

Nodos virtuales (sin tarjeta física)

Los nodos que actúan como relay o proxy (sin lector físico propio) anuncian las tarjetas de sus upstream mediante CMD_CARD_MAP con hop=N+1. El campo max_hops de la cuenta de cada cliente controla hasta qué profundidad de hop puede ver ese cliente:

• max_hops=0 → solo tarjetas físicas del nodo (hop 0)
• max_hops=1 → hop 0 + lo que el nodo obtiene de sus upstream directos (hop 1)
• max_hops=N → hasta N hops de profundidad

Los peers con hop > 10 se descartan para evitar propagación anómala.

Failban anti-CGNAT

Cuando un peer autentica correctamente, se limpia el contador de intentos fallidos de su IP. Esto evita que en redes con CGNAT (múltiples peers compartiendo la misma IP pública) un peer con credenciales incorrectas banee involuntariamente a otros peers legítimos en la misma IP.

🔒 Reshare Enforcement - Control de redistribución (R35)

El problema

En los sistemas de cardsharing convencionales (ncam, oscam), el operador puede configurar que un cliente no tenga permiso de reshare, pero esa restricción es puramente local: el cliente puede ignorarla, modificar su software y redistribuir igualmente las CWs recibidas. En Candela, el mecanismo opera a nivel de anuncio de capacidades: si el cliente no sabe qué tarjetas tiene acceso a redistribuir, no puede ofrecerlas.

Solución: flag no_reshare en el protocolo

El byte HOP del protocolo CMD_CARD_MAP ahora codifica dos campos:

El cliente almacena el flag no_reshare junto con la entrada de card_map. Cuando construye su propio CMD_CARD_MAP para envíarlo a sus clientes, salta todas las entradas marcadas no_reshare=1 - independientemente de lo que indique su configuración local.

Cuándo se activa el flag

• reshare_hops=0 en la cuenta del cliente (default): todas las entradas envíadas a ese cliente llevan bit 7=1.
• enable_reshare=0 en config global: equivale a reshare_hops=0 para todos los clientes, sin excepción.
• Propagación transitiva: si A no permite reshare a B, B almacena la entrada como no_reshare=1 y nunca la incluye en su CMD_CARD_MAP hacia C, aunque C tenga max_hops > 0.

Compatibilidad con nodos legacy

Un nodo Candela anterior a R35 no conoce el bit 7. Al recibir una entrada con bit 7=1, ve el byte HOP con valor > 10 y lo descarta silenciosamente (regla ya existente). El resultado es idéntico al esperado: no puede anunciar la tarjeta. Comportamiento fail-safe por diseño.

Diferencia respecto al control de visibilidad (max_hops)

Config

🫀 CPM - Adaptive Pulse Masking

El problema que resuelve

El Fake TLS 1.3 (CTC) oculta el contenido de los paquetes, pero no oculta el ritmo. El cardsharing tiene una firma temporal inconfundible: una petición de ~150 bytes y una respuesta de ~32 bytes exactamente cada 10-15 segundos (el criptoperíodo DVB). Un DPI avanzado no necesita leer el paquete - si ve ese patrón de silencio/ráfaga/silencio a intervalos regulares, identifica el servicio y puede actuar.

Solución: Adaptive Chaffing

Por cada peer autenticado, el sistema monitoriza el tiempo desde el último envío real (last_tx_time). Si el silencio supera un umbral aleatorio de 2.0 a 3.5 segundos, se inyecta un paquete de relleno (CMD_PADDING) con payload pseudoaleatorio de 200 a 1400 bytes. El resultado: el DPI ve una conexión TLS con tráfico continuo y variable. El latido de 10s queda enterrado.

Diseño técnico

• PRNG xorshift32: no bloqueante, cero syscalls, ~1ns/llamada. Seed con clock_gettime(MONOTONIC) ^ getpid() en el arranque. Distinto en cada proceso.
• Sin hilos adicionales: la evaluación se hace en el bucle watchdog existente (~250ms de resolución). Cero pthread_create.
• Intervalo desfasado por peer: next_chaff_ms se renueva aleatoriamente tras cada chaff, evitando ráfagas síncronas cuando hay muchos peers.
• Cifrado estándar: el chaff pasa por proto_send_packet() → LZ4 + ChaCha20-Poly1305 + CTC si está activo. Indistinguible de tráfico real.
• Coste por peer: ~1 paquete/2.75s × 800 bytes promedio ≈ 2.3 kbps. En un router MIPS con 5 peers: ~11.5 kbps total. En un VPS con 100 peers: ~230 kbps - perfectamente asumible.

Campos añadidos a candela_peer_t

Config

🎭 DPM - Decoy Port Multiplexing

El problema que resuelve

Cualquier escáner de red (Shodan, ZMap, Censys, herramientas de ISP) que encuentre el puerto P2P de Candela puede identificarlo mediante un banner grab: el primer byte no es un verbo HTTP ni un handshake TLS reconocido, por lo que queda clasificado como "protocolo desconocido de alta entropía". Esta clasificación puede atraer atención indeseada o desencadenar bloqueos automáticos.

Solución: respuesta HTTP falsa

El servidor inspecciona los primeros 4 bytes de cualquier conexión entrante no autenticada que no haya iniciado un handshake CTC. Si coincide con un verbo HTTP (GET , POST, HEAD, OPTI, PUT , DELE, CONN), responde con una página nginx plausible y cierra inmediatamente la conexión.

Respuesta envíada

HTTP/1.1 200 OK
Server: nginx/1.24.0
Content-Type: text/html; charset=utf-8
Content-Length: 97
Connection: close

<!DOCTYPE html><html><head><title>Home</title></head>
<body><p>Service unavailable.</p></body></html>

Diseño técnico

• Detección: memcmp de 4 bytes - sin parsing HTTP completo. Cero asignaciones dinámicas.
• Condiciones: peer no autenticado + ctc_active == 0 + bytes_read >= 4. Un peer Candela legítimo nunca envía un verbo HTTP.
• Respuesta estática: static const char dpm_resp[] - compilada en el binario, sin ficheros externos.
• Coste en peers legítimos: cero. La condición falla en la primera comprobación (peer autenticado o CTC activo).

Config

🎯 Anti-Scanner - Honeypot CAIDs + CAID Probe Detection

Honeypot CAIDs

Los Honeypot CAIDs son valores de CAID ficticios configurados como trampa. Ningún canal real de TV existe con estos CAIDs, por lo que cualquier peer que solicite un ECM con uno de ellos es, con 100% de certeza, un scanner, bot o cliente malicioso.

Configuración de Honeypot CAIDs

Anti-Probing - Detección de scanners por CAID

Un STB real que descifra TV siempre solicita ECMs de los mismos 1–3 CAIDs (los del canal sintonizado). Un bot que enumera las capacidades del servidor prueba sistemáticamente decenas de CAIDs distintos en pocos segundos - esa diversidad estadística es la firma del probing.

Configuración de Anti-Probing

ECDH-first Handshake (Protocolo v2)

Además de los mecanismos activos de detección de scanners, el Protocolo v2 garantiza que las credenciales de usuario nunca viajan bajo la clave bootstrap conocida.

El servidor rechaza cualquier CMD_HELLO que llegue sin ECDH previo activo, registrando el evento en failban (P2P:hello_no_ecdh). Un cliente de protocolo <v2 no puede autenticarse.

Nonce monotónico anti-colisión

El nonce ChaCha20 de 12 bytes incorpora un contador monotónico por peer (tx_nonce_ctr, uint64_t) en sus primeros 8 bytes (XOR). Esto garantiza unicidad matemática entre paquetes dentro de una sesión sin depender únicamente de la aleatoriedad, eliminando la probabilidad de colisión por birthday paradox incluso en sesiones de ultra-larga duración.

🕸️ PIR - Peer Intelligence Ring

Cada nodo Candela defiende solo su propio perímetro. Con PIR la red se convierte en un sistema inmune distribuido: cuando un nodo detecta un scanner, ataque honeypot o fallo AEAD, comparte el evento con todos sus peers autenticados vía CMD_REP_SHARE. Los peers receptores añaden la IP a su watchlist local. Si esa IP intenta conectarse a ellos en las próximas 24h, ya están en alerta máxima.

Flujo de inteligencia colectiva

Tipos de evento compartidos

Rate limiting y anti-spam

Máximo pir_rate_limit eventos por minuto emitidos (default 5). En caso de ataque DDoS masivo que genere miles de events/segundo, PIR reduce automáticamente su emisión para no saturar los canales P2P con inteligencia.

Descubrimiento de peers - CMD_PEER_DISC (legacy)

Los peers con proto_ver < 35 envían CMD_PEER_DISC con hasta 16 peers conocidos. Los nodos modernos (v35+) lo procesan como entrada NETMAP (hops=1). Reemplazado por CMD_NET_MAP en proto_ver 35.

Config

🏠 LAN Discovery - Detección local UDP

Módulo que detecta automáticamente otras instancias de Candela en la misma red local (LAN) sin necesidad de configurarlas manualmente. Los peers descubiertos se muestran en el WebIf como candidatos a añadir en Config > Servidores.

Cómo funcióna

Al arrancar, Candela lanza un hilo de fondo (lan_disc_thread) que:

1. Abre un socket UDP con SO_BROADCAST + SO_REUSEADDR + SO_REUSEPORT enlazado al puerto 52700.
2. Cada 60 segundos envía un beacon UDP broadcast a 255.255.255.255:52700 con el formato:
   CANDELA_LAN_V1:<NodeID>:<puerto_p2p>:<nombre_operador>\n
3. Escucha beacons de otras instancias y los almacena en un ring buffer de 16 entradas con TTL de 300 segundos.
4. Filtra el propio beacon por NodeID para no añadirse a sí mismo.

Vista en WebIF

En la pestaña Mapa de Red, cuando hay peers descubiertos, aparece debajo de la tabla NETMAP una sección 🏠 Detectados en la LAN con:

• Nombre del operador (o NodeID si no tiene nombre)
• IP:puerto P2P anunciado
• NodeID (si está disponible)

API

Devuelve array JSON: [{"ip":"192.168.1.5","port":15000,"nodeid":"9F4E...","name":"Peer1","last_seen":1714500000}]

Archivos

Config

🗺 NETMAP - Network Topology Map

Descubrimiento de la topología completa de la red Candela mediante gossip P2P puro. Un nodo con un solo peer conocido aprende automáticamente la existencia de todos los demás nodos de la red. Cero credenciales viajan nunca - solo metadatos públicos (IP, puerto, nombre de operador, país, versión de protocolo), cifrados y autenticados con ECDH.

Comando CMD_NET_MAP = 0x16 (formato R38+)

Solo se acepta de peers con ECDH activo y autenticados. Payload:

CMD_NODE_INFO = 0x1A (formato R38+)

Enviado tras CMD_HELLO_ACK para anunciar metadatos propios al peer directo. 53 bytes:

Reglas de gossip

• Solo se envía a peers con ecdh_active=1 y authenticated=1.
• Al recibir CMD_NET_MAP, el nodo actualiza su tabla y reenvía solo si al menos una entrada es nueva o ha cambiado (R39 - evita bucles infinitos de retransmision).
• Tras CMD_HELLO_ACK se envía inmediatamente el mapa completo al nuevo peer.
• TTL de cada entrada: 24 horas desde last_seen. Expiradas → inactivas.
• Los nodos PEER_INCOMING (clientes entrantes) son visibles en el NETMAP global desde R38.
• R40 Si un nodo tiene el flag legacy_proto=1 (NewCamd/MGcamd server activo), este dato se propaga como cambio relevante y desencadena reenvío gossip. El flag se almacena en netmap_entry_t.legacy_proto y se expone en /api/peers/netmap como campo legacy_proto.

GSP - Gossip Selective Propagation (R39)

Sin GSP, cada CMD_NET_MAP envíaba la tabla completa de nodos conocidos, permitiendo a un actor con multiples peers autenticados enumerar toda la red en pocas peticiónes. GSP limita cuántas entradas se incluyen en cada gossip usando un shuffle aleatorio.

• Cada CMD_NET_MAP incluye como máximo netmap_gossip_max entradas (default 30), selecciónadas aleatoriamente con Fisher-Yates parcial sobre la tabla completa.
• El PRNG del shuffle se inicializa con RAND_bytes en cada arranque (no predecible entre sesiones).
• Con netmap_gossip_max=30 y una red de N nodos, un observador necesita del orden de N/30 peticiónes para enumerar todos los nodos, en lugar de recibirlos de golpe.

Config

📡 NSS - Node Status Signal

Cuando un nodo Candela se apaga de forma ordenada (SIGTERM/SIGINT), anuncia su baja a todos sus peers mediante CMD_GOING_DOWN = 0x15. Los receptores reinician inmediatamente el contador de reconexión sin esperar el timeout de socket (30–60s), eliminando la pantalla negra en apagados planificados.

Flujo

Config

⭐ NRS - Node Reputation Score

Cada servidor upstream recibe una puntuación de reputación 0–100 basada en su comportamiento histórico. El watchdog de reconexión ordena los servidores por NRS descendente - el de mayor score se intenta primero.

Fórmula

Un nodo nuevo comienza con score neutro (50). El factor de confianza hace que el score converja gradualmente hacia el valor real segun acumula historial (~10 muestras para confianza plena). Latencia actualizada con EWMA (a=0.2) en cada CMD_CW_RESP.

Bonus contribuidor (R38)

Los nodos con pir_auto_connect=1 y anon_peer_ips=0 son marcados como contribuidores: comparten peers descubiertos con la red. Reciben +10 puntos de bonus sobre su NRS Score (tope 100). En el WebIF aparecen con icono 🔥 en el mapa de red y en la lista de peers. El flag se propaga en CMD_NODE_INFO y CMD_NET_MAP.

Penalización legacy protocol (R40)

Los nodos que tienen activo un servidor NewCamd o MGcamd (newcamd_servers/mgcamd_servers con enabled=1) anuncian el flag legacy_proto en CMD_NODE_INFO y CMD_NET_MAP. Los peers que reciben este flag aplican una penalización de -8 puntos sobre el NRS Score de ese nodo (tope inferior 0). El flag se actualiza en tiempo real: si el operador desactiva los servidores legacy, la penalización desaparece en el siguiente anuncio.

En el WebIF el nodo afectado aparece con el icono 🔓 (candado abierto) junto al score NRS. El icono es visible tanto en el panel compacto de nodos como en la tabla completa del mapa de red. El tooltip indica el motivo. La penalización no excluye al nodo de AMPE, solo lo relega en el ranking respecto a nodos equivalentes sin legacy activo.

Eventos registrados

Config

🛡 Anti-Eclipse

Un atacante que controle suficientes nodos puede saturar la lista de peers de la víctima con nodos propios del mismo bloque IP, aislándola de la red real (ataque Eclipse). Anti-Eclipse limita cuántos peers activos pueden pertenecer al mismo bloque /24.

Funcionamiento

El watchdog verifica antes de cada intento de conexión cuántos peers activos ya provienen del mismo /24 que el servidor candidato (ip & 0xFFFFFF00). Si el recuento ≥ max_peers_per_subnet, el candidato se omite en ese ciclo.

Config

⚡ AMPE - Adaptive Multi-Path ECM

Extensión del motor HLS que consulta varios peers en paralelo por cada ECM en lugar de uno solo. La primera CW válida que llegue se entrega al receptor. El objetivo es eliminar los cortes de imagen cuando el peer prioritario tiene un pico de latencia puntual.

El problema que resuelve

Con ecm_multipath=1 (modo clásico), si el peer con mejor score tarda más de lo esperado (saturación, jitter de red), el receptor espera y puede producirse un corte. AMPE lanza la petición a N peers simultáneamente: si el primero tarda, el segundo o tercero ya tienen la respuesta lista.

Cómo funcióna

1. En cada tick del watchdog (~250ms), el motor HLS ordena todos los peers elegibles por score.
2. Con AMPE activo, en lugar de envíar CMD_ECM_REQ solo al top-1, lo envía a los top-N (según ecm_multipath).
3. Todos los peers envíados se marcan en tried_peers_map del slot ECM, evitando reenvíos duplicados en el mismo tick.
4. La primera CMD_CW_RESP válida que llegue se procesa según la lógica normal (CWS, ERD, FakeCW check). Las respuestas tardías de los otros peers actualizan igualmente su avg_latency.

Valores de ecm_multipath

• 0 — todos los peers elegibles reciben la ECM simultáneamente. Maxima redundancia; util en nodos de alta disponibilidad.
• 1 — modo clasico: un solo peer por ECM (comportamiento previo a AMPE).
• 2, 3, 4... — top-N peers por score reciben la ECM en paralelo. El valor 3 es el defecto desde R42.

No hay límite superior: cualquier valor entero positivo es válido. El motor envía solo a los peers disponibles; si hay menos de N, envía a todos sin generar peticiónes vacías.

Efecto en el scoring HLS

El scoring HLS sigue aprendiendo de forma correcta con AMPE:

• El peer ganador (más rápido) actualiza su avg_latency con el tiempo real.
• Los peers que responden (aunque lleguen tarde) también actualizan su latencia si el slot ECM todavía está activo.
• Los peers que no responden (timeout) reciben la penalización existente.

En la práctica, el scoring converge más rápido porque se obtienen N datos de latencia por ECM en lugar de 1.

Coste en red

Con ecm_multipath=N se multiplica por N el tráfico de peticiónes ECM al upstream. En redes con pocos peers disponibles el motor adapta el envío al número real de peers activos.

Límite de propagación de tarjeta (card_hop_limit)

Parametro complementario que controla hasta qué distancia (en saltos) puede llegar una tarjeta compartida desde su origen. Cuando un peer anuncia su card_map via CMD_CARD_MAP, las entradas con hop > card_hop_limit se descartan directamente: no se almacenan, no se usan y no se reenvían a otros peers.

• 0 — sin límite (comportamiento por defecto). Se aceptan tarjetas hasta hop 10 (límite absoluto contra propagación anómala).
• 1 — solo tarjetas directas: hop 0 (propias) y hop 1 (un salto desde el origen).
• N — se aceptan tarjetas con hasta N saltos de distancia. Maximo configurable: 10.

Útil para operadores que quieren garantizar que sus tarjetas no llegan a redes a las que no conocen. A diferencia del campo por cuenta max_hops y reshare_hops (que controlan qué se envía a un peer concreto), card_hop_limit actua en recepcion: filtra lo que Candela acepta de cualquier peer.

Prioridad por latencia en todas las fuentes locales

Ademas de ordenar los peers P2P por score HLS, Candela aplica selección por latencia media a todas las fuentes locales que pueden servir un mismo CAID:

• Lectores NewCamd cliente: si hay varias líneas NewCamd conectadas con el mismo CAID:PROVID, se usa siempre la que tiene menor avg_latency_ms histórico. Sin datos previos, el reader se trata como de alta latencia hasta acumular al menos una medición.
• Lectores MGcamd cliente: mismo mecanismo. El reader más rápido históricamente recibe la ECM primero.
• Lectores hardware físicos: cuando hay varios lectores compatibles y MCRR esta desactivado, se ordenan por avg_latency_ms antes de intentarlos. Con MCRR activo se respeta la asignacion determinista por SRVID.

La latencia se mide con CLOCK_MONOTONIC en cada descifrado éxitoso y se actualiza con EMA (70 % histórico, 30 % muestra nueva). El resultado es que, tras las primeras ECMs, el reader más rápido para cada CAID se seleccióna automáticamente sin configuración adicional.

Config

Se configuran desde Mantenimiento → Transporte y Anti-DPI → AMPE - Multi-Path ECM.

🛡 TAR - Anti-DPI Suite (Traffic Analysis Resistance)

Motivación: los vectores DPI que CTC y CPM no resuelven

CTC oculta el contenido (framing TLS) y resuelve el bloqueo por perfil de protocolo desconocido. CPM entierra el patrón temporal de latido DVB (silencio/ráfaga a intervalos de 10-15s). Sin embargo, un ISP con capacidad de DPI estadístico avanzado dispone de cuatro vectores adicionales que estos módulos no cubren:

PSN - Packet Size Normalization

Los paquetes salientes se normalizan a uno de cinco buckets de tamaño fijo antes de envíarse: 128 · 256 · 512 · 1024 · 1400 bytes. Cualquier payload se redondea al bucket superior más cercano y se rellena hasta ese tamaño con bytes pseudoaleatorios cifrados. El receptor descarta el relleno tras el descifrado ChaCha20-Poly1305 usando la longitud real incluida en la cabecera del paquete Candela.

• Elimina la distribución estadística de tamaños que distingue ECMs de CWs de chaff.
• La distribución resultante es discreta y uniforme - idéntica a TLS con registros de Application Data de tamaño estándar.
• Overhead: 0 a ~180 bytes por paquete dependiendo del bucket (media ~90 bytes).
• Config: enable_psn = 1 (activo por defecto).

ETJ - ECM Timing Jitter

Introduce un retardo pseudoaleatorio adicional antes de reenvíar cada ECM upstream: entre 0 y etj_max_ms ms (default: 400ms), generado con xorshift32 de forma que la distribución en frecuencia sea plana. La autocorrelación del periodo ECM (~10s) no es detectable aunque el observador acumule horas de tráfico.

• No afecta la latencia percibida: el margen del criptoperíodo DVB (~500ms-1s antes del corte) absorbe el jitter sin impacto visible.
• Config: enable_etj = 1, etj_max_ms (rango recomendado: 200-600ms).

CTF - Constant Traffic Floor

Mantiene un caudal mínimo constante de tráfico sintético hacia cada peer activo: ctf_floor_kbps kbps (default: 0 = desactivado). El relleno se emite como paquetes CMD_PADDING cifrados con ChaCha20-Poly1305+CTC, indistinguibles del tráfico real para cualquier observador externo. El resultado es un flujo con tasa de bits mínima garantizada similar a una descarga HTTPS de baja velocidad continua.

• Con CTF + CPM activos: tasa de bits mínima garantizada (CTF) y sin silencios > 3.5s (CPM). El perfil de caudal es el de una conexión HTTPS de streaming.
• Coste típico: 5-20 kbps por peer en routers domésticos; 50-100 kbps en VPS con pocos peers de alto tráfico.
• Config: ctf_floor_kbps (0 = desactivado; rango útil: 5-200 kbps).

TCR - TCP Connection Rotation

Rota la sesión TCP de forma transparente y periódica. El intervalo se programa como [N, 4×N] horas donde N = tcp_rotation_h, usando jitter xorshift32 para evitar sincronización entre nodos que arrancaron simultáneamente. El ISP nunca observa una conexión P2P con duración superior a 4×N horas - dentro del rango normal de sesiones HTTPS largas (streaming, llamadas, videoconferencia).

• La reconexión TCR se marca internamente como planificada, por lo que el contador de reconexiónes del dashboard no se incrementa - no genera falsa alarma.
• Transparencia: el peer acepta la nueva conexión con el handshake CTC+ECDH X25519 habitual. La caché CW y el buffer del receptor absorben los ~150-300ms de reconexión sin corte de imagen.
• Ejemplo: tcp_rotation_h = 6 → rotación entre las 6h y las 24h. Ninguna sesión TCP dura más de un día.
• Config: tcp_rotation_h (0 = desactivado; rango: 2-24h).

SCC - Simultaneous Channel Cap (R38)

Limita el número de SRVIDs (canales) distintos activos simultáneamente en el lector de tarjeta físico. Cuando el contador de canales activos alcanza scc_max_channels, los ECMs de canales nuevos se redirigen a P2P en lugar de ir a la tarjeta local. Un SRVID se considera activo mientras haya ECMs periódicos; expira tras scc_window_s segundos sin actividad.

• Para la CA de la operadora: el perfil de uso de la tarjeta no supera el de un suscriptor multi-room estándar.
• Transparente para el cliente: si hay P2P disponible para el canal bloqueado, el servicio continúa sin interrupción.
• Config: scc_max_channels (0 = desactivado), scc_window_s (default 30 s).

ETS - ECM Temporal Spreading (R38)

Cuando múltiples canales nuevos envían su primera ECM al lector en ráfaga simultánea (dentro de una ventana de 500 ms), cada ECM recibe un retardo pseudoaleatorio independiente de [1, ets_max_spread_ms] ms antes de llegar a la tarjeta. Durante el retardo, la ECM queda encolada con prioridad de reintento local (mecanismo HW_READER_ALL_BUSY); el watchdog la reintenta cada ~250 ms hasta que el spreading expira.

• El spreading solo aplica al primer ECM de cada SRVID nuevo en ráfaga. Las ECMs de refresco de canales ya activos (SRVID conocido en la tabla SCC) pasan sin retardo.
• Detección de ráfaga: si un solo canal inicia sin otros concurrentes en 500 ms, no hay delay - no penaliza el cambio de canal individual.
• Config: enable_ets (1 = activo por defecto), ets_max_spread_ms (default 2000 ms).

ECM Coalescing Agresivo (R38)

Algunos sistemas CA (especialmente Viaccess y variantes Nagra) generan ECMs con payload ligeramente distinto en cada criptoperíodo aunque la CW resultante sea la misma: añaden un nonce interno o timestamp propio. El caché por hash de ECM exacto no detecta estos duplicados y el lector hardware recibe peticiónes redundantes. El Coalescing resuelve esto deduplicando por CAID+PROVID+SRVID dentro de una ventana temporal.

• Si el lector resolvió una ECM para el mismo canal en los últimos ecm_coalesce_window_ms ms, se reutiliza la CW sin tocar el hardware.
• Complementario al caché CW existente: el caché actúa sobre el hash exacto de ECM; el Coalescing actúa sobre el canal independientemente del payload.
• La ventana máxima (9000 ms) es inferior al criptoperíodo DVB estándar (10 s), por lo que no hay riesgo de servir una CW caducada.
• Config: ecm_coalesce_window_ms (0 = desactivado; rango útil: 4000-7000 ms).

ECM Relay - Anti-correlación de tráfico (R39)

Enruta ECMs hacia el destino a través de un nodo P2P intermediario (relay), de forma que un observador externo (ISP, sonda de red) que analice metadatos de conexión TCP no puede correlacionar directamente quién originó la petición con quién la resolvió. El relay no tiene acceso al contenido, que viaja siempre cifrado ChaCha20-Poly1305.

• Flujo: origen envía la ECM al relay (CMD_ECM_RELAY); el relay la reenvía al destino (CMD_ECM_REQ); el destino resuelve la CW y la devuelve al relay; el relay la reenvía al origen (CMD_ECM_RELAY_RESP). El relay nunca tiene acceso al contenido, siempre cifrado.
• Compatible con AMPE: cada path paralelo usa un relay distinto; si no hay relay disponible para un path concreto, ese path cae a directo sin afectar a los otros.
• La tabla interna de seguimiento soporta hasta 64 peticiónes simultáneas con timeout de 10 s por entrada.
• Config: enable_ecm_relay (0 = desactivado por defecto).

MCRR - Multi-Card Round-Robin (R39)

Distribuye los ECMs entre múltiples lectores de tarjeta físicos presentes en el mismo nodo. El lector asignado se calcula como SRVID % num_readers, lo que hace la asignación determinista (el mismo canal siempre va al mismo lector) y compatible con la caché CW. Si el lector asignado está al límite de paralelismo configurado, la iteración circular avanza al siguiente lector compatible.

• El lector virtual MOSC siempre se intenta primero, antes de aplicar MCRR. No entra en la rotación.
• Pre-scan de lectores compatibles: solo participan en la rotacion los lectores en estado READY, habilitados, con CAID y PROVID coincidentes. El lector virtual MOSC se excluye de la rotacion y siempre se intenta primero.
• Si no hay lectores compatibles el watchdog deriva la petición a P2P automáticamente.
• Config: enable_mcrr (0 = desactivado por defecto).

Cobertura total acumulada

Config

Todos los parámetros se configuran desde WebIf → Mantenimiento → Transporte y Anti-DPI.

Control avanzado de caché, CW Cycle Check y DoubleCheck por CAID

Nuevos parámetros de configuración para control granular de memoria de caché CW/ECM, Cycle Check avanzado y DoubleCheck selectivo por CAID.

Control de memoria de caché

CW Cycle Check avanzado

Los parámetros avanzados se muestran en el WebIF solo cuando cw_cycle_check = 1.

DoubleCheck por CAID

WebIF

• Inputs numéricos para cw_cache_memory, ecm_cache_size, ecm_cache_memory en la tarjeta "Control de CW".
• Sección avanzada de Cycle Check con v-if="cwCycleCheck": lista CAID, maxlist, keeptime, selector de sensibilidad (1/2/3), toggle usecwcfromce.
• Input double_check_caid con v-if="configObj.enable_doublecheck".
• Traducciones en 6 idiomas: ES, EN, DE, FR, IT, PT.

Mejoras de seguridad incluidas en R35