Cómo evitar que los participantes hagan trampas al establecer una estructura similar a OpenPGP

Navega tus respuestas
3

Me gustaría compartir documentos dentro de los grupos y asegurarme de que el miembro de cada grupo solo pueda acceder a los documentos compartidos en su grupo. También quiero asegurarme de que ninguna de las partes pueda hacer trampa en el proceso de creación de esta arquitectura.

Situation:

Hay5participantes(A,B,C,D).Haydosgrupos(azul:A,B,D,rojo:D,C).AyBsolopuedenverdocumentosazules(comoDocument_1)yCsolopuedenverdocumentosrojos(comoDocument_2).Dpuedeverlosdocumentoscompartidosenambosgrupos.

Enfoque:Elsiguienteenfoqueescercanoalenfoqueen Tom Leeks responde y está cerca de OpenPGP. Se toma este enfoque, ya que se escala a grupos con muchos usuarios.

Ejemplo para grupo azul:

  • A genera un par de claves. Clave pública: pk_a. Clave privada / secreta: sk_a
  • B genera el par de claves pk_b, sk_b
  • C genera el par de claves pk_c, sk_c
  • pk_a, pk_b, pk_c se publican en un servidor de claves, visible para el público
  • A (o cualquier miembro del grupo azul) genera una clave simétrica s1
  • A calcula pk_b (s1) (s1 cifrado con pk_b) y pk_c (s1).
  • A publica pk_b (s1) y pk_c (s1) en el servidor
  • B y C ahora pueden tomar esos valores y descifrarlos usando theis sk
  • A, B, C ahora conocen S1 y pueden compartir datos dentro del grupo azul
  • Si están publicando datos en el grupo azul, pueden usar su sk para indicar a los demás que realmente fueron enviados por ellos
  • hacemos lo mismo para el grupo rojo con la clave simétrica S2

Problema: ¿Cómo podemos asegurarnos de que A envíe la clave simétrica correcta? A podría querer excluir B y enviar pk_b (Sx) en lugar de pk_b (S1). B quedaría excluida de la comunicación.

Idea:

  • A está publicando un entero aleatorio "a B" sk_a (pk_b (int)). Para autenticarse, lo está cifrando con su clave secreta
  • B toma ese valor incrementándolo y lo publica en C sk_b (pk_d (int + 1))
  • D está publicando sk_d (pk_a (int + 2))
  • A puede confirmar que las cosas son correctas y que efectivamente recibió su entero original, incrementado en 2
  • A publica sk_a (pk_b (int + 3))
  • B puede confirmar que las cosas están correctas
  • B publica sk_b (pk_d (int + 4))
  • D puede confirmar que las cosas están correctas

¿Este enfoque tiene sentido? ¿Hay una solución más elegante o eficiente?

    
pregunta User12547645 02.11.2018 - 08:28
fuente

1 respuesta

1

Parece que está intentando realizar un intercambio de claves multipartidista para los fines de cifrado de difusión.

En su situación, no confía en que los usuarios envíen a todos los miembros de su grupo una clave simétrica válida (S1), pero confía en que un servidor de claves enumere correctamente las claves públicas de todos los participantes. Si presume que el servidor de claves es confiable (podría serle a cualquiera de los miembros del grupo si fuera malicioso), ¿no podemos también asignarle la función de generar la clave simétrica y difundirla al grupo?

Supongamos que no podemos confiar en que el servidor de claves genere la clave simétrica y la envíe a todos los participantes del grupo. La solución que propusiste requiere mucha comunicación.

Aquí está mi sugerencia: 

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))))

El mensaje que recibe A de D se puede verificar utilizando todas las claves públicas para verificar la cadena de firmas.

Cada participante puede hacer hash del NONCE que recibe y verificar que coincida con el hash firmado por A.

    
respondido por el Daisetsu 04.11.2018 - 03:33
fuente

Lea otras preguntas en las etiquetas

claves de gnupg y base de datos de paso - Protegiendo tanto de pérdidas y accesos no autorizados ¿Cómo guarda Google la información de autenticación en el navegador? [duplicar]