Come definire i requisiti di sicurezza per garantire che gli sviluppatori ... non forniscano sicurezza per oscurità?

Un esempio è il sistema di criptaggio dei contenuti per impedire la copia dei DVD. Mentre il sistema di scrambling era sconosciuto, questo ha funzionato. Poi un adolescente chiamato Jon Lech Johansen l'ha capito, ha scritto DeCSS ed era rotto.

Come sottolinea @GrahamLee, i meccanismi di sicurezza che devono essere fatti valere devono funzionare anche se conosciuti dai cattivi.

Al giorno d'oggi la crittografia fornisce sicurezza in così tante applicazioni, quindi è fondamentale che sia implementata correttamente. Poiché la matematica è al di là della maggior parte delle persone, esiste una scuola di pensiero che sostiene la pubblicazione degli algoritmi e che consente alle persone di tutto il mondo di cercare di trovare difetti. Il lato positivo: molti occhi. Il rovescio della medaglia: se l'algoritmo è già implementato, un utente malintenzionato può trovare un difetto ed essere in grado di usarlo, quindi è molto utile farlo prima dell'implementazione.

L'altro punto di vista è nascondere l'algoritmo per impedire agli hacker di sapere come funziona - Il problema con l'oscurità è che è stato dimostrato più volte che affidarsi alla sicurezza attraverso l'oscurità fallisce perché a un certo punto i cattivi scoprono il segreto .

Vale la pena leggere questo post di Bruce Schneier - un noto avversario della sicurezza attraverso oscurità e autore di vari algoritmi crittografici che sono stati testati dalla comunità - come esempio di dove l'oscurità ha funzionato, ma solo perché i criminali non hanno appreso del piano.

Non so se sia possibile rispondere veramente all'ultima parte della tua domanda senza più contesto. Ad esempio, se questo è per codice sviluppato da terze parti, potresti richiedere una revisione del codice, ma ciò che potresti davvero cercare è una terza parte che pubblica i loro algoritmi / codice ecc. Come open source.

Il controesempio canonico alla sicurezza attraverso l'oscurità è il principio di Kirchkoffs: i progettisti di crittografia dovrebbero supporre che il sistema crittografico verrà catturato dal nemico, quindi dovrebbe essere sicuro se tutto ciò che lo riguarda tranne la chiave è noto.

Si noti tuttavia che questo non dice che l'oscurità è cattiva e non dovrebbe essere invocata: dice che l'oscurità non può essere la difesa solo . Questo perché è fragile. Ma l'oscurità può ancora rallentare o dissuadere gli aggressori non qualificati.

L'oscurità è ciò che non può essere quantificato.

La corretta sicurezza viene fornita con le stime dei costi. Diciamo che una chiave di crittografia a 128 bit è sicura perché possiamo stimare quanto costerebbe (in processori dedicati e potenza elettrica, e in definitiva in dollari) per trovare la chiave con una ricerca esauriente (cercando tutte le possibili chiavi a 128 bit). Quando il costo è molto più alto di quello che un attaccante sarebbe disposto a spendere e, in particolare, quando è molto più alto di quello che qualsiasi attaccante con tecnologia terrestre potrebbe spendere, allora abbiamo raggiunto la sicurezza.

Quando una tale stima non è possibile, allora è la sicurezza dall'oscurità. Ad esempio, supponiamo di avere una sorta di sistema di crittografia su un software che tu tenga segreto. Quanto è segreto quel software? È scritto su alcuni dischi rigidi. È stato sviluppato da qualche parte, esiste un codice sorgente per esso, memorizzato da qualche parte. Quanto è difficile per un utente malintenzionato recuperare l'algoritmo? I file memorizzati perdono in molti luoghi, ad es. vecchi computer scartati, laptop rubati, indiscrezioni dai subappaltatori (il codice sorgente del software è nei file, ma anche nel cervello di alcuni programmatori) ... se l'hacker può impossessarsi del binario, può smontarlo, un processo che è non immediato ma limitato solo dall'intelligenza dell'attaccante.

Il punto di tutto questo è che mentre si esegue un codice segreto di sicuro rende l'attività più difficile per l'utente malintenzionato, è molto difficile dire quanto più difficile diventa, quando si desidera esprimerlo in dollari.

Quindi ecco la mia risposta alla tua domanda: per impedire agli implementatori di utilizzare la sicurezza per oscurità, impone loro di produrre stime giustificate dettagliate dei costi per gli attacchi.

Se stai cercando di costruire linee guida di codifica sicure per gli sviluppatori interni, quella ruota è già stata inventata. OWASP , ad esempio, ha una vasta panoramica che include le ingiunzioni contro l'affidamento sulla sicurezza attraverso l'oscurità; e CERT ha standard molto dettagliati per C e C ++.