Utilizzo delle firme digitali per identificare gli utenti

I miei pensieri vanno nella giusta direzione secondo me, anche se spero di poterti convincere a seguire un percorso leggermente diverso.

Analizziamo i tuoi requisiti:

• Si desidera garantire richieste autenticate reciprocamente per l'elaborazione dei pagamenti, ovvero un client che avvia tale processo vorrebbe essere sicuro di parlare con il server giusto e un server che accetta una richiesta vorrebbe essere sicuro dell'identità del pari. Quindi la soluzione deve avere l'autenticazione del server più l'autenticazione del client

• L'integrità delle richieste è un'altra: nessuno dovrebbe avere la possibilità di modificare qualcosa nella richiesta mentre è in corso

Questi erano i requisiti principali che hai elencato. Aggiungerei anche la privacy al mix: probabilmente non vorresti che nessuno ascoltasse nel traffico per poter imparare ciò che il cliente ha acquistato o la somma di denaro che paga.

E ora arriva la parte difficile. Puoi davvero raggiungere questi obiettivi con un mix di crittografia asimmetrica e simmetrica. Ma penso che uno schema manuale non sia appropriato qui, ed ecco i motivi per cui:

• Stai provando a proteggere transport e la protezione è effimera - una volta completata la transazione, non devi più persistere i dati della richiesta (a meno che non provi a stabilire un audit trail)

• Assicurando il trasporto, in questo momento stai progettando un protocollo di sicurezza. E farli bene è probabilmente uno dei problemi più difficili nella crittografia. Se hai letto il protocollo Needham-Schroeder : sono morti sul serio riguardo a questo protocollo per una coppia di anni, convinto che andava perfettamente bene. E avevano tutto il diritto di farlo, essendo decorati crittografi e tutto il resto. Ma tre anni dopo è stato presentato un attacco valido ... probabilmente sai dove sto andando e tu stesso hai già menzionato le varie cose di cui dovresti preoccuparti quando cerchi di rendere sicura questa cosa ...

Ma non tutto è perduto, perché c'è già un protocollo perfetto che fa tutto quanto sopra e molto altro per te. È TLS! Supporta tutte le tue esigenze ed è stato testato da milioni di persone, quindi è improbabile che la tua soluzione manuale non sarà in grado di competere comunque. E sul lato positivo, è anche già supportato in tutti i linguaggi di programmazione più diffusi, non è necessario inventare nulla.

PS : quando utilizzare le firme rispetto a quando utilizzare TLS: mi ha sempre aiutato ad analizzare la mia situazione facendomi questa domanda: "Vuoi proteggere il trasporto?" "Vuoi proteggere i dati / documenti?"

Quello che stai cercando di ottenere è chiamato non ripudio (vedi link ).

Firma con una chiave privata del certificato fornirà un'origine per la non ripudio. La firma digitale è normalmente considerata personale quindi raccomando che ogni individuo abbia un certificato separato per la firma digitale. Ciò elimina anche qualsiasi confusione su chi ha firmato la richiesta, poiché ogni persona può firmare solo per se stessa. I certificati di firma possono essere generati da un'autorità di certificazione (CA) interna in cui il sistema è presente o fornito dall'utente da un'autorità emittente esterna.

In breve:

Bob knows that Alice sent the payment request. Alice cannot deny she sent the payment request.

Questo perché:

• Alice ha inviato la richiesta di pagamento che è stata sottoposta a hash (per evitare manomissioni) e quindi l'hash è crittografato con la chiave privata di Alice, creando una firma della richiesta originale. La richiesta conterrebbe i dettagli o l'ID utente di Alice nel sistema. L'hash e la firma si limitano a fare in modo che non venga alterato in alcun modo.

• Bob ha la chiave pubblica di Alice (che verosimilmente verrà archiviata nel sistema) in modo che possa cancellare la richiesta originale e decodificare la firma della richiesta. Ciò consente a Bob di sapere che la richiesta è stata inviata da Alice confrontando i due hash (perché il suo nome è nella richiesta e la sua chiave pubblica ha decrittografato l'hash) e la richiesta non è stata alterata.

• Bob può confrontare i campi del certificato per determinare che Alice proviene dall'azienda che afferma di essere.

Vedi qui per un riferimento visivo: link

Nota:

• Ciò non garantisce che solo Bob e Alice possano leggere la richiesta, che sarebbe la crittografia (messaggio o trasporto).
• La firma con una chiave privata del certificato garantisce che il messaggio non venga manomesso.
• I metadati nella richiesta / messaggio identificheranno che Alice ha inviato la richiesta.

Inoltre, se si emette da una CA interna, è possibile estendere gli attributi del certificato per includere un limite di delega che è spesso importante in materia finanziaria. Il certificato dice che Alice può solo ordinare $ 30.000 o meno.