Segurança do hardware: o que o Kshana faz com o hardware e o que nunca faz

Estado: revisão jurídica pelo proprietário pendente. As notas jurídicas abaixo são a leitura que os responsáveis pela manutenção fazem de fontes públicas, escritas para que um utilizador saiba onde estão os limites. Não são aconselhamento jurídico, não foram revistas por um advogado e a lei difere de país para país. Leia-as como um motivo para consultar um advogado, não como uma permissão.

Software de caráter consultivo para investigação, simulação e ensaio. Não é um equipamento homologado e não classifica nem aprova um recetor, um relógio ou um laboratório. Ver a declaração consultiva no README.

A regra#

A receção é o produto. A transmissão nunca faz parte do motor aberto.

O Kshana não contém qualquer código que controle um transmissor. Não existe nenhum caminho de transmissão SDR (nenhuma chamada de transmissão UHD, HackRF, bladeRF ou Soapy), e nenhuma forma de onda de jamming ou de spoofing é escrita num ficheiro destinado a reprodução.
Os ficheiros que o Kshana escreve (cenas IQ, gravações SigMF e ION .sdrx, exportações NMEA e de bench) descrevem sinais ou movimento simulados e legítimos, e os metadados que o Kshana escreve para uma cena indicam que foi escrita por kshana iq scene (o comentário ION .sdrx indica que se trata de uma cena simulada, não de uma gravação).
Quando uma experiência necessita de RF numa bancada, é o equipamento do próprio operador que a produz, no recinto do próprio operador, sob a autorização do próprio operador. O Kshana regista o que o operador afirma ter sido feito e nunca o infere.

Fases#

Cada fase indica o que o Kshana faz, que equipamento está envolvido, quem emite RF (se alguém o fizer) e a condição que tem de se verificar antes de o Kshana tratar o resultado como evidência.

Fase	Papel do Kshana	Equipamento	Emissão de RF	Condição	Estado na 0,38
0	Ficheiros: registos de reprodução, IQ, exportações de bench, NMEA ou UBX em direto através de stdin, TCP ou UDP	none	none	none	incluída
1	Receção passiva: recetores só de leitura; registos de temporização (linuxptp, chrony, TICC); CSV de IMU; `iq monitor --follow` num ficheiro SigMF em crescimento	os recetores, o grandmaster e o SDR em receção do utilizador	none	qualquer escrita de configuração num recetor exige um `--configure` explícito; a predefinição é só de leitura	parcialmente incluída: formatos de registos de temporização, `holdover-test`, `iq monitor --follow`; a entrada de recetor série está prevista
2	Orquestração de laboratório sem RF do Kshana: uma especificação das condições de ensaio, passos do operador (retirar a antena, iniciar o simulador) pedidos e com marca temporal, pontuação de ida e volta e evidências	simuladores do laboratório, caixas blindadas	apenas pelo simulador do laboratório, por condução	um `lab-attestation` assinado (abaixo) registado no pacote de evidências; o Kshana recusa pontuar uma execução de laboratório sem ele	o registo está implementado nos pacotes de evidências; a recusa de pontuar sem ele ainda não (não existe nenhum comando de execução de laboratório)
3	Reprodução por condução de cenas IQ GNSS legítimas: o Kshana escreve o ficheiro da cena e o utilizador reproduz-o com a sua própria ferramenta, através de um cabo com atenuadores e de um dispositivo em ensaio num recinto de RF	o SDR, os atenuadores e o recinto do utilizador	apenas por condução, da responsabilidade do utilizador	nenhum código de transmissão no motor aberto; as formas de onda de interferência e de spoofing ficam fora do âmbito; revisão de controlo de exportações; assessoria jurídica	não consta do motor aberto; um item da edição comercial a tratar com assessoria jurídica
4	Hardware-in-the-loop de RF em malha fechada e em tempo real	equipamento de parceiros	parceiro	integrar antes através da especificação da fase 2	não prevista

"Incluída" significa que o código consta desta versão. Nada nesta tabela afirma que alguma fase tenha sido utilizada com algum parceiro, laboratório ou autoridade; nenhuma foi.

Princípios#

