Come impedire ai partecipanti di barare quando si stabilisce una struttura simile a OpenPGP

Naviga le tue risposte
3

Vorrei condividere i documenti all'interno dei gruppi e assicurarmi che il membro di ciascun gruppo possa accedere solo ai documenti condivisi nel suo gruppo. Voglio anche assicurarmi che nessuna delle parti possa imbrogliare nel processo di creazione di questa architettura.

Situazione:

Cisono5partecipanti(A,B,C,D).Cisonoduegruppi(blu:A,B,D,rosso:D,C).AeBpossonovederesolodocumentiblu(comeDocumento_1)eCpossonovederesolodocumentirossi(comeDocumento_2).Dpuòvedereidocumenticondivisiinentrambiigruppi.

Approccio:Ilseguenteapproccioèvicinoall'approccioin risposta di Tom Leeks ed è vicino a OpenPGP. Questo approccio è preso, perché si adatta ai gruppi con molti utenti.

Esempio per il gruppo blu:

  • A genera una coppia di chiavi. Chiave pubblica: pk_a. Chiave privata / segreta: sk_a
  • B genera una coppia di chiavi pk_b, sk_b
  • C genera una coppia di chiavi pk_c, sk_c
  • pk_a, pk_b, pk_c sono pubblicati su un server delle chiavi, visibili al pubblico
  • A (o qualsiasi membro del gruppo blu) genera una chiave simmetrica s1
  • A calcola pk_b (s1) (s1 crittografato con pk_b) e pk_c (s1).
  • Un post pk_b (s1) e pk_c (s1) al server
  • B e C possono ora prendere quei valori e decodificarli usando theis sk
  • A, B, C ora conoscono S1 e possono condividere i dati all'interno del gruppo blu
  • Se pubblicano dati nel gruppo blu, possono usare il loro sk per indicare agli altri che è stato davvero inviato da loro
  • facciamo lo stesso per il gruppo rosso con il tasto simmetrico S2

Problema: Come possiamo assicurarci che A invii effettivamente la chiave simmetrica corretta? A potrebbe voler escludere B e inviare pk_b (Sx) invece di pk_b (S1). B sarebbe escluso dalla comunicazione.

Idea:

  • A sta postando un numero intero casuale "a B" sk_a (pk_b (int)). Per autenticarsi, lo sta crittografando con la sua chiave segreta
  • B prende quel valore lo incrementa e lo invia a C sk_b (pk_d (int + 1))
  • D sta postando sk_d (pk_a (int + 2))
  • A può confermare che le cose sono corrette e che ha effettivamente ricevuto il suo intero originale, incrementato di 2
  • A post sk_a (pk_b (int + 3))
  • B può confermare che le cose sono corrette
  • B post sk_b (pk_d (int + 4))
  • D può confermare che le cose sono corrette

Questo approccio ha senso? Esiste una soluzione più elegante o efficiente?

    
posta User12547645 02.11.2018 - 08:28
fonte

1 risposta

1

Sembra che tu stia tentando di eseguire uno scambio di chiavi multipartitico ai fini della crittografia broadcast.

Nel tuo scenario non ti fidi che gli utenti inviino a tutti nel loro gruppo una chiave simmetrica valida (S1), ma ti stai fidando di un server chiave per elencare correttamente le chiavi pubbliche per tutti i partecipanti. Se si presume che il server delle chiavi sia affidabile (potrebbe essere utile a qualcuno dei membri del gruppo se fosse malevolo), allora non possiamo anche assegnargli la funzione di generare la chiave simmetrica e diffonderla nel gruppo?

Supponiamo che non possiamo fidarci del server delle chiavi per generare la chiave simmetrica e inviarla a tutti i partecipanti del gruppo. La soluzione che hai proposto richiede molta comunicazione.

Ecco il mio suggerimento: 

Group: A, B, D
A -> B: pk_b(NONCE), sk_a(hash(NONCE))
B -> D: pk_d(NONCE), sk_b(sk_a(hash(NONCE)))
D -> A: pk_a(NONCE), sk_d(sk_b(sk_a(hash(NONCE))))

Il messaggio A ricevuto da D può essere verificato utilizzando tutte le chiavi pubbliche per verificare la catena di firme.

Ogni partecipante può cancellare la NONCE che riceve e verificare che corrisponda all'hash firmato da A.

    
risposta data 04.11.2018 - 03:33
fonte

Leggi altre domande sui tag

In che modo Google salva le informazioni di autenticazione nel browser? [duplicare] Quando viene respinta una email?