Desarrollo de Servicios Confiables en Kubernetes Utilizando TEEs

Desarrollo de Servicios Confiables en Kubernetes Utilizando TEEs Diego Ferreiro Ferr´ on Gradiant [email protected]g Mario L´ opez Feijoo Gradiant [email protected]g Iago L´ opez Rom´ an Gradiant [email protected]g Adri´ an V´ azquez Saavedra Gradiant avsaav[email protected] Resumen—La alta demanda de servicios en la nube y la cantidad de datos sensibles que procesan, hace que sea primordial que ofrezcan garant´ ıas de confidencialidad e integridad. La computaci´ on confidencial propone el uso de Entornos de Ejecuci´ on Confiables (TEEs) basados en hardware para limitar el acceso a los datos no cifrados. Estas soluciones resultan ideales para entornos en la nube, en los cuales la infraestructura es confiada a terceros que no siempre son considerados fiables. En el presente trabajo, se ha desarrollado un servicio confiable, basado en el TEE ofrecido por la tecnolog´ ıa SGX, para el mantenimiento predictivo de veh´ ıculos. Este servicio ha sido desplegado utilizado la metodolog´ ıa m´ as com´ un seguida por las organizaciones: contenedores y Kubernetes. Los resultados de nuestro trabajo prueban que la computaci´ on confidencial es efectiva y necesaria para reforzar la seguridad de los servicios en la nube actuales. Index Terms—Computaci´ on confidencial, Entornos de computaci´ on confiable, Kubernetes Tipo de contribuci´ on: Investigaci´ on en desarrollo (l´ ımite 8 p´ aginas) I. INTRODUCCI´ ON La seguridad de la informaci´ on ha sido un desaf´ ıo constante a lo largo de la historia. En respuesta a esta problem´ atica surgi´ o la criptograf´ ıa, pr´ actica que consiste en ocultar o cifrar informaci´ on de manera que s´ olo el destinatario previsto pueda leerla. Esta informaci´ on puede estar en tres estados, (1) en tr´ ansito, mientras se traslada de un lugar a otro, (2) en reposo, mientras est´ a almacenada, y (3) en uso, durante su procesamiento. La criptograf´ ıa cl´ asica t´ ıpicamente se ha enfocado en los dos primeros estados. No obstante, en los ´ ultimos a˜ nos, han surgido distintos enfoques criptogr´ aficos, como el cifrado homom´ orfico o la computaci´ on segura entre m´ ultiples partes, que abordan la problem´ atica del tercer estado. A pesar de ello, estas t´ ecnicas criptogr´ aficas est´ an lejos de poder ser utilizadas en la pr´ actica en cualquier tipo de escenario debido a sus limitaciones, como la complejidad computacional [1]. Por ello, en la d´ ecada pasada, se introdujo el concepto de computaci´ on confidencial, una soluci´ on que opta por introducir entornos de ejecuci´ on confiables (TEEs) basados en hardware. Los TEEs son dispositivos de prop´ osito general que se caracterizan principalmente por proporcionar un ´ area segura aislada en el procesador principal [2]. Estos dispositivos est´ an dise˜ nados para ejecutar aplicaciones en un entorno protegido y sin interferencias, garantizando el aislamiento a trav´ es de soporte hardware. En cuanto al rendimiento, si bien depende del TEE utilizado, este suele ser significante superior a los enfoques puramente criptogr´ aficos [3]. En el panorama tecnol´ ogico actual, las compa˜ n´ ıas tienden a ofrecer sus servicios en la nube, dadas las ventajas que esta provee. Los entornos cloud se distinguen por la dependencia de las empresas hacia los proveedores de infraestructura, una relaci´ on que va m´ as all´ a de la provisi´ on de recursos y se extiende a aspectos cr´ ıticos como la seguridad. La capacidad de los proveedores para acceder al hardware les confiere la posibilidad de interactuar con cualquier informaci´ on alojada en sus sistemas. La computaci´ on confidencial emerge como una soluci´ on ideal en este tipo de entornos, ya que permite que las organizaciones a´ ıslen sus aplicaciones protegiendo tanto sus datos como los de sus clientes, evitando esta dependencia del proveedor de la infraestructura [4]. En el ´ ambito de la implementaci´ on, los contenedores y Kubernetes representan la metodolog´ ıa m´ as com´ un para el despliegue de aplicaciones en la nube [5]. Los contenedores encapsulan las aplicaciones y sus dependencias, permitiendo una ejecuci´ on eficiente y aislada, mientras que Kubernetes orquesta estos contenedores, gestionando su despliegue, escalado y operaci´ on de manera automatizada. La combinaci´ on de computaci´ on confidencial con la contenerizaci´ on y la orquestaci´ on de Kubernetes permitir´ a ofrecer soluciones robustas en t´ erminos de seguridad en la nube. Los contenedores pueden integrarse con los TEEs, proporcionando un entorno de ejecuci´ on seguro, y Kubernetes puede asegurar que s´ olo los contenedores autorizados y verificados se ejecuten, manteniendo la integridad y confidencialidad de los datos en todo momento. Esta sinergia entre la computaci´ on confidencial, contenedores y Kubernetes es fundamental para avanzar hacia un modelo de seguridad zero trust en la nube [6]. I-A. Nuestra contribuci´ on En este trabajo, hemos dise˜ nado y desarrollado un servicio confiable que se despliega dentro de un TEE para garantizar la confidencialidad e integridad de la informaci´ on que procesa. El servicio ha sido desarrollado utilizando la tecnolog´ ıa Intel SGX [7], un TEE que permite aislamiento a nivel de aplicaci´ on. Es decir, cada aplicaci´ on estar´ ıa aislada, no s´ olo de otras aplicaciones que se est´ an ejecutando en el sistema, si no que ni el sistema operativo ni el hipervisor tendr´ ıan acceso a la informaci´ on manejada. Nuestro servicio ofrece la capacidad de registrar de forma confidencial un modelo de Machine Learning (ML) que haya sido entrenado previamente. Posteriormente, permite a los usuarios enviar sus datos, de manera tambi´ en confidencial, para realizar inferencias empleando este modelo. El servicio tambi´ en ofrece la funcionalidad de acreditaci´ on para que cualquier usuario que se comunique con ´ el pueda verificar que se est´ a ejecutando en el entorno confiable. JNIC 2024 ISBN:978-84-09-62140-8 428 Adem´ as, hemos optado por un modelo de arquitectura que se ha convertido casi en un est´ andar del sector, la utilizaci´ on de contenedores en Kubernetes. Al contenerizar el servicio, logramos independizar el despliegue de la infraestructura. Por ´ ultimo, el servicio est´ a corriendo en un cl´ uster de Kubernetes con soporte Intel SGX, lo que nos facilita un escalado eficaz y una gesti´ on simplificada. II. PRELIMINARES La computaci´ on confidencial es una tecnolog´ ıa que garantiza la seguridad de los datos durante el procesado. Para ello, utiliza entornos de ejecuci´ on confiables, entornos aislados para computaci´ on protegida. Aunque el t´ ermino computaci´ on confidencial es relativamente nuevo, los dispositivos en los que se basa existen desde hace algunas d´ ecadas. Ciertas clases de TEEs han estado disponibles en dispositivos comerciales en formatos como TPMs (M´ odulos de Plataforma de Confianza) y HSMs (M´ odulos de Seguridad de Hardware) [8]. Estos dispositivos presentan un marcado enfoque criptogr´ afico, en otras palabras, su funci´ on principal es ejecutar operaciones criptogr´ aficas evitando que las claves se expongan en entornos no seguros. No obstante, en los ´ ultimos a˜ nos, se ha desarrollado una nueva categor´ ıa de TEEs. Esta categor´ ıa de entornos de computaci´ on confiables son dispositivos de prop´ osito general que se caracterizan por proporcionar un ´ area segura aislada en el procesador principal [2]. Estos TEEs se distinguen por las siguientes propiedades, aunque no todas las tecnolog´ ıas TEEs que se mencionar´ an a continuaci´ on las cumplen: Confidencialidad: se garantiza que ´ unicamente las entidades dentro del entorno seguro tienen acceso a su contenido, sea c´ odigo o datos. Integridad: se garantiza que el contenido del TEE no se puede modificar por entidades que se encuentren fuera del entorno seguro. Acreditaci´ on (attestation): permite a entidades externas verificar que est´ an interactuando con un entorno confiable. Es preciso aclarar que los TEEs poseen un mecanismo de intercambio de datos con el exterior en donde la comunicaci´ on entre la parte segura y la parte no segura se hace a trav´ es de un buffer de datos (memoria RAM), el cual es compartido entre ambos entornos. Por ello, la informaci´ on que se introduce en este buffer debe encontrarse cifrada con una clave perteneciente al entorno seguro. En el panorama actual, todos los grandes fabricantes de procesadores han integrado los entornos de ejecuci´ on segura dentro de sus procesadores. La compa˜ n´ ıa pionera en este campo es ARM ya que desde la d´ ecada de los 2000s cuentan con la tecnolog´ ıa ARM Trustzone [9]. Adem´ as, recientemente ha desarrollado una versi´ on mejorada llamada ARM CCA [10]. Tras la iniciativa de ARM, otros fabricantes como Intel y AMD han contribuido al desarrollo de la tecnolog´ ıa. En particular, Intel con la introducci´ on de Intel SGX [7], mejorado con SGXv2; y m´ as recientemente, con la presentaci´ on de Intel TDX [11]. Mientras que AMD por su lado, con la tecnolog´ ıa SEV [12] y sus actualizaciones, SEV-ES [13] y SEV-SNP [14]. Figura 1. Comparativa superficie de ataque TEEs [4]. Por lo general, podemos dividir todos estos TEEs introducidos en dos variantes, dependiendo del tama˜ no de la base de c´ omputo confiable (TCB). La TCB es la parte del sistema que implementa la seguridad y confianza. Abarca hardware, software y firmware, siendo esencial para garantizar el funcionamiento seguro del sistema [15]. En otras palabras, en el contexto de los TEEs, es la parte del software que se ejecuta en el entorno seguro, adem´ as del firmware/microc´ odigo del procesador. Considerando este aspecto, tenemos dos variantes: (1) los secure enclaves, donde dentro del entorno aislado, ´ unicamente se ejecuta una parte de una aplicaci´ on; y (2) las confidential VMs otrust domains, que ejecutan una m´ aquina virtual completa dentro del entorno seguro. En la figura 1, se presenta una comparativa entre estas dos variantes en relaci´ on al entorno de computaci´ on est´ andar o convencional. Se enfatiza qu´ e entidades tienen acceso a la informaci´ on en cada caso. Este aspecto est´ a directamente relacionado con los riesgos de seguridad del contenido del entorno seguro. Cuantas menos entidades tengan acceso, menor ser´ a el riesgo. Debe destacarse que en este diagrama hemos excluido a aquellas entidades que tienen acceso directo al hardware, esto es debido a que los TEEs no est´ an especialmente dise˜ nados para hacer frente a ataques de canal lateral [16]. Por otro lado, en la tabla I se muestran algunas de las tecnolog´ ıas anteriormente mencionadas, especificando la variante a la que pertenecen as´ ı como las caracter´ ısticas que ofrecen. Tabla I COMPARATIVA PROPIEDADES DE SEGURIDAD TEES[17]. TEE Tipo Confidencialidad Integridad Acreditaci´ on (Remota) SGX Enclave SEV VM * SEV-ES VM SEV-SNP VM TDX VM Para concluir, aunque inicialmente los entornos de computaci´ on confiables se concibieron como ´ areas seguras dentro del procesador principal, recientemente se ha venido trabajando en extender estas ´ areas seguras a otro tipo de dispositivos confiables, como el caso de las tarjetas gr´ aficas. Estos dispositivos ofrecen nuevas posibilidades a los entornos de computaci´ on confiable, especialmente en aquellos escenarios donde se requiera una gran capacidad de c´ omputo. En este contexto, NVIDIA est´ a desempe˜ nando un papel clave liderando el desarrollado de esta tecnolog´ ıa con su producto NVIDIA Desarrollo de Servicios Confiables en Kubernetes Utilizando TEEs 429 Figura 2. Acceso a memoria con Intel SGX. Confidential Computing [18]. II-A. Intel SGX Intel Software Guard Extensions, m´ as conocido como Intel SGX, es una tecnolog´ ıa de seguridad integrada en algunos procesadores Intel que garantiza la protecci´ on de los datos en uso a trav´ es de un aislamiento individual por aplicaci´ on. Para ello, permite que las aplicaciones utilicen espacios de memoria cifrados controlados por el procesador conocidos como enclaves. El acceso a estos espacios de memoria estar´ ıa limitado ´ unicamente a las aplicaciones que los hayan solicitado, ya que el descifrado se hace al vuelo en el procesador. La figura 2 presenta un esquema de alto nivel que ilustra c´ omo el procesador toma decisiones sobre el acceso a una p´ agina de memoria. Intel SGX se integra a nivel del procesador, por lo que las aplicaciones estar´ an protegidas frente a malware y usuarios no autorizados, incluso en caso de vulneraci´ on de las capas del sistema operativo o del hipervisor. Se basa en un nuevo conjunto de instrucciones a˜ nadidas a la arquitectura de procesadores de Intel en dos fases. El primer subconjunto se a˜ nadi´ o en 2015 y es conocido como SGXv1. En 2019, para tratar con algunos limitantes de SGXv1, como el tama˜ no de los enclaves, las operaciones de I/O y ciertos ataques de canal lateral, se introdujo una nueva versi´ on de la tecnolog´ ıa conocida como SGXv2. Todas las aplicaciones que utilizan Intel SGX se dividen en dos partes: una parte confiable y una parte no confiable. La parte confiable comprende todo el c´ odigo que se carga y ejecuta dentro de la memoria protegida. Por otro lado, la parte no confiable debe, como m´ ınimo, cargar el c´ odigo que se ejecutar´ a en la parte confiable. Adem´ as, tiene la responsabilidad de canalizar toda la informaci´ on hacia la entidad confiable, dado que la parte confiable carece de acceso a los componentes externos al procesador, como por ejemplo, los dispositivos de red. Las aplicaciones desarrolladas en base a la tecnolog´ ıa Intel SGX incluyen algunas medidas de seguridad para prevenir ataques en la cadena de suministro. Por esta raz´ on, es imperativo que cualquier aplicaci´ on o c´ odigo que se introduzca en la parte confiable est´ e debidamente autenticado mediante una firma digital del desarrollador de la aplicaci´ on. Sin embargo, investigadores han demostrado que estas protecciones no son completamente efectivas, ya que es posible comprometer el enclave antes de que se firme [19]. El proceso de carga o inicializaci´ on del enclave es crucial, ya que garantiza tanto la integridad como la confidencialidad del c´ odigo del enclave. Durante el proceso de carga del c´ odigo en la memoria, se calcula un hash criptogr´ afico basado en el contenido del mismo. Este hash, posteriormente, se emplea en conjunto con la clave p´ ublica del desarrollador para validar la autenticidad de la firma asociada al c´ odigo. Con respecto a la confidencialidad, de forma transparente al usuario, cada p´ agina de memoria del enclave se cifra utilizando el algoritmo AES en modo XTS con el motor criptogr´ afico incorporado en los procesadores Intel una vez que ‘sale del procesador’. Referente a la acreditaci´ on en Intel SGX, tenemos dos variantes. (1) La acreditaci´ on local permite que dos enclaves en un mismo servidor puedan establecer una relaci´ on de confianza. Este tipo de acreditaci´ on utiliza una clave sim´ etrica grabada durante la fabricaci´ on del procesador. Los propios enclaves no tienen acceso a la clave pero si pueden solicitar al procesador que les genere una prueba criptogr´ afica llamada REPORT que, entre otras cosas, contiene un hash del contenido, una referencia a la clave p´ ublica del desarrollador y del identificador del micro-c´ odigo que est´ a utilizando el procesador. El REPORT incluye un MAC generado con esta clave. De la misma manera que pueden solicitar un REPORT, tambi´ en le pueden pedir al procesador que lo verifique. (2) La acreditaci´ on remota, por otro lado, permite que una entidad remota pueda establecer una relaci´ on de confianza con un enclave. Si bien existen dos modos de acreditaci´ on remota, DCAP y EPID, este ´ ultimo est´ a obsoleto y se dejar´ a de dar soporte por parte de Intel en 2025, por ello describiremos ´ unicamente la acreditaci´ on remota DCAP. En la acreditaci´ on remota DCAP, al igual que en la acreditaci´ on local, se parte de la clave sim´ etrica estampada durante el proceso de fabricaci´ on. Sin embargo, en este caso, en lugar de utilizarse directamente, dicha clave sim´ etrica se emplea para autenticarse ante un servicio proporcionado por el fabricante. Este servicio emitir´ a un certificado para el servidor. De esta forma cuando el enclave necesita acreditarse ante una entidad externa, solicita un REPORT al procesador. Este reporte se firmar´ a con el certificado de la plataforma, lo que se conoce como QUOTE. La entidad externa tiene la opci´ on de comunicarse con Intel para verificar la QUOTE. Finalmente, bas´ andose en el resultado de la verificaci´ on de la QUOTE y las propiedades incluidas en ella, la entidad externa puede decidir si establecer o no la confianza en el enclave. En cuanto al soporte de esta tecnolog´ ıa, actualmente est´ a respaldada por los principales sistemas operativos. A partir del kernel 5.11, Linux incluye los drivers de SGX en su n´ ucleo. Por su parte, Windows tambi´ en ofrece soporte para SGX desde la versi´ on 1511 de Windows 10. En lo que respecta a la virtualizaci´ on, SGX est´ a disponible en la mayor´ ıa de las soluciones como KVM/Qemu, VMWare vSphere y HyperV, aunque con algunas limitaciones. Por ´ ultimo, en entornos cloud, SGX se encuentra disponible en las plataformas de Microsoft Azure, IBM Cloud y Alibaba Cloud. III. ESCENARIO El escenario propuesto, consistir´ a en la creaci´ on de un modelo de Machine Learning para el mantenimiento predictivo de veh´ ıculos [20], y su posterior integraci´ on en la plataforma Intel SGX. En primer lugar, para la creaci´ on del modelo se D. Ferreiro Ferr´on, M. L´opez Feijoo, I. L´opez Rom´an and A. V´azquez Saavedra 430 parte de la recopilaci´ on de datos de cuatro rodamientos, con una estructura de datos que usa tres conjuntos con valores en los que se describen pruebas de fallo. En segundo lugar, se buscar´ a registrar el modelo y poder realizarle inferencias seguras, tal y como se observa en los pasos uno y ocho de la figura 3 respectivamente. Figura 3. Privacy Preserving Machine Learning Tensorflow using a TEE. A continuaci´ on, se procede a dar una descripci´ on superficial de la arquitectura funcional presentada en la figura 3. Primero el cliente cifra y sube el modelo ML a una base de datos, posteriormente, se lleva a cabo la autenticaci´ on y arranque para poder lanzar el microservicio con su configuraci´ on asociada. Acto seguido, el servicio descifra el modelo ML, para luego ejecutarlo y permitir a los clientes realizar inferencias confiables. IV. IMPLEMENTACI ´ ON Y DESPLIEGUE Para llevar a cabo este apartado, es fundamental contar con un entorno adecuado. Por un lado, necesitamos disponer del hardware correspondiente a la tecnolog´ ıa utilizada, en este caso, Intel SGX. Por otro lado, en lo que respecta al software, es importante destacar que sin las herramientas, frameworks y aplicaciones adecuadas, la computaci´ on confidencial resulta pr´ acticamente in´ util [4]. Estos SDKs yframeworks permiten construir o adaptar aplicaciones confidenciales, y proporcionan lo siguiente: (1) Abstracci´ on de funciones complejas como la acreditaci´ on remota; (2) Empaquetado y firma de aplicaciones (crucial en acreditaci´ on remota), y (3) Un entorno de ejecuci´ on compatible con la interfaz POSIX (soporte de E/S de red y archivos, multihilo, etc.). Para poder lograr esto, este apartado dar´ a lugar a tres subsecciones. En la primera se hablar´ a de la integraci´ on de SGX con Kubernetes. En la segunda subsecci´ on se versar´ a sobre el desarrollo del servicio confiable. En la tercera se explicar´ a de manera minuciosa el despliegue del servicio en la plataforma confidencial. IV-A. Kubernetes con soporte de Intel SGX Anteriormente se ha hablado de la tecnolog´ ıa Intel SGX, en el punto actual, se va a discutir su integraci´ on en entornos de Kubernetes. Para poder llevar a cabo esta integraci´ on, en la primera parte de este subapartado, se estudiar´ an los componentes que lo forman, y en la segunda parte, se dar´ a una explicaci´ on de los pasos a tener en cuenta para garantizar su funcionamiento. Lo primero a considerar en este proceso es que el soporte de la tecnolog´ ıa Intel SGX en un cl´ uster de Kubernetes requiere de tres componentes principales, los cuales est´ an definidos a continuaci´ on: SGX Device Plugin [21], cuya responsabilidad radica en descubrir y notificar que nodos tienen un dispositivo Intel SGX. Se debe aclarar que si los contenedores solicitan recursos sobre la tecnolog´ ıa SGX en el cl´ uster, estos no deben utilizar directamente los recursos proporcionados por el device plugin. SGX Admission Webhook, su funci´ on consiste en realizar los cambios necesarios durante la configuraci´ on del Pod. Para ello emplea el proveedor de Quotes de Intel SGX, que tendr´ a la responsabilidad de lograr el funcionamiento de la acreditaci´ on remota en el cl´ uster. Cabe resaltar que este debe establecerlo el usuario mediante una anotaci´ on que recibe el nombre de sgx.intel.com/quoteprovider. Su objetivo principal consiste en ocultar los detalles de configuraci´ on de los recursos del dispositivo, as´ ı como los de los puntos de montaje de vol´ umenes que se usen para la acreditaci´ on remota de Intel SGX en el cl´ uster. Adem´ as, existe otra anotaci´ on que se conoce con el nombre de sgx.intel.com/epc, la cual es utilizada por el webhook de admisi´ on para ajustar din´ amicamente el tama˜ no de la memoria cach´ e en las p´ aginas cifradas del Enclave Page Cache (EPC). SGX EPC memory registration, permite registrar la memoria EPC disponible en cada nodo como un recurso de Kubernetes. Posteriormente, se instala una regla en Node-Feature-Discovery (NFD) para identificar la memoria SGX, y se configura NFD para registrarla autom´ aticamente, de esta manera Kubernetes puede administrar de forma eficaz la memoria EPC en el cl´ uster para las diversas cargas de trabajo que requieran SGX. Lo segundo a destacar es que, si se desea que el cl´ uster se pueda beneficiar de las propiedades de SGX ser´ a necesario realizar la instalaci´ on del plugin mencionado anteriormente Intel SGX device plugin for Kubernetes. El proceso de instalaci´ on requiere unos prerrequisitos. Estos son: (1) Un kernel Linux con los drivers SGX, disponibles en el kernel desde la versi´ on ≥5.11 [22]; (2) El hardware SGX debe disponer de Flexible Launch Control (FLC), que permite al administrador de la plataforma escoger que Launch Enclave [23] (LE) (tipo especial de enclave) puede generar launch tokens o si los enclaves precisan o no de estos tokens; este tipo de tokens permiten garantizar que solo los enclaves autorizados y confiables puedan ser lanzados y ejecutados en un entorno de ejecuci´ on seguro; (3) Instalaci´ on de cert-manager [24], para gestionar certificados TLS en Kubernetes, y (4) Comprobar en los nodos si la asignaci´ on de recursos cuenta con el dispositivo SGX cargado. Una de las particularidades de este plugin es que permite aceptar argumentos de l´ ınea de comandos como el n´ umero de contenedores por nodo para acceder a los dispositivos SGX, estos son: /dev/sgx enclave y/dev/sgx provision. De esta manera se consigue que las cargas de trabajo de Kubernetes empleen SGX, lo que resulta en un cl´ uster confiable y Desarrollo de Servicios Confiables en Kubernetes Utilizando TEEs 431 escalable. Una vez conocidos los componentes y los prerrequisitos necesarios, se debe definir el proceso de instalaci´ on de este plugin. Actualmente existen tres maneras de realizar la instalaci´ on [21]: (1) Im´ agenes Docker previamente creadas, (2) Mediante el uso de un operador, y (3) Utilizando kubectl. Todas estas formas tienen en com´ un una primera fase para efectuar el despliegue de NFD y posteriormente otra para el despliegue del plugin. De todas ellas, para el escenario actual se emplea la opci´ on tres. IV-B. Desarrollo de un servicio confiable Para llevar a cabo la creaci´ on del servicio confidencial se utiliza el modelo de mantenimiento predictivo mencionado previamente en el escenario, donde una vez preprocesados los datos, se hace una normalizaci´ on de estos. Para ello se transformar´ an los datos a un formato que permita introducirlos en una red Long short-term memory LSTM, para ulteriormente emplear un autoencoder que permita reconstruir los datos de entrada, siguiendo la estructura del modelo desarrollado en la publicaci´ on Sensor Anomaly Detection [25]. Finalmente, respecto al modelo, cabe a˜ nadir que este se ha entrenado con 100 epochs, y tras el entrenamiento y las pruebas de validaci´ on necesarias, se ha obtenido un modelo ML capaz de identificar fallos en el comportamiento de los sensores de veh´ ıculos. Para el desarrollo de este modelo se ha utilizado Python 3 [26] y la librer´ ıa TensorFlow [27], adem´ as, el modelo ha sido exportado en formato ProtoBuf (.pb) para garantizar su funcionamiento tanto en TensorFlow, como gRPC [28], en el caso del primero se utiliza este formato para definir la estructura del modelo ML, mientras que en el segundo caso sirve para habilitar inferencias distribuidas sobre el modelo. Como bien se ha indicado anteriormente, es necesario el uso de varias tecnolog´ ıas para lograr este tipo de despliegues. Para esta casu´ ıstica se emplear´ a Gramine [29], la cual permite garantizar que las aplicaciones que no son mutuamente confiables no puedan inferir informaci´ on entre ellas, garantizando as´ ı un aislamiento de seguridad comparable a la ejecuci´ on de m´ aquinas virtuales aisladas. Este library OS [30] ser´ a utilizado para realizar operaciones de cifrado/descifrado sobre el modelo ML y sus variables aplicando la tecnolog´ ıa Intel SGX. A mayores, tambi´ en se opta por el uso de la herramienta MarbleRun [31] para facilitar los procesos de despliegue, escalado y verificaci´ on del servicio TensorFlow. Gracias a MarbleRun, se podr´ a ejecutar de manera confiable el servicio con el modelo generado para la detecci´ on de fallos en sensores. Una vez desplegado este servicio confiable, los clientes podr´ an acceder a este e inferir datos de los sensores y recibir los resultados correspondientes, empleando el proceso de verificabilidad y un certificado. Se debe remarcar que estos datos inferidos viajan cifrados v´ ıa gRPC con TLS sobre el modelo detector de fallos que se encuentra en ejecuci´ on en el servidor TEE dentro del cl´ uster confidencial como un contenedor que emplea Gramine; permitiendo as´ ı a los clientes que tengan permisos necesarios, poder recuperar resultados seguros sobre este modelo. IV-C. Despliegue de un servicio confiable Tras la obtenci´ on del modelo anterior, el siguiente paso ser´ a lograr que funcione dentro de un servidor TensorFlow que se ejecuta como un contenedor dentro del cl´ uster confidencial SGX. Seg´ un la literatura actual, este procedimiento recibe el nombre de Privacy Preserving Machine Learning with Intel SGX and TensorFlow Serving [32], debido a que permite asegurar que la informaci´ on sensible permanezca cifrada durante todo el proceso mediante el uso de la plataforma Intel SGX. Seguidamente se exponen los pasos requeridos para lograr que el despliegue funcione, estos se muestran en la figura 3: 1. El modelo ML de detecci´ on de fallos se cifra y se sube cifrado a la nube (en este caso la nube ser´ ıa el cl´ uster del servidor TEE). 2. Se realiza el lanzamiento de MarbleRun utilizando un archivo de configuraci´ on, conocido como manifest, que establece la estructura y los elementos de la aplicaci´ on confidencial ML. Este procedimiento debe ser realizado por el administrador de la plataforma. 3. Seguidamente, el administrador debe desplegar la aplicaci´ on ML confidencial. 4. De manera aut´ onoma, MarbleRun realiza los procesos de autenticaci´ on y arranque correspondientes a la plataforma. 5. Posteriormente, se verifica el despliegue del modelo v´ ıa MarbleRun. Se carga de manera segura la clave de cifrado AES generada con Gramine en la aplicaci´ on TensorFlow, utilizando la funcionalidad de gesti´ on de secretos de MarbleRun. 6. La aplicaci´ on TensorFlow puede descifrar el modelo dentro del enclave mediante la clave proporcionada. 7–8 Finalmente, los clientes pueden verificar el despliegue usando MarbleRun, y a continuaci´ on se podr´ an conectar de manera segura al servicio sabiendo en todo momento que sus datos solamente pueden ser accedidos desde dentro del enclave. Estos pasos anteriores reflejan el proceso de despliegue del servicio confidencial en Kubernetes utilizando un TEE (v´ ease C´ odigo A). Durante la ejecuci´ on de estos pasos, ocurren una serie de comportamientos espec´ ıficos a nivel interno, que son vitales para comprender adecuadamente el flujo de las operaciones efectuadas dentro del escenario. En la figura 4, se pueden ver estos comportamientos desglosados. Para poder abarcar un mayor conocimiento de lo que ocurre, a continuaci´ on, se desarrollar´ an algunos de los puntos anteriores en base a sus comportamientos complejos. 1.1 El proceso de obtenci´ on de clave y de cifrado del modelo ML se realiza a trav´ es de Gramine, en concreto, mediante la utilidad gramine-sgx-pf-crypt. Esta utilidad dispone de m´ ultiples argumentos, y su comportamiento durante el despliegue es el siguiente: primero se ejecuta el argumento gen-key el cual permite generar una wrapkey empleando una fuente de n´ umeros pseudoaleatorios segura; despu´ es, se emplea el argumento encrypt, que permite envolver el modelo y las variables con esta wrapkey. Posteriormente, tanto el modelo como las variables se cargar´ an en el cl´ uster. 2.1 Antes de hacer el despliegue con MarbleRun, se necesita generar v´ ıa OpenSSL una clave (RSA) y un certificado (X.509) para el usuario. Una vez generados, se emplea la herramienta MarbleRun, primeramente para cargar D. Ferreiro Ferr´on, M. L´opez Feijoo, I. L´opez Rom´an and A. V´azquez Saavedra 432 el archivo manifest que contiene la configuraci´ on del Marble/Servicio TensorFlow, as´ ı como el certificado del usuario, roles de este, etc. Despu´ es de haber cargado el manifest al cl´ uster, se realiza la autenticaci´ on empleando la clave y el certificado mencionados al principio, para as´ ı poder cargar la clave generada con Gramine al cl´ uster mediante la opci´ on de secretos de MarbleRun. De esta manera, posteriormente tanto el modelo como las variables podr´ an ser descifradas dentro del cl´ uster. 3.1 Para poder desplegar la aplicaci´ on, se debe construir un contenedor Docker. Conviene resaltar que este tiene varias fases en su construcci´ on, estas son: 3.1.1 Instalaci´ on de las librer´ ıas necesarias como: SGX, TensorFlow, Edgeless RT (SDK y Runtime para operar f´ acilmente con Intel SGX) [33], y MarbleRun. Por otro lado, tambi´ en se copiar´ an ciertos archivos al contenedor, como la plantilla de Gramine y un script de inicializaci´ on llamado start.sh el cual se describir´ a en el subapartado 3.1.3. 3.1.2 El archivo de plantilla Gramine (v´ ease C´ odigo B) para TensorFlow, permite realizar una configuraci´ on minuciosa del LibOS de Gramine con SGX, pudiendo as´ ı especificar: el tama˜ no del enclave utilizado, hilos que puede emplear el procesador, archivos confiables, el nombre del servicio a ejecutar, etc. 3.1.3 La ´ ultima fase consiste en la ejecuci´ on de start.sh que lleva a cabo tareas como: inicializar la direcci´ on url de Intel SGX Provisioning Certificate Caching Service (PCCS) [34], el cual se usa para obtener certificados PCK [35] y otro material criptogr´ afico, y finalmente ejecuta el servicio TensorFlow v´ ıa Gramine empleando el comando gramine-sgx. C´ odigo A ARCHIVO DE PLANTILLA KUBERNETES PARA TENSORFLOW. 1... 2serviceAccountName: tf-server 3containers: 4image: ... 5resources: 6requests: 7memory: "12Gi" 8cpu: 8 9sgx.intel.com/epc: "8Gi" 10 sgx.intel.com/enclave: 1 11 sgx.intel.com/provision: 1 12 ... 13 env: 14 - name: PCCS_URL 15 value: {{ .Values.pccsURL }} 16 - name: PCCS_USE_SECURE_CERT 17 value: "{{ .Values.secureCert }}" 18 - name: PCCS_DCAP 19 value: {{ .Values.pccsDCAP }} 20 - name: SGX_AESM_ADDR 21 value: "1" 22 - name: EDG_MARBLE_DNS_NAMES 23 value: "grpc.tensorflow-serving.com" 24 volumeMounts: 25 - name: aesmd-socket 26 mountPath: /var/run/aesmd 27 - name: model-dir 28 ... Figura 4. Comportamientos internos durante el despliegue. C´ odigo B ARCHIVO DE PLANTILLA GRAMINE. 1loader.argv = ["tensorflow_model_server"] 2sgx.enclave_size = "8G" 3sgx.max_threads = 512 4sgx.trusted_files = [ 5"file:{{ gramine.libos }}", 6"file:{{ gramine.runtimedir() }}/", 7"file:tensorflow_model_server", 8... 9] 10 sgx.remote_attestation = "dcap" ... V. RESULTADOS Debido a que los (TEEs) est´ an basados en hardware, las pruebas que se realizar´ an en este apartado han requerido del uso de un equipo con un procesador Intel Xeon Gold 5318S de 24 n´ ucleos y 512 GB de RAM, el cual es compatible con SGXv2. Adem´ as, dentro de este se ha desplegado un cl´ uster de Kubernetes configurado con 14 n´ ucleos de CPU a 2.10 Ghz y 50 GiB de memoria RAM. Acto seguido, se ejecutar´ a el modelo ML bajo un contenedor limitado cuyos recursos son 8 n´ ucleos a 2.10 GHz, 12 GiB de memoria RAM, y un tama˜ no de enclave de 8 GiB. Las pruebas efectuadas consisten en interactuar con el modelo detector de fallos. Por un lado, se llevar´ an a cabo dentro de un entorno de ejecuci´ on confiable, mientras que, por otro lado, se realizar´ an en un entorno est´ andar sin hacer uso del TEE. Se pretende observar como penaliza el rendimiento del servidor la utilizaci´ on de las t´ ecnicas de seguridad implementadas y concluir si la penalizaci´ on en el rendimiento puede o no suponer una merma significativa en el desempe˜ no del servicio que haga inviable el uso de las t´ ecnicas descritas. Para lograr esto, se ha desarrollado un script que permite realizar benchmarks de carga. Estos benchmarks permiten inferir datos de un tama˜ no espec´ ıfico, seleccionando el n´ umero de clientes que interact´ uan y eligiendo la cantidad de inferencias por cliente (v´ ease C´ odigo C). Desarrollo de Servicios Confiables en Kubernetes Utilizando TEEs 433 Tras haber realizado los benchmarks correspondientes, se han obtenido dos tablas. Estas tablas contienen datos sobre el n´ umero de clientes y las predicciones efectuadas por estos (iteraciones) que tuvieron lugar en las pruebas. El objetivo es analizar los tiempos de latencia (expresados en milisegundos) para determinar cuanto tiempo tarda el modelo en procesar informaci´ on en dos condiciones, un entorno seguro basado en TEEs y un entorno no seguro. Por un lado, tenemos la tabla tabla II, la cual contiene los datos de latencia utilizando un TEE. Por otro lado, obtenemos la tabla tabla III, que presenta los tiempos de latencia sin emplear un entorno confiable, es decir, sin ninguna medida de seguridad. C´ odigo C PSEUDOC ´ ODIGO PARA LAS PRUEBAS DE RENDIMIENTO. 11. A˜ nadir argumentos: 2"URL gRPC" 3"Certificado TLS para gRPC" 4"Tama˜ no del lote" 5"N´ umero de conexiones concurrentes" 6"N´ umero de iteraciones" 7 82. BenchmarkEngine(argumentos) 9 10 3. Crear un bucle asincr´ onico. 11 12 4. Establecer eventos a utilizar. 13 14 5. Crear una lista de conexiones asincr´ onicas. 15 16 6. Para cada valor en el rango de conexiones concurrentes se a˜ nade una conexi´ on asincr´ ona. 17 18 7. Ejecutar todas las conexiones asincr´ onicas esperando a que est´ en completas. 19 20 8. Cerrar el bucle de conexiones asincr´ onicas. 21 22 9. Tiempo actual <- al final de la ejecuci´ on. 23 24 10. Calcular y mostrar <- (Conexiones concurrentes , tiempos e2e, latencia media, transferencias por segundo). Tabla II AN´ ALISIS PERTINENTE ACERCA DEL IMPACTO DE LA LATENCIA UTILIZANDO UN TEE. Num. clientes Iteraciones 5 15 25 (ms) (ms) (ms) 17,082 1,959 4,712 20 14,724 10,054 9,231 50 20,853 19,096 24,792 100 50,151 48,362 49,902 200 100,256 96,207 102,048 300 138,770 142,619 158,115 400 194,711 161,808 168,470 450 250,081 191,557 183,281 500 302,489 205,392 208,757 600 339,786 315,411 386,833 700 447,126 317,887 438,891 800 531,647 428,751 444,681 Con base a los resultados obtenidos, lo primero que destaca es que el entorno confiable (tabla II) introduce una ligera sobrecarga que se traduce en una mayor latencia, lo que es esperable debido a las medidas de seguridad implementadas. Observamos que el procesamiento dentro de un TEE supera Tabla III AN´ ALISIS PERTINENTE ACERCA DEL IMPACTO DE LA LATENCIA SIN UTILIZAR UN TEE. Num. clientes Iteraciones 5 15 25 (ms) (ms) (ms) 12,049 1,436 1,163 20 2,873 3,004 3,110 50 7,341 6,336 5,828 100 13,595 13,024 11,192 200 39,864 23,543 21,899 300 59,068 38,540 35,070 400 86,309 56,676 55,571 450 115,871 64,341 59,429 500 125,805 76,746 66,062 600 187,190 104,278 84,600 700 217,089 129,156 106,321 800 287,341 152,953 126,758 los 300ms a partir de las 5 iteraciones realizadas por 500 clientes. Por otro lado en la tabla III que refleja las latencias obtenidas fuera de un TEE, independientemente del n´ umero de iteraciones, la latencia en t´ erminos generales se encuentra ligeramente por debajo de los 300ms. Al comparar las latencias m´ as altas de ambos escenarios, encontramos que en la tabla II se obtiene una latencia de ≈531ms, mientras que, en la tabla III se registra un m´ aximo de ≈287ms, Esto implica un diferencia de alrededor de 244ms entre ambos escenarios. Adem´ as de la figura 5, podemos observar c´ omo la sobrecarga disminuye a medida que se conectan m´ as clientes. Esto se debe a que el aumento en latencia debido al procesado dentro del TEE escala mejor cuando hay m´ as clientes conectados. La raz´ on entre las latencias observadas en la tabla II y la tabla III tiende a estabilizarse a medida que aumenta la demanda de procesamiento por parte de los clientes. VI. CONCLUSIONES Y L´ INEAS FUTURAS El desarrollo de servicios confiables utilizando contenedores supone un avance significativo en la protecci´ on de datos sensibles en entornos cloud. La introducci´ on de la tecnolog´ ıa Intel SGX en un entorno contenerizado con Kubernetes ofrece una soluci´ on tanto confiable como escalable y flexible, que permite mejorar la seguridad de los servicios en la nube actuales. Figura 5. Comparativa resultados obtenidos. El an´ alisis de los datos obtenidos en las pruebas que hemos realizado, revelan que la adopci´ on de un entorno de ejecuci´ on seguro (TEE) conlleva un incremento en el coste computacional. Este sobrecoste se estima en torno al 300 %, como se puede ver en la figura 5. A pesar de este incremento, nuestra valoraci´ on es que el sobrecoste es proporcionado y D. Ferreiro Ferr´on, M. L´opez Feijoo, I. L´opez Rom´an and A. V´azquez Saavedra 434 razonable si lo comparamos con el ofrecido por el resto de tecnolog´ ıas de procesamiento en el dominio cifrado [36]. La raz´ on principal para esta conclusi´ on es que operar dentro de un TEE nos permite proporcionar una capa adicional de seguridad para la aplicaci´ on, asegurando la integridad y la confidencialidad de los datos procesados. En un panorama donde las amenazas cibern´ eticas son cada vez m´ as frecuentes y avanzadas, esta seguridad mejorada se convierte en un requisito indispensable. Bas´ andonos en nuestra investigaci´ on, hemos identificado varias direcciones para futuras investigaciones, que detallamos a continuaci´ on: Realizar un an´ alisis detallado del comportamiento de Gramine para optimizar el rendimiento del servicio. Explorar otras implementaciones TEEs con contenedores [37] comparando el rendimiento ofrecido. Analizar y comparar el rendimiento y consumos de la tecnolog´ ıa utilizada con otras similares respecto al dominio del cifrado. Valorar el uso de im´ agenes de contenedores siempre cifradas. En este enfoque, las im´ agenes s´ olo se descifrar´ an durante el despliegue en el entorno seguro. La clave de descifrado necesaria ser´ a proporcionada por el desarrollador responsable. REFERENCIAS [1] TCS (Tata Consultancy Services). “Costs of Encrypted Computation: Why Fully homomorphic computations are Slow.” [Online]. Available: https://www.tcs.com/content/dam/globaltcs/en/pdfs/insights/whitepapers/Fully-homomorphic-encryptiondata-privacy.pdf [2] M. Sabt, M. Achemlal, and A. Bouabdallah, “Trusted Execution Environment: What It is, and What It is Not,” 2015 IEEE Trustcom/BigDataSE/ISPA, vol. 1, Aug. 2015, doi: https://doi.org/10,1109/ trustcom,2015,357. [3] A. Akram, A. Giannakou, V. Akella, J. Lowe-Power, and S. Peisert, “Performance Analysis of Scientific Computing Workloads on General Purpose TEEs.” Accessed: Mar. 19, 2024. [Online]. Available: https: //arch.cs.ucdavis.edu/assets/papers/ipdps21-hpc-tee-performance.pdf [4] Confidential computing, How to process data securely on third-party infrastructure. [Online]. Available: https://content.edgeless.systems/hubfs/ ConfidentialComputingWhitepaper.pdf. 2023. [5] Cloud Native Computing Foundation, CNCF Annual Report 2022. [Online]. Available: https://www.cncf.io/reports/cncf-annual-report-2022/. Accessed: Mar. 20, 2024. [6] Confidential Computing Consortium. “Confidential Computing: Hardware-Based Trusted Execution for Applications and Data” Confidential Computing Consortium. November 2022. [Online]. Available: https://confidentialcomputing.io/wp-content/uploads/sites/ 10/2023/03/CCC outreach whitepaper updated November 2022.pdf [7] V. Costan and S. Devadas, “Intel SGX Explained,” IACR Cryptology ePrint Archive, no. 2016/086, 2016. [Online]. Available: https: //eprint.iacr.org/2016/086. Accessed on: Mar. 14, 2024. [8] F. Kammel, M. Ylinen, and T. Feldman-Fitzthum, “Confidential Kubernetes: Use Confidential Virtual Machines and Enclaves to improve your cluster security,” Jul. 26, 2023. https://kubernetes.io/blog/2023/07/ 06/confidential-kubernetes/ (accessed Mar. 19, 2024). [9] B. Ngabonziza, D. Martin, A. Bailey, H. Cho, and S. Martin, “TrustZone Explained: Architectural Features and Use Cases,” in 2016 IEEE 2nd International Conference on Collaboration and Internet Computing (CIC), Nov. 2016, pp. 1-8, doi: 10.1109/CIC.2016.0651. [10] Arm Limited. (2021). Arm Confidential Compute Architecture. [Online]. Available: https://www.arm.com/architecture/security-features/ arm-confidential-compute-architecture [11] P.-C. Cheng, W. Ozga, E. Valdez, S. Ahmed, Z. Gu, H. Jamjoom, H. Franke, and J. Bottomley, “Intel TDX Demystified: A Top-Down Approach,” arXiv preprint arXiv:2303.15540, Mar. 2023. [Online]. Available: https://arxiv.org/abs/2303,15540. Accessed on: Mar. 14, 2024. [12] D. Kaplan, J. Powell, T. Woller, “Memory Encryption White Paper,” AMD, Oct. 18, 2021. [Online]. Available: https://www.amd.com/content/dam/amd/en/documents/epyc-businessdocs/white-papers/memory-encryption-white-paper.pdf. Accessed on: Mar. 14, 2024. [13] D. Kaplan, “Protecting VM Register State with SEV-ES,” AMD, Feb. 17, 2017. [Online]. Available: [AMD]. Accessed on: Mar. 14, 2024. [14] “AMD Secure Encrypted Virtualization Solution Brief,” AMD, Jan. 2020. [Online]. Available: https://www.amd.com/content/dam/amd/en/ documents/epyc-business-docs/solution-briefs/amd-secure-encryptedvirtualization-solution-brief.pdf.Accessedon:Mar,14,2024. [15] Confidential Computing Consortium, “Common Terminology for Confidential Computing,” December 2022. [Online]. Available: https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/ Common-Terminology-for-Confidential-Computing.pdf [16] Wang, Jinwen et al. “Interface-Based Side Channel Attack Against Intel SGX.” ArXiv abs/1811.05378 (2018): n. pag. [17] J. M´ en´ etrey et al., Attestation mechanisms for trusted execution environments demystified, Distributed Applications and Interoperable Systems, Cham: Springer International Publishing, 2022, pp. 95-113. [18] Rob Nertney, C¸ onfidential Compute on NVIDIA Hopper H100”, Nvidia, July 25, 2023. [Online]. Available: https://images.nvidia.com/aem-dam/ en-zz/Solutions/data-center/HCC-Whitepaper-v1,0.pdf [19] A. Mogage, R. Pires, V. Cr˘ aciun, E. Onica and P. Felber, ”Supply Chain Malware Targets SGX: Take Care of what you Sign,”2019 38th Symposium on Reliable Distributed Systems (SRDS), Lyon, France, 2019, pp. 52-528, doi: 10.1109/SRDS47363.2019.00016. [20] Hai Qiu, Jay Lee, Jing Lin, ”Wavelet Filter-based Weak Signature Detection Method and its Application on Roller Bearing Prognostics,”Journal of Sound and Vibration, Vol. 289, pp. 1066-1090, February, 2006, doi: 10.1016/j.jsv.2005.03.007. [21] Intel Device Plugins for Kubernetes, Overview. [Online]. Available: https://intel.github.io/intel-device-plugins-for-kubernetes/ README.html. 2024. [22] Intel® SGX Software Installation Guide, For Linux* OS. [Online]. Available: https://download,01.org/intel-sgx/latest/linux-latest/ docs/Intel SGX SW Installation Guide for Linux.pdf. 2024. [23] Intel(R) SGX Reference Launch Enclave. [Online]. Available: https: //github.com/intel/linux-sgx/blob/master/psw/ae/ref le/ref le.md. 2023. [24] Kubernetes - Installing with regular manifests, cert-manager. [Online]. Available: https://cert-manager.io/v1,1-docs/installation/kubernetes/. 2024. [25] Sensor anomaly detection, Kaggle.com. [Online]. Available: https: //www.kaggle.com/code/rkuo2000/sensor-anomaly-detection/notebook. 2020. [26] Welcome to Python.org. [Online]. Available: https://www.python.org/. 2024. [27] TensorFlow. [Online]. Available: https://www.tensorflow.org/. 2024. [28] GRPC. [Online]. Available: https://grpc.io/. 2024. [29] Gramine, Gramineproject.io. [Online]. Available: https: //gramineproject.io/. 2024. [30] C.-C. Tsai, D. E. Porter, y M. Vij, Graphene-SGX: a practical library OS for unmodified applications on SGX, Proceedings of the 2017 USENIX Conference on Usenix Annual Technical Conference, 2017, pp. 645658, doi: 10.5555/3154690.3154752. [31] MarbleRun: the service mesh for confidential computing, Edgeless.systems. [Online]. Available: https://www.edgeless.systems/ products/marblerun/. 2024. [32] Reference Architecture for Privacy Preserving Machine Learning with Intel® SGX and TensorFlow* Serving. [Online]. Available: https://www.intel.com/content/www/us/en/developer/articles/technical/ privacy-preserving-ml-with-sgx-and-tensorflow.html. 2024. [33] Edgeless RT. [Online]. Available: https://github.com/edgelesssys/ edgelessrt. 2024. [34] Provisioning Certificate Caching Service (PCCS). [Online]. Available: https://github.com/intel/SGXDataCenterAttestationPrimitives/blob/ master/QuoteGeneration/pccs/README.md. 2024. [35] Remote Attestation for Multi-Package Platforms using Intel® SGX Datacenter Attestation Primitives (DCAP). [Online]. Available: https://download,01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel SGX DCAP Multipackage SW.pdf. 2021. [36] Performance Impact Analysis of Homomorphic Encryption: A Case Study Using Linear Regression as an Example, Researchgate.net. [Online]. Available: https://www.researchgate.net/publication/ 375473628 Performance Impact Analysis of Homomorphic Encryption A Case Study Using Linear Regression as an Example. 2023. [37] CoCo, Confidential containers. [Online]. Available: https: //confidentialcontainers.org/. 2024. Desarrollo de Servicios Confiables en Kubernetes Utilizando TEEs 435