Soluzione per i dati sensibili del negozio senza accesso ad esso

1

Ho bisogno di sviluppare un sistema in cui dobbiamo archiviare dati sensibili crittografati, ma non ho accesso diretto ad esso.

Ciò che penso è qualcosa come una coppia di chiavi private / public-ish . Conserveremmo il privato per crittografare i dati che gli utenti possono inserire e fornire loro la chiave public-ish . I dati possono essere decifrati solo utilizzando entrambi i privati e i public-ish .

In questo modo, possiamo archiviare i dati, ma non abbiamo accesso ad essi. Inoltre, una volta che gli utenti vogliono ottenere le loro informazioni, dovranno informare la loro chiave, in modo che possiamo decrittografarla e inviarla indietro.

Ha senso? C'è uno standard crittografico per qualcosa di simile? O c'è un altro concetto / sistema crittografico che potrei usare in questo caso?

Grazie!

    
posta jonatas.baldin 20.07.2017 - 04:06
fonte

2 risposte

2

Dalla tua descrizione, presumo che tu (A) non abbia effettivamente bisogno di accedere ai dati degli utenti (B) in qualsiasi momento? Vale a dire. I dati di un negozio B, niente di più.

Se è così, tutta la tua idea suona male.

Qualcosa sulla normale crittografia asimmetrica prima:

  • La chiave pubblica è usata per en crypt. La chiave pubblica, non la chiave privata. L'idea è che decifrare sia difficile. Non sarà difficile se ti serve la chiave pubblica.
  • Non c'è qualcosa come una chiave pubblica / semi-privata. Uno dei due portachiavi può sempre calcolare anche l'altra chiave (ma non viceversa), cioè la chiave privata può essere utilizzata per calcolare la chiave pubblica.
  • Non esiste uno schema di crittografia (singolo) asimmetrico in cui la decifrazione richiede entrambe le chiavi. Potresti usare due coppie di kay, es. 4 chiavi, per fare qualcosa del genere, ma non una singola coppia pubblica / privata.

Detto questo, il prossimo problema è la tua definizione di "archiviazione senza accesso". Se A vuole archiviare dati senza avere accesso, perché B dovrebbe inviare i dati semplici ad A? Perché è esattamente quello che stai proponendo: B invia i dati ad A in modo che A possa crittografarli. Prima di crittografare, A ha accesso in abbondanza. Stessa storia dopo quando viene decifrato di nuovo sul lato A prima che i dati vengano inviati a B.

Terzo, A dà a B una chiave e in seguito B rimanda la chiave ad A? Come sei sicuro che A non manterrà la chiave per avere accesso in ogni momento? E perché le chiavi vengono mandate in giro?

Cosa potresti fare (ed è molto più semplice): A memorizza i dati, come hai detto tu, e niente di più . Non inventare strategie di crittografia non biologiche coinvolgenti entrambe le parti. Se B vuole che i dati siano privati, B può crittografare i dati da solo, con le proprie chiavi e i propri metodi, prima inviandoli ad A. A non otterrà mai alcuna chiave.

E se hai questo, dovresti pensare anche a integrità + autenticità.

    
risposta data 20.07.2017 - 04:54
fonte
0

Se si dispone di una coppia di chiavi asimmetrica (chiave pubblica e chiave privata): se si cripta la chiave pubblica, la chiave privata viene utilizzata per eseguire la decrittografia e viceversa. Non si usano entrambi contemporaneamente per eseguire la decrittografia. Non sei sicuro che si tratti di un fraintendimento del sistema di chiavi o solo un refuso?

In secondo luogo, le chiavi asimmetriche tendono a essere una cattiva scelta per la crittografia di grandi quantità di dati. Sarebbe preferibile un algoritmo a chiave simmetrica come AES, per ulteriori informazioni vedere: RSA vs AES

Se si desidera che l'utente sia in grado di memorizzare i dati, non è possibile decrittografarli per poi decodificarli in un secondo momento. Potrebbe essere più sensato per l'utente crittografarlo con una chiave simmetrica come AES sul lato client prima di riceverlo. Quindi possono richiedere i dati crittografati e decodificarli autonomamente.

Non sono sicuro se stai suggerendo all'utente di inviare dati non criptati, che poi cripterai con una chiave privata? Che viene poi restituito a loro per la decrittazione con una chiave pubblica alla loro fine? In quel caso i dati non crittografati sono ancora esposti a voi all'inizio. Mi scuso ancora se ho male interpretato!

    
risposta data 20.07.2017 - 17:41
fonte

Leggi altre domande sui tag