Saltar al contenido
Financial Context Wiki

Riesgo del comite de disponibilidad de datos (DAC)

Guia orientada a la verificacion de atestaciones DAC, reglas de aceptacion q-de-n, posesion y recuperacion reales de los datos, dominios de fallo correlacionados, rotacion de claves, retencion, mecanismos alternativos y riesgo de salida.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversion. Invertir puede ocasionar perdidas.

Respuesta directa

Un comite de disponibilidad de datos es un conjunto acotado de miembros cuyas firmas o atestaciones pueden satisfacer la regla de un protocolo para aceptar una afirmacion de disponibilidad de datos fuera de la cadena. El certificado solo demuestra que el conjunto de claves configurado y el umbral aceptaron un objeto firmado concreto conforme a esas reglas. No demuestra por si solo que cada firmante obtuvo todos los bytes, conservo una copia duradera, atiende ahora a los usuarios, valido la ejecucion o hizo definitivo el asentamiento.

La seguridad y la actividad son distintas. Si el contrato acepta firmas q-of-n, el control de q claves validas puede satisfacer esa regla para un objeto no disponible, salvo que otra comprobacion lo impida. Con menos de q firmantes dispuestos y accesibles normalmente no puede formarse un certificado nuevo, por lo que las actualizaciones se detienen o recurren a un mecanismo alternativo documentado. La recuperacion efectiva tambien depende de comprobaciones honestas previas a la firma, copias independientes, retencion, capacidad de servicio, historial de claves y gobierno, y software ejecutable de reconstruccion y salida.

Como funciona

  1. Fijar el despliegue: cadena, modo y version del protocolo, contratos de asentamiento y verificacion de disponibilidad, lote y objeto de datos, codificacion, compromiso, conjunto de claves, umbral q, numero de miembros n, firmantes obligatorios, activacion, vencimiento, revocacion y autoridad de gobierno.
  2. Reconstruir la afirmacion firmada exacta y la logica de aceptacion. Verificar dominio, vinculacion con cadena y contrato, identificador del lote, compromiso o raiz de estado, vencimiento, mapa de bits de firmantes o agregacion, proteccion contra repeticion y calculo real del umbral en el contrato. El logotipo de un miembro o una respuesta de API no es la regla de aceptacion.
  3. Exigir que cada miembro obtenga el objeto completo antes de firmar, compruebe su compromiso y codificacion, lo decodifique y conserve los datos necesarios para derivar el estado o ejecutar la salida de un usuario de forma independiente. Documentar que atestiguan los miembros y si el protocolo puede probar que esas comprobaciones ocurrieron.
  4. Cartografiar dominios de fallo independientes en vez de contar nombres. Identificar entidades juridicas, control efectivo, cuentas y regiones de nube, DNS y redes, software y bases de datos, custodia de claves, almacenamiento, operaciones y jurisdiccion. Espejos o endpoints bajo un mismo plano de control no son miembros independientes.
  5. Probar posesion y recuperacion. Obtener lotes recientes e historicos de varios miembros sin la API del operador, verificar hashes y raices, reconstruir el estado o una prueba de retiro, medir retencion y transferencia, y distinguir produccion del certificado, recuperacion presente, validez de ejecucion, finalidad del consenso y durabilidad del archivo.
  6. Ejercitar el ciclo de vida y la recuperacion: rotacion de miembros y claves, conjuntos historicos, vencimiento y revocacion, disponibilidad inferior al umbral, compromiso de claves de umbral, servicio selectivo, caida del operador, alternativa con datos completos, modo de congelacion o escape, inclusion forzada, archivos independientes y gas y tiempo reales necesarios para salir.
  7. Supervisar mapas de firmantes aceptados, demora del certificado, exito de recuperacion, integridad de bytes, antiguedad del almacenamiento, cambios de conjunto y umbral, actualizaciones, pausas y capacidad alternativa. Archivar certificados, datos y estado contractual, y dejar de aumentar la exposicion si se aceptan certificados pero la recuperacion independiente deja de funcionar.

