¿Cómo pueden los entornos de ejecución confiables hacer más justa una transacción digital?
Por: Edison Narváez
Publicado: Septiembre 2026
Área: Ciberseguridad · Sistemas Distribuidos · Computación Confiable · Comercio Electrónico
Resumen
Las transacciones digitales permiten intercambiar documentos, información, servicios y otros recursos sin que las partes estén físicamente presentes. Sin embargo, cuando dos participantes no se conocen o no confían plenamente entre sí, aparece un problema: ¿cómo garantizar que ambos cumplan lo acordado y que ninguno obtenga una ventaja injusta?
El artículo “Implementación de un modelo computacional de troca justa utilizando ambiente de execução confiável” propone un protocolo de intercambio justo apoyado en entornos de ejecución confiables (TEE, por sus siglas en inglés) y en un tercero de confianza descentralizado. La propuesta divide las funciones de ese tercero en dos componentes: los attestables, que realizan operaciones de forma aislada para cada participante, y un Public Bulletin Board (PBB), que permite coordinar la sincronización del intercambio.
La arquitectura busca proteger la integridad de la transacción y reducir la dependencia de un único intermediario central. El proceso contempla establecer la comunicación, depositar los elementos, verificar que correspondan a lo acordado y decidir si se liberan o se restauran. El trabajo presenta una propuesta de protocolo y describe sus componentes; no debe interpretarse como una demostración de que elimina todos los riesgos de seguridad.
Palabras clave: intercambio justo, entornos de ejecución confiables, TEE, sistemas distribuidos, ciberseguridad, privacidad, attestable, Public Bulletin Board, transacciones digitales.
1. Introducción
El comercio electrónico y los sistemas distribuidos permiten que personas, empresas y aplicaciones intercambien datos y recursos a distancia. Aunque estas operaciones facilitan numerosos procesos, también crean un reto: las partes necesitan garantías de que el intercambio se realizará conforme a las condiciones pactadas.
Por ejemplo, una persona puede enviar un documento digital y esperar recibir otro a cambio. Si una de las partes entrega primero su recurso y la otra no cumple, la primera puede sufrir una pérdida. El problema no se limita al dinero: también puede involucrar archivos, certificados, información, permisos o servicios digitales.
El intercambio justo busca que ninguna de las partes quede injustamente perjudicada. El artículo analizado aborda este problema mediante una arquitectura que utiliza entornos de ejecución confiables para distribuir funciones que tradicionalmente se concentraban en un tercero de confianza.
2. El problema del intercambio justo
En un intercambio digital participan, como mínimo, dos actores. Para explicar el concepto, el artículo utiliza el ejemplo de Alice y Bob. Alice dispone de un elemento que quiere intercambiar y Bob posee otro. Ambos necesitan comprobar que la operación se complete correctamente.
El desafío consiste en evitar situaciones como las siguientes:
Una parte recibe el recurso de la otra, pero no entrega el suyo.
Un participante modifica o sustituye el elemento que debía intercambiar.
La comunicación falla y cada parte interpreta un estado distinto de la transacción.
Un intermediario central sufre una interrupción, es atacado o accede a información que debería mantenerse privada.
Un protocolo de intercambio justo define las reglas para depositar, comprobar, sincronizar y finalmente liberar o restaurar los elementos. La sincronización es importante porque determina si el proceso debe completarse o cancelarse.
3. ¿Qué investigaron?
Los autores estudiaron cómo diseñar un protocolo de intercambio justo con un tercero de confianza descentralizado, utilizando tecnologías de Trusted Execution Environment (TEE). La finalidad es conservar mecanismos de coordinación y protección sin concentrar todas las operaciones en una única entidad central.
La propuesta se apoya en antecedentes de protocolos de intercambio justo, mecanismos criptográficos y tecnologías que aíslan la ejecución de código sensible. El artículo revisa trabajos previos y presenta una arquitectura conceptual con componentes separados.
El objetivo principal no es medir la productividad de un algoritmo de aprendizaje automático ni presentar porcentajes de precisión. Se trata de una propuesta de arquitectura y protocolo de seguridad para transacciones digitales.
4. ¿Qué es un tercero de confianza?
Un tercero de confianza, conocido como TTP (Trusted Third Party), es una entidad que ayuda a coordinar una operación entre participantes que no confían plenamente entre sí. En un intercambio digital puede autenticar a los actores, custodiar elementos, comprobar condiciones y resolver qué sucede si aparece un problema.
En una solución centralizada, el TTP concentra responsabilidades importantes. Esto puede simplificar la coordinación, pero también crea un punto crítico: si el intermediario falla, es atacado o no protege correctamente los datos, la transacción puede quedar comprometida.
El enfoque del artículo consiste en distribuir esas funciones entre componentes con responsabilidades diferenciadas. La descentralización propuesta no significa que desaparezcan todos los supuestos de confianza; la seguridad depende de que los componentes y las condiciones asumidas por el protocolo se cumplan.
5. ¿Qué es un entorno de ejecución confiable (TEE)?
Un TEE es un entorno de ejecución aislado que busca proteger código y datos frente a accesos no autorizados desde el resto del sistema. Puede apoyarse en características del hardware y del software para separar operaciones sensibles de los procesos normales del dispositivo.
El artículo menciona varias tecnologías relacionadas:
Intel SGX: permite ejecutar código sensible dentro de regiones protegidas conocidas como enclaves.
ARM TrustZone: separa un entorno seguro de otro entorno de ejecución normal dentro de una plataforma compatible.
AMD SEV: emplea mecanismos de cifrado de memoria para ayudar a proteger máquinas virtuales.
Morello Board: explora mecanismos de seguridad de memoria basados en la arquitectura CHERI.
Estas tecnologías no son idénticas ni ofrecen exactamente las mismas garantías. Su función concreta depende de la plataforma, la configuración y el modelo de amenazas. El artículo las presenta como alternativas tecnológicas que pueden contribuir a implementar partes confiables del protocolo.
6. ¿Cómo funciona el intercambio justo?
De forma simplificada, el proceso descrito puede organizarse en las siguientes etapas:
1. Establecimiento de comunicación (handshake). Alice y Bob inician la comunicación y preparan las condiciones necesarias para el intercambio.
2. Depósito de los elementos. Cada participante deposita el elemento que desea intercambiar en el proceso protegido, evitando que la otra parte lo obtenga antes de que corresponda.
3. Verificación. Los componentes comprueban que los elementos depositados coincidan con las descripciones y condiciones acordadas.
4. Sincronización. El Public Bulletin Board (PBB) coordina el resultado mediante los tokens previstos por el protocolo.
5. Liberación o restauración. Si la sincronización resulta satisfactoria, se liberan los elementos; si no, se restauran o se mantiene la operación sin completar, de acuerdo con el protocolo.
La idea fundamental es que la decisión no dependa únicamente de la voluntad de uno de los participantes. Las operaciones protegidas y la sincronización coordinada deben hacer que ambos lados sigan un resultado consistente.
7. Arquitectura propuesta: attestables y PBB
La propuesta separa las funciones que un TTP centralizado normalmente ejecutaría de manera monolítica.
Attestables
Cada participante dispone de un componente attestable: attA para Alice y attB para Bob. Estos componentes realizan operaciones de cómputo independientes y controlan acciones como ocultar, bloquear y liberar los elementos según el resultado del protocolo.
Public Bulletin Board (PBB)
El PBB funciona como un mecanismo público de mensajes o registro para coordinar la sincronización. En la arquitectura descrita, no realiza el cómputo principal de los elementos: publica y recibe tokens que permiten a los attestables determinar si corresponde liberar o restaurar.
La separación entre cómputo protegido y sincronización busca reducir la dependencia de un único componente que controle todas las operaciones. No obstante, el protocolo presupone que los attestables y el PBB están libres de amenazas, fallos o accidentes, por lo que esas condiciones son importantes al interpretar la propuesta.
8. ¿Qué papel cumple la criptografía?
El artículo describe una etapa en la que los documentos se cifran con una clave compartida antes de ser intercambiados. El cifrado ayuda a evitar que el contenido quede expuesto durante el proceso, mientras que los componentes confiables controlan cuándo se permite su liberación.
La protección no depende solamente de cifrar los archivos. También es necesario comprobar que los elementos corresponden a lo esperado, coordinar el estado de la transacción y definir qué ocurre cuando hay fallos de comunicación. Por eso, el protocolo combina protección de datos, verificación y sincronización.
La criptografía, por sí sola, no garantiza que todo el sistema sea seguro: también importan la administración de claves, la implementación, la configuración del hardware y el comportamiento de los componentes.
9. Proceso general de la solución
ALICE Y BOB
↓
ESTABLECIMIENTO DE COMUNICACIÓN
↓
CIFRADO Y DEPÓSITO DE LOS ELEMENTOS
↓
VERIFICACIÓN MEDIANTE attA Y attB
↓
PUBLICACIÓN DE TOKENS EN EL PBB
↓
SINCRONIZACIÓN DEL RESULTADO
↓
LIBERACIÓN O RESTAURACIÓN
10. ¿En qué se diferencia de una solución centralizada?
En una solución centralizada, un único intermediario puede custodiar los elementos, verificar condiciones y decidir el resultado. En el enfoque propuesto, esas funciones se reparten entre dos attestables independientes y el PBB.
| Aspecto | TTP centralizado | Propuesta con TEE |
| Organización | Funciones concentradas en un intermediario. | Funciones divididas entre attestables y PBB. |
| Coordinación | El tercero central controla el estado de la operación. | El PBB coordina la sincronización mediante tokens. |
| Privacidad | El intermediario puede tratar datos de las partes. | Busca reducir la exposición y distribuir responsabilidades. |
| Riesgo operativo | Existe dependencia de un punto central. | Busca reducir esa dependencia, bajo supuestos de seguridad específicos. |
| Implementación | Puede ser más directa de administrar. | Requiere integrar y verificar componentes protegidos y mecanismos de coordinación. |
11. Posibles aplicaciones
Aunque el artículo se centra en el protocolo y sus componentes, el problema del intercambio justo aparece en diferentes contextos digitales. Como aplicaciones potenciales —no como resultados ya validados por el artículo— se pueden considerar:
Comercio electrónico: intercambio de documentos o recursos digitales entre compradores y vendedores.
Intercambio de contratos: entrega coordinada de archivos y confirmaciones entre organizaciones.
Colaboración empresarial: transferencia de información entre entidades que necesitan limitar la exposición de sus datos.
Servicios digitales: intercambio de credenciales, licencias o permisos sujetos a condiciones.
Sistemas distribuidos: coordinación de operaciones cuando las partes no comparten una autoridad central.
La viabilidad de cada caso depende de los requisitos legales, el tipo de recurso, las amenazas relevantes y las garantías que ofrezca la implementación concreta.
12. Beneficios potenciales y aspectos que deben evaluarse
La arquitectura propone varios beneficios potenciales:
Mayor autonomía de los participantes al reducir la dependencia de un intermediario único.
Separación de responsabilidades entre cómputo protegido y sincronización.
Protección de la integridad de la transacción mediante componentes confiables.
Posibilidad de adaptar la arquitectura a diferentes plataformas de TEE.
Un mecanismo explícito para liberar o restaurar elementos según el resultado del intercambio.
Estos beneficios describen la motivación y el diseño de la propuesta. Para establecer su alcance real, una implementación debe evaluarse frente a fallos, ataques, interrupciones, costes de operación y limitaciones del hardware utilizado.
13. Un posible enfoque para RIIOTE
La propuesta puede servir como punto de partida para una línea de divulgación o investigación de RIIOTE sobre confianza digital y protección de transacciones. Una ruta de aprendizaje podría combinar:
Fundamentos de criptografía y gestión de claves.
Conceptos de sistemas distribuidos y protocolos de sincronización.
Estudio de los entornos de ejecución confiables disponibles.
Diseño de pruebas para interrupciones, mensajes retrasados y participantes maliciosos.
Evaluación de privacidad, rendimiento, recuperación ante fallos y facilidad de implementación.
Este esquema es una posible aplicación educativa inspirada en el tema del artículo, no un modelo institucional evaluado por sus autores.
14. Limitaciones y precauciones
El documento presenta una arquitectura y un protocolo propuesto, pero no ofrece en sus conclusiones cifras de rendimiento que permitan afirmar una mejora cuantificada frente a otras soluciones. Por ello, no corresponde atribuirle porcentajes de éxito, velocidad o reducción de ataques que no aparecen reportados.
La solución también parte de supuestos relevantes: los attestables y el PBB se consideran libres de amenazas, fallos o accidentes; las aplicaciones de Alice y Bob pueden ser manipuladas por sus propietarios; y los canales de comunicación no se consideran confiables, ya que los mensajes podrían retrasarse, reordenarse o descartarse.
Otra cuestión es que la propuesta está diseñada para elementos copiables, como datos digitales que pueden duplicarse. Los intercambios de elementos únicos o no copiables requieren análisis adicional. Los autores identifican como trabajo futuro probar escenarios prácticos, estudiar elementos únicos y copiables, utilizar attestables reales y comparar mecanismos de sincronización probabilísticos y determinísticos.
Por tanto, un TEE no debe entenderse como una garantía absoluta de seguridad. Es necesario estudiar el modelo de amenazas, las vulnerabilidades de la plataforma, los errores de implementación y la disponibilidad de los componentes.
15. Futuras investigaciones
A partir de las líneas señaladas por los autores, los siguientes pasos podrían incluir:
Implementar el protocolo en escenarios experimentales reproducibles.
Evaluar el intercambio de elementos únicos y copiables.
Construir y probar attestables reales sobre plataformas compatibles.
Analizar con mayor profundidad la sincronización y sus condiciones de fallo.
Comparar estrategias de sincronización probabilísticas y determinísticas.
Medir rendimiento, consumo de recursos, disponibilidad y recuperación ante interrupciones.
Documentar las amenazas que cada plataforma de TEE puede mitigar y las que permanecen fuera de su protección.
Las mediciones experimentales permitirían pasar de una propuesta arquitectónica a una evaluación más completa de su comportamiento bajo condiciones realistas.
16. Conclusiones
El intercambio justo es un problema importante de los sistemas distribuidos porque busca evitar que una de las partes obtenga el recurso acordado mientras la otra queda perjudicada. Las soluciones tradicionales pueden apoyarse en un tercero de confianza centralizado, pero esa concentración de funciones crea preocupaciones de privacidad, disponibilidad y dependencia.
El artículo analizado propone distribuir las responsabilidades del tercero de confianza mediante dos componentes principales: los attestables, encargados de las operaciones protegidas de cada participante, y el Public Bulletin Board, que coordina la sincronización mediante tokens. El proceso contempla comunicación inicial, depósito, verificación y liberación o restauración.
La propuesta utiliza los entornos de ejecución confiables como mecanismo para aislar operaciones sensibles y apoyar la integridad de las transacciones. Sin embargo, sus garantías dependen de los supuestos de seguridad y de una implementación correcta. El artículo no proporciona cifras que permitan afirmar una mejora cuantitativa de rendimiento, por lo que son necesarias pruebas prácticas para determinar su eficacia.
En conclusión, el trabajo presenta una alternativa interesante para diseñar intercambios digitales con mayor autonomía y una distribución más clara de responsabilidades. Su aporte debe valorarse como una arquitectura propuesta que abre líneas de evaluación e investigación, no como una solución que elimine todos los riesgos de las transacciones digitales.
📚 Referencia original
Rodrigues, D. A., Roos-Frantz, F. C., Frantz, R. Z., Sawicki, S., & Molina-Jimenez, C. (2026). Implementação de um modelo computacional de troca justa utilizando ambiente de execução confiável. Proceeding Series of the Brazilian Society of Computational and Applied Mathematics, 12(1). https://doi.org/10.5540/03.2026.012.01.0295