> Esta traducción se ofrece por comodidad. El texto normativo es el original en inglés. # Modelo de seguridad **Especificación del Meta-Universo** **ID del documento:** MU-V2-FED-012 **Título:** Modelo de seguridad y modelo de amenazas de la federación **Clase de documento:** normativo **Versión:** 2.0 (borrador) **Estado:** borrador de trabajo **Referencias normativas:** MUC, [MUFP](../03-federation/MUFP.md), [MUFP-Messages](../03-federation/MUFP-Messages.md), [Trust-Model](../03-federation/Trust-Model.md), [Consent-and-Disclosure](../03-federation/Consent-and-Disclosure.md), [MMAS-Interchange](../02-architecture/MMAS-Interchange.md), RFC 2119 **Referencias informativas:** [Identity-Binding](../03-federation/Identity-Binding.md), [Conflict-Resolution](../03-federation/Conflict-Resolution.md), [Traceability](../02-architecture/Traceability.md) **Copyright:** © Orkestron.AI **Licencia:** Apache-2.0 --- # 1. Propósito Este documento define el **modelo de seguridad** de la federación del Meta-Universo: el modelo de amenazas, las protecciones que toda implementación DEBERÁ ofrecer, el cálculo del [vector de confianza](../03-federation/Trust-Model.md), la mecánica de la revocación y el tratamiento de la privacidad y de los datos personales. Existe porque **la confianza no es la seguridad** ([MUC, artículo 15](../01-constitution/Meta-Universe-Constitution.md)). Establecer confianza responde a *"¿creo quién eres y qué modelas?"*; la seguridad responde a *"¿puede garantizarse la integridad, la autenticidad y la confidencialidad de lo que intercambiamos con independencia de la confianza?"*. Hacen falta las dos. --- # 2. Alcance Este documento se aplica al canal de federación y a todo artefacto que lo atraviesa: sobres, proyecciones, contratos, vínculos de identidad, correspondencias semánticas y eventos. No impone una suite criptográfica concreta; impone las propiedades que esa suite DEBERÁ proporcionar. --- # 3. Principios de seguridad - **La confianza no es la seguridad.** La seguridad DEBERÁ sostenerse incluso cuando la confianza es alta. - **Verificar y solo entonces usar.** Todo artefacto recibido DEBERÁ autenticarse y comprobarse en su integridad antes de influir en decisión alguna. - **Mínimo conocimiento por construcción.** El protocolo DEBERÁ hacer difícil la divulgación excesiva, no meramente desaconsejarla. - **La historia es prueba.** Los sucesos relevantes para la seguridad DEBERÁN registrarse como [eventos](../04-core-concepts/Event.md) inmutables. --- # 4. Activos y fronteras de confianza Los activos que una federación debe proteger: | Activo | Por qué importa | |-------|----------------| | Vínculos de identidad | Un vínculo falsificado permite a un atacante suplantar el enlace entre dos entidades reales. | | Correspondencias semánticas | Una correspondencia envenenada cambia el significado en silencio al cruzar la frontera. | | Proyecciones | El conocimiento efectivamente divulgado; el objetivo de la confidencialidad. | | Eventos y linaje semántico | El registro de la verdad; envenenarlo corrompe toda conclusión derivada. | | Contratos | La base de autorización de toda divulgación. | | Estado de confianza | Determina lo permitido; su corrupción escala privilegios. | La frontera de confianza es el borde de cada Universo soberano. Todo lo que la cruza es no confiable hasta que se verifica. --- # 5. Modelo de amenazas Para cada amenaza principal, la mitigación REQUERIDA: | # | Amenaza | Mitigación (DEBERÁ) | |---|--------|--------------------| | T1 | **Identidad suplantada / vínculo de identidad falsificado** | Autenticar la parte `from` de cada sobre; ligar todo acuerdo de identidad a evidencia verificable y a una firma; rechazar los vínculos no verificables. | | T2 | **Carga útil manipulada** (modelo, proyección, correspondencia) | Verificar la [huella semántica](../02-architecture/MMAS-Interchange.md) de toda carga MUIF al recibirla; fallar con `MUFP-E-FINGERPRINT-MISMATCH`. | | T3 | **Correspondencia semántica envenenada** | Las correspondencias DEBERÁN declarar una autoridad y quedar fijadas por huella a versiones concretas de los modelos; una correspondencia que no case con ambas huellas DEBERÁ rechazarse. | | T4 | **Envenenamiento de eventos o del linaje** | Los eventos DEBERÁN ser inmutables y firmados en su procedencia; los hechos derivados DEBERÁN ser recomputables a partir de eventos de origen firmados. | | T5 | **Fuga de proyección / divulgación excesiva** | Ninguna proyección DEBERÁ devolverse sin un contrato aceptado y un propósito declarado; los campos fuera del contrato DEBERÁN omitirse al generarla, no filtrarse después. | | T6 | **Repetición** de un sobre capturado | Los sobres DEBERÁN llevar un `messageId` único y `sentAt`; los receptores DEBERÁN rechazar duplicados y marcas de tiempo caducadas fuera de una ventana acordada. | | T7 | **Intermediario** en el canal | El enlace de transporte DEBERÁ proporcionar cifrado autenticado (por ejemplo, TLS); los sobres DEBERÍAN además firmarse de extremo a extremo. | | T8 | **Escalada de privilegios por confianza o contrato caducados** | La revocación DEBERÁ surtir efecto de inmediato y propagarse (sección 8); las referencias a elementos revocados DEBERÁN fallar con `MUFP-E-REVOKED`. | | T9 | **Repudio** | Las acciones relevantes para la seguridad (vinculación, divulgación, revocación) DEBERÁN registrarse como eventos firmados, preservando el no repudio. | | T10 | **Denegación de servicio** | Los puntos de acceso DEBERÍAN limitar la tasa (`MUFP-E-RATE-LIMITED`) y acotar el coste de la validación y del cálculo de huellas. | --- # 6. Autenticación e integridad del sobre - Todo [sobre MUFP](../03-federation/MUFP-Messages.md) DEBERÍA llevar una `signature` desprendida sobre la **forma canónica** del sobre (según [MMAS-Interchange](../02-architecture/MMAS-Interchange.md)) con el campo `signature` eliminado. La canonicalización hace que los bytes firmados sean reproducibles entre implementaciones. - El receptor DEBERÁ verificar la firma contra una clave ligada a la identidad `from` antes de actuar sobre el mensaje. Un sobre sin firmar DEBERÁ tratarse como **no verificado** y NO DEBERÁ usarse para divulgar conocimiento protegido. - Toda carga MUIF dentro del cuerpo DEBERÁ superar por su cuenta la verificación de huella (T2), de modo que un sobre válido no pueda colar un modelo manipulado. --- # 7. Cálculo del vector de confianza El [modelo de confianza](../03-federation/Trust-Model.md) define seis dimensiones. Esta sección las hace calculables para que una `TrustResponse` sea reproducible y explicable. Cada dimensión se puntúa en `[0.0, 1.0]` a partir de entradas declaradas y verificables: | Dimensión | Se puntúa a partir de | |-----------|-------------| | `identity` | fuerza de la autenticación de la identidad de la contraparte (por ejemplo, DID verificado, cadena de certificados) | | `semantic` | nivel de validación de los modelos de la contraparte (V0-V5) y calidad de las correspondencias | | `governance` | evidencia de madurez de gobernanza (auditorías, certificaciones) | | `contract` | historial de contratos cumplidos frente a incumplidos | | `operational` | disponibilidad / capacidad de respuesta / conformidad del punto de acceso | | `historical` | duración e historial de incidentes de la federación previa | Una decisión de federación es una **función del vector y del propósito**, no un solo escalar. Una política DEBERÁ definir, por propósito, la puntuación mínima exigida en cada dimensión; una solicitud se acepta solo si cada dimensión exigida alcanza su umbral. La decisión DEBERÁ registrar el vector y la política aplicada, para poder explicarla, trazarla y revisarla. La confianza NO DEBERÁ reducirse a un único número promediado que oculte una dimensión suspensa. --- # 8. Revocación y propagación La confianza, los contratos y los vínculos de identidad son revocables en cualquier momento mediante un mensaje `Revoke` ([MUFP-Messages §9](../03-federation/MUFP-Messages.md)). - La revocación DEBERÁ surtir efecto en cuanto se recibe y DEBERÁ registrarse como un [evento](../04-core-concepts/Event.md) inmutable; el elemento revocado queda **terminado, no borrado** (la historia se conserva). - Tras la revocación, cualquier referencia al elemento revocado DEBERÁ fallar con `MUFP-E-REVOKED`, y la máquina de estados de la federación DEBERÁ retroceder al estado anterior al elemento revocado. - La parte que haya compartido aguas abajo una proyección revocada DEBERÁ propagar la revocación a sus propios consumidores, respetando las cláusulas de `no-onward-disclosure` y de retención del contrato que rige. - La propagación de la revocación DEBERÍA ser oportuna; el retardo máximo de propagación DEBERÍA constar en el contrato de federación. --- # 9. Privacidad y datos personales El Meta-Universo se usa a menudo para federar información sobre personas, así que la privacidad es una preocupación de primer orden, no una ocurrencia tardía. - **Vinculación al propósito.** Los datos personales DEBERÁN divulgarse únicamente para el propósito explícito de un contrato aceptado ([MUC, artículos 11-13](../01-constitution/Meta-Universe-Constitution.md)). - **Alineación con el interesado.** Cuando una proyección concierne a una persona, el modelo DEBERÍA identificar el rol de interesado para que sus derechos (acceso, rectificación, supresión de las copias ulteriores, limitación) puedan ejercerse mediante modificación y revocación del contrato. Esto se alinea con regímenes del estilo del RGPD sin atar el estándar a ninguna jurisdicción concreta. - **Minimización.** El mínimo conocimiento (T5) es la expresión técnica de la minimización de datos: la proyección lleva solo los campos contratados. - **Supresión frente a historia.** La historia inmutable de eventos registra *que* hubo una divulgación y *que* fue revocada después; NO DEBERÁ usarse para retener la carga personal más allá del plazo de retención del contrato. La supresión se aplica a los datos personales divulgados; no reescribe la auditoría de la decisión de divulgar. --- # 10. Consideraciones de seguridad para los documentos de federación Todo documento de `03-federation/` DEBERÍA llevar una breve nota de **consideraciones de seguridad** que identifique las amenazas que le atañen y remita aquí. Los documentos de mecanismo se corresponden con este modelo así: | Documento | Amenazas principales | |----------|-----------------| | [Identity-Binding](../03-federation/Identity-Binding.md) | T1, T9 | | [Semantic-Mapping](../03-federation/Semantic-Mapping.md) | T3 | | [Consent-and-Disclosure](../03-federation/Consent-and-Disclosure.md) | T5, privacidad | | [Synchronization](../03-federation/Synchronization.md) | T4, T6 | | [Trust-Model](../03-federation/Trust-Model.md) | T7, T8 | | [MUFP-Messages](../03-federation/MUFP-Messages.md) | T2, T6, T7, T10 | --- # 11. Conformidad Una implementación de federación es conforme con este modelo cuando: - autentica la parte `from` y verifica la integridad del sobre antes de usarlo; - verifica la huella semántica de toda carga MUIF; - rechaza las correspondencias no fijadas a las huellas de ambos modelos; - no devuelve ninguna proyección sin contrato aceptado y propósito declarado; - rechaza repeticiones y mensajes caducados; - aplica la revocación de inmediato, la registra como evento y la propaga; - calcula y registra el vector de confianza y la política de propósito de cada decisión. --- # 12. Invariantes arquitectónicas - La seguridad NO DEBERÁ depender de que la confianza sea alta. - Todo artefacto que cruza DEBERÁ autenticarse y verificarse en su integridad. - La revocación DEBERÁ ser inmediata, registrada y propagada. - Los datos personales DEBERÁN estar vinculados al propósito y minimizados. - La auditoría de una decisión DEBERÁ sobrevivir a la supresión de los datos que la decisión trataba. --- # Direcciones futuras - Un **perfil criptográfico** (suites de firma, formatos de clave, métodos DID), a desarrollar junto con el [registro descentralizado](../06-ecosystem/Decentralized-Registry.md). - Patrones de **computación confidencial** para que una proyección pueda calcularse sobre datos que nunca se divulgan en claro, y [atestación de políticas de conocimiento cero](../03-federation/Zero-Knowledge-Attestation.md) para que un Universo pueda demostrar su conformidad sin revelar su modelo. - Un **conjunto de pruebas de conformidad de seguridad** dentro del Semantic Test Kit (hoja de ruta WS6). --- # Declaración final > La confianza decide si dos universos *quieren* compartir significado. La seguridad garantiza > que lo que cruza entre ellos es exactamente lo pactado - ni más, sin alteración, > atribuible y revocable. El Meta-Universo necesita ambas.