Segurilatam 019

artículo técnico CCTV y Control de Accesos Podemos dividir el proceso en tres partes diferenciadas. La primera es la parte en la que se obtiene la fuen- te de los datos desde el navegador (cámara web, cámara IP, etc. el Me- diaStream). La segunda parte es la conexión PeerConnection, en la que se intercambia entre los pares los flu- jos obtenidos en la primera parte. Por último, el DataChannel en la que se intercambia otros datos de la aplica- ción necesarios. En el primer proceso, podemos te- ner acceso al micrófono o la cámara en nuestro navegador y es el propio usuario el encargado de permitir o no su utilización. Es en el segundo proceso, el de comunicación entre pares (PeerCon- nection), cuando los datos “salen” de nuestro ordenador y viajan por la red. Para la negociación se utiliza el protocolo ICE ( Interactive Connectivity Establishment ), que suele necesitar, debido a las restricciones de red, los protocolos STUN y TURN (requirien- do un servidor para ello) para que se puedan establecer las conexiones re- queridas entre los pares y éstos pue- dan “verse” en la red y establecer una conexión directa. Las sesiones se rea- lizan a través de SDP, que describe la forma de establecer las sesiones entre los pares y define el proceso de offer/ answer entre ellos. Una vez que el pro- ceso de signaling se establece y com- pleta, el transporte de los datos entre los pares comienza y se inicia una co- municación por protocolo UDP. Ahora bien, todo este proceso de comuni- cación y transferencia de información puede ser interceptado por un ma- lware, siendo de vital importancia que toda la información esté encriptada. Además, en aplicaciones en las que uno de los clientes sea, por ejemplo, una cámara de seguridad, los datos que se transmiten son especialmente sensibles y deben ser protegidos. Protocolos seguros El estándar WebRTC utiliza y obliga para todos estos procesos protocolos segu- ros en su implementación destacando los siguientes: HTTPS: La conexión al servidor que se encarga de la negociación se debe hacer a través de HTTPS; no es posible establecer conexiones no seguras den- tro del protocolo. DTSL ( Datagram Transport Layer Se- curity ): Este protocolo se utiliza para establecer las sesiones, trabaja basa- do en TLS, pero adaptado al transporte por UDL proporcionando una seguridad equivalente. Para el proceso de offer/ answer de la comunicación, se utilizan certificados autofirmados para proteger el contenido de la negociación, de ma- nera que la información sensible queda a salvo. SRTP ( Secure Real-time Transport Protocol ): WebRTC utiliza una versión segura del protocolo RTP, el SRTP. Se puede considerar como una versión ligera del protocolo DTSL y se utiliza para el transporte de los datos en sí, en la que la carga ( payload ) del paquete está siempre encriptada. Conclusión En conclusión, bajo nuestra propia ex- periencia en Panoptico, el protocolo WebRTC es uno de los más seguros que se pueden utilizar para soluciones de streaming y conferencias, además de ser el más rápido de su generación. Es seguro porque depende de la segu- ridad de los propios navegadores. Es seguro porque obliga a que todas las comunicaciones estén encriptadas y sean seguras, y emplea protocolos de comunicación comunes, abiertos y pro- bados en infinitos escenarios. Es segu- ro porque tiene una fuerte comunidad detrás que vela por la actualización y mejora destacando que, al ser un proyecto abrigado por la W3 y ser de código abierto, es transparente en su desarrollo y está sujeto al escrutinio de la comunidad de desarrolladores. No deja una implementación ofuscada por código privativo en la que no sabemos qué es lo que nos está haciendo en las sombras el software . Tecnologías que permiten llevar a cabo todas las funcionalidades del protocolo WebRTC. / Fuente: (Grigorik, 2013). Tercer cuatrimestre 2021 / 117