Origens: um manual militar, e não um slogan

O princípio vem de Auguste Kerckhoffs, escrevendo em 1883 sobre cifras militares. Entre seis requisitos que enunciou, o que sobreviveu diz que um sistema não deve exigir sigilo, e precisa poder cair nas mãos do inimigo sem inconveniente.

Lido com atenção, aquilo não é proibição de segredos. É uma afirmação sobre qual segredo sustenta a segurança. O desenho pode ser público; a chave é o que precisa ser privado. O raciocínio de Kerckhoffs era operacional, e não filosófico: uma cifra é usada por muitas pessoas, em campo, por anos. Pessoal muda e equipamento é capturado, então um sistema cuja segurança depende de ninguém descobrir como ele funciona tem uma segurança que vence na primeira vez que ele é perdido.

depois comprimiu isso na forma que a maioria conhece: presuma que o inimigo conhece o sistema. Mesma afirmação, sem nenhuma suavização.

Em 1975, Saltzer e Schroeder a inscreveram numa lista de princípios de projeto para proteção em sistemas computacionais, como desenho aberto: o mecanismo não deve depender da ignorância dos atacantes, e deve estar aberto a revisão. Puseram-na ao lado de padrões seguros por omissão, menor privilégio e economia de mecanismo, e o argumento deles acrescentou algo que Kerckhoffs não tinha - que um desenho público é examinado, e exame é como falhas são achadas antes da implantação, e não depois.

A distinção que o slogan perde

Duas coisas são rotineiramente chamadas de obscuridade, e elas se comportam de forma diferente:

Uma dependência. O sistema é seguro porque um atacante não sabe algo estrutural - o algoritmo, o protocolo, o desenho interno, o fato de existir uma interface de gerência. É isso que o princípio proíbe, e a razão é empírica, e não moral: esse conhecimento sempre vaza, por desmontagem, por gente de dentro, por documento de licitação, ou por alguém com uma chave de fenda e tempo.

Uma camada. O sistema é seguro por outros motivos, e a obscuridade adicionalmente eleva o custo para atacantes oportunistas. Tirar o da porta 22 remove quase todo o ruído automatizado dos logs. Não defende de ninguém que esteja de fato atacando você, e torna os logs legíveis, o que tem valor operacional real.

A confusão entre as duas produz dois erros opostos. Uma equipe entrega um produto cuja segurança é um protocolo secreto e chama isso de defesa em profundidade. Outra recusa uma medida barata de redução de ruído porque um princípio mandou. O teste é o que continua verdadeiro se a obscuridade for removida: se a resposta for "nada", era dependência; se for "a mesma segurança, com mais ruído", era camada.

O registro: sistemas que dependeram disso

O argumento está resolvido empiricamente, e os exemplos têm formato constante.

  • O A5/1, a cifra de voz do GSM, foi desenhado em segredo nos anos 1980, vazou e foi submetido a engenharia reversa nos anos 1990, e quebrado com ataques ao alcance de hardware comum.
  • O CSS, a proteção de conteúdo do DVD, manteve algoritmo e tratamento de chaves confidenciais; uma vez extraído, o esquema caiu em pouco tempo, e o esforço do sigilo comprou alguns anos.
  • O MIFARE Classic, largamente implantado em transporte e controle de acesso, usava cifra proprietária que foi recuperada do silício e mostrada fraca, e depois disso o parque implantado não podia simplesmente ser recolhido.
  • Equipamentos de votação e de jogos, em que várias jurisdições trataram o código-fonte como confidencial e descobriram, na revisão que enfim aconteceu, que a confidencialidade vinha substituindo a correção.

O padrão é idêntico sempre: o segredo durou um tempo, sua revelação foi involuntária, e o custo da substituição caiu sobre o operador, e não sobre quem desenhou. Os sistemas não falharam por serem secretos; eles eram fracos, e o sigilo adiou a descoberta para o momento menos conveniente.

Onde esconder é legítimo

O princípio é mais estreito que a fama dele, e o que segue não o viola:

  • Chaves, credenciais, tokens e certificados. O desenho inteiro pressupõe que sejam privados. Confundir chave com obscuridade é a leitura errada mais comum da máxima.
  • Detalhe de configuração que seria útil a um atacante - endereçamento interno, topologia, inventário de software. Publicar não ajuda ninguém a defender, e tratar isso como sensível não é dependência de segurança.
  • Banners de versão e verbosidade de erro. Suprimi-los evita identificação trivial e não elimina nada; mantenha a versão corrigida, e não apenas escondida.
  • Portas fora do padrão, port knocking, autorização por pacote único. Legítimos como elevadores de custo e redutores de ruído, ilegítimos como a razão de um serviço estar seguro.
  • Não publicar uma vulnerabilidade sem correção enquanto o conserto é preparado. Isso é coordenação, e não obscuridade - o desenho segue aberto, e o adiamento é limitado e acordado.

A discussão sobre divulgação é a mesma discussão

Todo debate sobre divulgação de vulnerabilidade é este princípio aplicado a um defeito específico. A divulgação completa sustenta que publicar força o conserto e arma quem defende; a não divulgação protege usuários que ainda não podem corrigir e, na prática, protege fabricantes do constrangimento; a divulgação coordenada é o meio-termo em que o campo se acomodou, com prazo anexado, porque sem prazo a segunda posição engole a primeira.

O prazo é a parte que sustenta o resto, e ele existe exatamente pelo que Kerckhoffs descreveu: presumir que só quem reportou sabe é inseguro, já que o mesmo defeito está ao alcance de qualquer outro que olhe.

O que levar disso

Enuncie o segredo. Para qualquer sistema que você opere ou compre, nomeie aquilo cuja revelação o quebraria. Se a resposta for uma chave, o desenho é sólido. Se for um documento, um algoritmo ou a ausência de curiosidade, o desenho tem uma dependência que não consegue honrar.

Faça a mesma pergunta ao fabricante, direto. "O que acontece com a segurança de vocês se um concorrente obtiver este ?" é pergunta justa, de resposta curta, e a qualidade da resposta informa, seja qual for o conteúdo.

Mantenha as obscuridades baratas e pare de defendê-las como segurança. Porta fora do padrão e banner discreto valem a pena pela mesma razão que log limpo vale a pena, o que é argumento de manutenção, e não de segurança - e é bem mais fácil de defender nesses termos.

Fontes