A receção é o produto, e a transmissão nunca consta do código aberto.
Cada sessão de hardware produz um pacote de evidências com os hashes das entradas, das condições e dos limiares utilizados.
Uma atestação de condução ou de blindagem é registada, nunca inferida.
Os números provenientes de hardware permanecem MODELLED até que uma referência independente externa concorde (por exemplo, uma trajetória de referência de laboratório ou um relógio de referência). Um limiar fixado antecipadamente não é afrouxado depois de uma execução.
As antenas com diagramas controlados, as unidades inerciais e os relógios atómicos à escala de chip são tratados como fontes de dados (diagramas, registos, curvas de estabilidade publicadas), e não como dispositivos que o Kshana controla.
Formulação: um resultado é "medido face à máscara" ou "fornece elementos de prova em apoio de" um requisito. O Kshana não afirma que um dispositivo satisfaz uma norma, e ninguém o classificou nem aprovou.

Notas jurídicas (revisão jurídica do titular pendente)#

Receber sinais GNSS é legal em quase todo o lado. Transmitir em bandas GNSS não é.

Estados Unidos. A interferência deliberada em radiocomunicações é proibida ao abrigo de 47 U.S.C. §333, e a FCC atua contra os jammers (https://www.fcc.gov/general/jammer-enforcement). Uma transmissão a partir de uma bancada pode chegar para além da bancada.
Noutros países. Os responsáveis pela manutenção não reviram a legislação de outros países. A comunidade em torno do gps-sdr-sim declara que transmitir a sua saída é proibido por lei na maioria dos países; deve tratar-se isso como pressuposto de trabalho onde a assessoria jurídica não tenha dito o contrário.
Uma montagem blindada ou por condução é uma salvaguarda, não uma licença. A atestação abaixo regista a salvaguarda que o operador afirma ter estado em vigor. Não torna lícita nenhuma emissão.
Gravação. Gravar sinais de rádio pode suscitar questões de privacidade e de legalidade em alguns locais. O iq monitor --follow e qualquer receita de captura são apenas de receção, e o operador é responsável pelo local e pelo que grava.
Controlo de exportações. O software de hardware-in-the-loop que controla geradores de sinais pode estar abrangido por regras de controlo de exportações. É por isso que a fase 3 fica fora do motor aberto.
Nada aqui constitui um aval ou um acordo. Nenhum regulador, campo de ensaios, laboratório ou fornecedor foi consultado sobre este documento nem acordou seja o que for do seu conteúdo.

O campo `lab-attestation`#

Da fase 2 em diante, uma execução que envolva equipamento de laboratório inclui um objeto lab-attestation, registado no pacote de evidências junto dos hashes das entradas. É uma declaração de um operador identificado, não uma medição, e o Kshana não a 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

O que está implementado na 0,38:

kshana receiver-trust evidence ... --lab-attestation <file.toml> valida o ficheiro e regista a atestação no manifest.json do pacote. O manifesto é coberto pela assinatura Ed25519 do pacote, pelo que o registo não pode ser editado sem quebrar a verificação. O mesmo está disponível como argumento lab_attestation do evidence_create de Python e como argumento lab_attestation_toml da ferramenta MCP create_evidence_pack (a versão de navegador não cria pacotes).
Um pacote criado sem atestação é, byte a byte, o que era antes.
kshana evidence verify comunica a atestação e indica que é "atestada pelo operador identificado; não verificada pelo Kshana".
Uma atestação que esteja incompleta, ou cujo setup não seja conducted nem shielded (uma montagem por via aérea não é aceite como execução de laboratório), é recusada e não é criado nenhum pacote.

O que não está ainda implementado: a regra da fase 2 segundo a qual o Kshana recusa pontuar uma execução de laboratório sem atestação. Nenhum comando aceita uma opção de execução de laboratório na 0,38, pelo que não há nada a recusar; a regra chegará com os comandos de orquestração de laboratório. Uma atestação regista a declaração do operador sobre uma salvaguarda. Não torna lícita nenhuma emissão e não altera a etiqueta de um resultado: uma execução de laboratório pontuada é MODELLED, a menos que uma referência independente externa concorde.

O que isto significa para quem contribui#

Não adicione ao motor aberto um caminho de transmissão, uma dependência de transmissão nem um exemplo de transmissão.
Não adicione um gerador de formas de onda cuja saída seja um sinal de jamming ou de spoofing destinado a reprodução.
As novas entradas de hardware são só de leitura por predefinição; uma escrita exige uma opção explícita e uma linha neste ficheiro.
Um novo comando que toque em hardware consta de todas as superfícies ou é marcado como N/A com uma justificação em SURFACES.md, e indica aqui a sua fase.