Ejemplos resueltos

  • Actividad y seguridad del umbral no son lo mismo. En un comite didactico 5-of-7, dos miembros no disponibles dejan 5 firmantes y aun puede formarse un certificado nuevo; tres dejan 4, por lo que 4 < 5 y la produccion se detiene salvo que exista una alternativa documentada. A la inversa, controlar 5 claves aceptadas permite satisfacer el umbral; el certificado sigue sin demostrar recuperacion actual de bytes ni validez de ejecucion.
  • Modelo de disponibilidad independiente. Supongase, solo como modelo IID didactico, que cada uno de 7 miembros esta disponible de forma independiente con probabilidad 0.95 y el certificado exige al menos 5. Entonces P(quorum) = sum(C(7,k) * 0.95^k * 0.05^(7-k), k=5..7) = 0.9962429570, de modo que la probabilidad modelizada de parada es 1 - 0.9962429570 = 0.0037570430. Dependencias compartidas de nube, software, operador, regimen juridico o claves invalidan esta estimacion binomial.
  • Copias almacenadas y servicio son conceptos distintos. Un lote ocupa 120 MB. Siete copias completas e independientes almacenarian 120 * 7 = 840 MB; si solo tres miembros lo conservan realmente, se almacenan 120 * 3 = 360 MB aunque hayan firmado cinco claves. Servir una vez el objeto a 100 clients transfiere 120 * 100 = 12,000 MB: el numero de firmas no es ni numero de copias ni medida de capacidad de transferencia.
  • Umbral de reconstruccion. Un objeto didactico contiene 1,024 records divididos en 16 chunks de 64 records, con umbral declarado de recuperacion de 12 chunks. Once fragmentos exponen 11 * 64 = 704 records, pero 11 < 12, por lo que el objeto no puede reconstruirse conforme a esa regla. Un certificado valido del comite no sustituye un fragmento ausente ni cambia el umbral.

Riesgos

  • Examinar una cadena, contrato, despliegue, lote o version de protocolo incorrectos.
  • Reconstruir mal la afirmacion firmada, el dominio, el compromiso o el vencimiento.
  • Aceptar repeticiones entre cadenas, contratos, versiones o conjuntos historicos.
  • Usar un conjunto de claves invalido, obsoleto, vencido o revocado.
  • Interpretar mal q, n, los firmantes obligatorios, mapas de bits o firmas agregadas.
  • Explotacion de un fallo del firmante o de la verificacion contractual.
  • Firmar antes de obtener, comprobar y conservar todos los datos.
  • Aceptar datos parciales, mal formados o codificados incorrectamente.
  • Perder seguridad por compromiso o colusion de claves de umbral.
  • Perder actividad porque menos miembros que el umbral pueden firmar.
  • Contar como independientes entidades, nubes, regiones u operadores correlacionados.
  • Compartir planos de control de DNS, TLS, software, bases de datos o almacenamiento.
  • Sufrir ataques eclipse, servicio selectivo o dependencia de una pasarela privada.
  • Borrar o podar datos despues de firmar o antes de terminar la ventana de salida.
  • Romper la recuperacion historica por cambios de miembros o rotacion de claves.
  • Permitir que el gobierno sustituya miembros, reduzca el umbral o eluda demoras.
  • Referirse a un compromiso de asentamiento obsoleto, inseguro o reorganizado.
  • Tratar una prueba de validez o una raiz finalizada como recuperacion actual.
  • Descubrir que la alternativa, congelacion, inclusion forzada o salida no es ejecutable.
  • Subestimar almacenamiento, transferencia, recuperacion, alternativa, tarifas o capacidad.

Errores comunes

  • Mas miembros implican automaticamente mas dominios de fallo independientes.
  • q firmas prueban que existen q copias completas duraderas y publicamente recuperables.
  • Una prueba de validez elimina la necesidad de verificar la disponibilidad del DAC.
  • Un certificado antiguo valido garantiza recuperacion actual y archivo permanente.
  • Un miembro honesto u oficial garantiza que todo usuario siempre pueda salir.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...