Protezione delle API machine-to-machine non consumer con Crittografia su SSL

Question

Protezione delle API machine-to-machine non consumer con Crittografia su SSL

#1 da (2 voti)
#2 da (0 voti)

0

Sto lavorando su un'API destinata a essere utilizzata da un altro sistema. I dati non sono di proprietà della macchina richiedente e degli utenti a cui i dati appartengono non stanno guidando la transazione. Si potrebbe pensare ad esso come lo stesso caso d'uso di un servizio web ospedaliero che trasferisce dati sensibili e le persone che possiedono i dati non sono coinvolti nella transazione. Oppure un servizio web bancario che viene utilizzato per eseguire query analitiche su molti dati dell'utente, ma gli utenti nei dati non stanno guidando la transazione.

problema

Sto studiando autenticazione e amp; Opzioni di autorizzazione per questo caso d'uso, ma quasi tutti i documenti che trovo per la sicurezza delle API passano a OAuth 2 ea volte OpenID Connect. Non credo che siano applicabili, se leggo correttamente le RFC. Sembrano concentrarsi sulla delega dell'autenticazione a una terza parte con il presupposto che un utente verrà quindi autenticato.

Soluzione che sto considerando

Ho preso in considerazione un token HMAC nell'intestazione Autorizzazione della richiesta in cui i dettagli della richiesta sono codificati e firmati con una chiave che l'app client è stata data una volta. Lo stesso flusso dello schema di autenticazione di AWS per le proprie API. L'unica cosa a cui posso pensare è più sicura di questo è lo scambio di chiavi di crittografia pubbliche e il client che cripta la richiesta con la mia chiave pubblica e mi fa crittografare la risposta con la loro (PGP / RSA Encryption). Entrambe le opzioni sarebbero su TLS con verifica del certificato. Sto reinventando la ruota qui? Esiste uno standard comparabile di regole da seguire per questo caso d'uso?

Side-note sulla crittografia su SSL

Ho sentito dire che una volta la crittografia su SSL era ridondante. Ho appena visto Moxie Marlinspike lacerare SSL a Defcon attraverso un uomo nel mezzo e lo spoofing della catena di certificati. Esiste sicuramente una grande differenza tra il processo di scambio dei certificati incluso in SSL che si verifica in ogni sessione e quello che avviene solo una volta per ciò che ho delineato sopra.

oauth encryption hmac oauth2 rsa

posta Usman Mutawakil 01.04.2017 - 07:48

fonte

2 risposte

Leggi altre domande sui tag oauth encryption hmac oauth2 rsa

HTTPS per reti private Domanda sulla gestione delle informazioni della carta di credito nel programma di vendita

score 2 · Answer 1

È necessario separare l'autenticazione dall'autorizzazione. OAuth 2.0 e OpenID Connect sono un sistema per la gestione principalmente dell'autorizzazione, non dell'autenticazione.

HMAC è un metodo per la firma simmetrica. Ti dà l'integrità e l'autenticazione parziale, ma non il non ripudio.

La crittografia della chiave pubblica è una crittografia asimmetrica. Ti dà riservatezza. Si noti tuttavia che la crittografia di per sé non garantisce l'integrità o l'autenticazione. Per aggiungere questi aspetti a un sistema di crittografia PKI, vengono utilizzati firma digitale e certificati. La firma digitale fornisce anche un limitato non ripudio.

Non c'è davvero alcuna differenza tra gli utenti sulle macchine, l'utente per l'utente o l'autenticazione da macchine a macchine. Una comunicazione da macchina a macchina è meno probabile che possa lamentare l'inconveniente di alcuni schemi, ma le tattiche utilizzate per mitigare modelli specifici di minacce sono esattamente le stesse.

La maggior parte dell'autenticazione da utente a macchina utilizza la password. In machine-to-machine, questa è chiamata autenticazione pre-shared key (PSK). TLS può essere configurato per utilizzare TLS-PSK, anche se questa è una configurazione relativamente rara.

È anche possibile utilizzare una PSK per creare un codice di autenticazione dei messaggi (MAC). Un MAC afferma che i dati non sono stati modificati durante il trasporto. TLS firma i dati con MAC per l'integrità, oppure puoi aggiungere HMAC a qualsiasi messaggio in qualsiasi protocollo, ma non sostituirlo con la firma non ripedibile.

In alcune impostazioni di sicurezza più elevate, il sistema potrebbe necessitare di uno schema che impedisca la manomissione delle richieste / documenti e impedisce all'utente / macchina di negare successivamente la richiesta / il documento. Questo non rifiuto è fornito dalla firma digitale. È possibile utilizzare la firma GPG o S / MIME per questo. Si noti che esiste una limitazione al non ripudio dalla firma digitale, in quanto il firmatario può semplicemente richiedere che la propria chiave privata venga compromessa. In molte situazioni, rivendicare un compromesso chiave ha spesso conseguenze meno gravi rispetto all'ammettere di aver firmato la richiesta / documento.

È possibile utilizzare una crittografia asimmetrica ogni volta che si ha bisogno di una capacità asimmetrica. Ad esempio, se si desidera consentire a una macchina di scrivere su una memoria di dati, ma impedire a detta macchina di leggere i dati memorizzati in futuro (o impedire la compromissione di detta macchina per consentire a un utente malintenzionato di decrittografare i dati memorizzati), allora può usare la crittografia asimmetrica.

In molti scenari di sistema distribuito, vorresti anche essere in grado di dimostrare il sequenziamento o la tempistica degli eventi. Molti sistemi utilizzavano blockchain per dimostrare il sequenziamento dei messaggi. In alternativa, alcuni potrebbero utilizzare un'autorità di timestamping. Una blockchain ampiamente distribuita, come la block chain di bitcoin, può anche essere utilizzata come autorità di timestamp decentralizzata.

score 0 · Answer 2

Either option would be over TLS with certificate verification. Am I re-inventing the wheel here? Is there a comparable standard of rules to follow for this use case?

La tua preoccupazione di base sembra essere quella che potresti difenderti usando blocco della chiave - che farebbe la guardia contro il tipo di MITM / spoofing che hai menzionato nella tua domanda.

Supponendo che sia correttamente implementato.

Anche se aggiungendo un altro livello di crittografia solo per il gusto di farlo sembrare ridondante, potrebbero esserci dei casi in cui potrebbe essere giustificato - è necessario verificare se questo è il tuo caso. Ad esempio, posso immaginare che potrebbero esserci casi in cui potresti voler memorizzare alcuni dati nella sua forma crittografata, in modo che solo i consumatori autorizzati possano leggerli.

Questo, tuttavia, non ha nulla a che fare con il perché vorresti usare TLS.

Potresti prendere in considerazione Token Web JSON per alcune delle tue esigenze di base all'interno della tua applicazione. Sembrerebbe una corrispondenza abbastanza vicina per:

an HMAC token in the Authorization header of the request in which the request details are encoded and signed with a key the client app was given once