Seguridad del hardware: qué hace Kshana con el hardware y qué no hace nunca

Estado: revisión jurídica del propietario pendiente. Las notas jurídicas de más abajo son la lectura que hacen los responsables de fuentes públicas, escrita para que el usuario sepa dónde están los límites. No son asesoramiento jurídico, no las ha revisado un abogado y la ley difiere según el país. Léalas como un motivo para consultar a un abogado, no como un permiso.

Software de carácter consultivo para investigación, simulación y ensayo. No es un equipo homologado y no califica ni aprueba un receptor, un reloj ni un laboratorio. Véase la declaración de carácter consultivo en el README.

La regla#

Recibir es el producto. Transmitir nunca forma parte del motor abierto.

• Kshana no contiene ningún código que controle un transmisor. No hay ninguna ruta de transmisión SDR (ninguna llamada de transmisión de UHD, HackRF, bladeRF o Soapy), y ninguna forma de onda de jamming o spoofing se escribe en un archivo destinado a su reproducción.
• Los archivos que escribe Kshana (escenas IQ, grabaciones SigMF e ION .sdrx, exportaciones NMEA y de bench) describen señales o movimientos simulados y legítimos, y los metadatos que Kshana escribe para una escena indican que la escribió kshana iq scene (el comentario de ION .sdrx indica que es una escena simulada, no una grabación).
• Cuando un experimento necesita RF en un banco de pruebas, la produce el equipo propio del operador, en el recinto propio del operador y bajo la autorización propia del operador. Kshana registra lo que el operador dice que se hizo y nunca lo infiere.

Etapas#

Cada etapa indica qué hace Kshana, qué hardware interviene, quién emite RF (si alguien lo hace) y la puerta de control que debe satisfacerse antes de que Kshana trate el resultado como evidencia.

"Incluido en la versión" significa que el código está en esta versión. Nada de esta tabla afirma que ninguna etapa se haya usado con ningún socio, laboratorio o autoridad; ninguna lo ha sido.

Principios#

1. Recibir es el producto, y transmitir nunca forma parte del código abierto.
2. Cada sesión de hardware produce un paquete de evidencias con los hashes de las entradas, las condiciones y los umbrales usados.
3. Una atestación de conducción o de apantallamiento se registra, nunca se infiere.
4. Las cifras que proceden del hardware siguen siendo MODELLED hasta que una referencia independiente externa coincida (por ejemplo, una trayectoria de verdad de laboratorio o un reloj de referencia). Un umbral fijado de antemano no se relaja después de una ejecución.
5. Las antenas con diagramas controlados, las unidades inerciales y los relojes atómicos a escala de chip se tratan como fuentes de datos (diagramas, registros, curvas de estabilidad publicadas), no como dispositivos que Kshana controla.
6. Redacción: un resultado está "medido frente a la máscara" o "aporta evidencias a favor de" un requisito. Kshana no dice que un dispositivo alcance una norma, y nadie lo ha calificado ni aprobado.

Notas jurídicas (revisión jurídica del propietario pendiente)#

Recibir señales GNSS es legal casi en todas partes. Transmitir en las bandas GNSS no lo es.

• Estados Unidos. La interferencia deliberada en las radiocomunicaciones está prohibida por 47 U.S.C. §333, y la FCC actúa contra los inhibidores (https://www.fcc.gov/general/jammer-enforcement). Una transmisión desde un banco de pruebas puede llegar más allá de este.
• En otros lugares. Los responsables no han revisado la legislación de otros países. La comunidad de gps-sdr-sim afirma que transmitir su salida está prohibido por ley en la mayoría de los países; trátese como supuesto de trabajo dondequiera que un asesor jurídico no haya indicado otra cosa.
• Una configuración apantallada o por conducción es una salvaguarda, no una licencia. La atestación que figura más abajo registra la salvaguarda que el operador dice que estaba en vigor. No hace lícita ninguna emisión.
• Grabación. Grabar señales de radio puede plantear cuestiones de privacidad y de legalidad en algunos lugares. iq monitor --follow y cualquier receta de captura son solo de recepción, y el operador es responsable de dónde y qué graba.
• Control de exportaciones. El software de hardware en el bucle que controla generadores de señal puede estar sujeto a normas de control de exportaciones. Por eso la etapa 3 queda fuera del motor abierto.
• Nada de lo aquí expuesto es un aval ni un acuerdo. Ningún regulador, campo de pruebas, laboratorio o proveedor ha sido consultado sobre este documento ni ha acordado nada de lo que contiene.

El campo lab-attestation#

Desde la etapa 2 en adelante, una ejecución que haya implicado equipo de laboratorio lleva un objeto lab-attestation, registrado en el paquete de evidencias junto a los hashes de las entradas. Es una declaración de un operador identificado, no una medición, y Kshana no la verifica.

[lab-attestation]                                     # or the same keys at the top level of the file
operator = "name or role of the person responsible"   # required
organisation = "laboratory or company"                # required
date = "2026-11-02"                                   # required, the day of the session
setup = "conducted"                                   # required: "conducted" or "shielded"
attenuation_db = 60.0                                 # required for "conducted": total, emitter to device
enclosure = "RF-shielded box, model and ID"           # required for "shielded"
emitter = "laboratory-owned simulator, model"         # required: what produced any RF
statement = "No emission outside the enclosure or cable path."   # required, free text
signature = "ed25519:..."                             # optional: the operator's own detached signature, recorded as given

Lo que está implementado en 0,38:

• kshana receiver-trust evidence ... --lab-attestation <file.toml> valida el archivo y registra la atestación en el manifest.json del paquete. El manifiesto queda cubierto por la firma Ed25519 del paquete, de modo que el registro no puede editarse sin romper la verificación. Lo mismo está disponible como el argumento lab_attestation de evidence_create en Python y el argumento lab_attestation_toml de la herramienta create_evidence_pack de MCP (la compilación para navegador no crea paquetes).
• Un paquete creado sin atestación es, byte a byte, idéntico a lo que era antes.
• kshana evidence verify informa de la atestación y dice que está "atestada por el operador indicado; no verificada por Kshana".
• Una atestación incompleta, o cuyo setup no es ni conducted ni shielded (una configuración por el aire no se acepta como ejecución de laboratorio), se rechaza y no se crea ningún paquete.

Lo que no está implementado todavía: la regla de la etapa 2 por la que Kshana se niega a puntuar una ejecución de laboratorio que no tenga atestación. Ningún comando admite un indicador de ejecución de laboratorio en 0,38, así que no hay nada que rechazar; la regla llegará con los comandos de orquestación de laboratorio. Una atestación registra la declaración del operador sobre una salvaguarda. No hace lícita ninguna emisión y no cambia la etiqueta de un resultado: una ejecución de laboratorio puntuada es MODELLED a menos que una referencia independiente externa coincida.

Qué significa esto para quien contribuye#

• No añada una ruta de transmisión, una dependencia de transmisión ni un ejemplo de transmisión al motor abierto.
• No añada un generador de formas de onda cuya salida sea una señal de jamming o de spoofing destinada a su reproducción.
• Las nuevas entradas de hardware son de solo lectura por defecto; una escritura requiere un indicador explícito y una línea en este archivo.
• Un comando nuevo que toque hardware se incluye en todas las superficies o se marca como N/A con un motivo en SURFACES.md, e indica aquí su etapa.