top of page

Inerente a qualquer serviço de streaming encontra-se o problema de como manter os dados enviados e as próprias transmissões seguros e de acesso limitado. Este problema torna-se um de extrema relevância para qualquer empresa ou entidade que forneça serviços de streaming cujo acesso se tenha de manter controlado ou deva ser obtido apenas através de uma autenticação válida, por exemplo provedores de serviços IPTV (MEO, NOS, Vodafone, entre outros).

Dependendo do tipo de arquitetura adoptado para transmissões streaming, poderão existir várias vulnerabilidades diferentes sendo que ataques repudiation, denial of service (DoS) ou forgery se encontram entre os mais comuns e mais graves para um provedor deste tipo de serviços. A proteção contra este tipo de ataques vai desde a proteção física dos vários elementos presentes na rede (ex. autenticação biométrica para acesso a servidores ou outros elementos da rede) até ao desenvolvimento de protocolos para streaming seguro.

Em arquiteturas mais predominantes como cliente-servidor, existem já conhecidas vulnerabilidades de segurança. Ataques DoS são uma variedade de ataques muito comuns e perturbam a capacidade de um servidor de responder ou servir própriamente um cliente. Existem diversas maneiras de colmatar estas vulnerabilidades baseadas tanto em soluções de hardware, como de software [REF para Seg. DoS]. Outros ataques, como TCP session highjacking são mais difícies de prevenir e acarretam consequências catastróficas para um serviço de distribuição através de streaming, permitindo aos atacantes desviar streams inseguras de utilizadores legítimos, do servidor para os seus próprios terminais. Em arquiteturas P2P, surgem outras vulnerabilidades associadas à possível existência de nós maliciosos na rede. Estes nós podem criar disrupções DoS noutros nós impedindo que tenham acesso à stream. As vítimas atacadas podem ser impedidas de receber os chunks da stream de que necessitam através da ocupação total da largura de banda do servidor por parte dos atacantes, ou ser sobrecarregadas de pedidos por parte de outros peers, caso um atacante anuncie à rede que a vítima possuí múltiplos chunks da stream.

Vulnerabilidades dependentes da arquitectura

Encriptação, autenticidade e integridade da stream

Vários protocolos foram criados com vista na segurança da stream enquanto esta atravessa a rede, sendo que um dos de maior relevância é o Secure Real-Time Transport Protocol (SRTP). Neste protocolo, todos os pacotes de dados a ser enviados para a rede são encriptados através de um qualquer forte algoritmo de encriptação, normalmente o Advanced Encryption Standard (AES). Deste modo, mesmo que a stream seja interceptada na rede, os dados nela contidos serão ilegiveis para qualquer utilizador que não possua a chave de desencriptação correta para aquela stream. Visto que o AES é um algoritmo de chave simétrica isto é, a chave usada para encriptar e desencriptar um dado bloco de dados é a mesma, os nós comunicantes da rede têm de possuir uma cópia desta chave, muitas vezes chamada de chave de sessão, para poder ler corretamente a informação partilhada entre ambos. O SRTP pode fazer uso de vários protocolos de troca de chaves sendo que os mais usados implementam o método de Diffie-Hellman, ou variações deste, que fazem uso de algoritmos de chave pública. Neste protocolo, a chave trocada entre os dois nós é apelidada de chave mestra. A chave mestra é aplicada a uma função de derivação de chaves igual para ambos os nós comunicantes, e a partir dela serão obtidas todas as chaves usadas no contexto criptográfico da transmissão, incluindo a chave de sessão usada pelo AES. O uso desta função permite que apenas tenha de ser trocada uma chave, a chave mestra, entre os nós comunicantes sendo as restantes chaves derivadas a partir dela. Isto elimina o risco de intercepção das chaves de sessão na rede. A função de derivação é aplicada periodicamente durante uma sessão de streaming garantindo benefícios de segurança adicionais, pois previne que um atacante que tenha eventualmente conseguido obter uma chave de sessão consiga desencriptar dados encriptados com chaves de sessão geradas anterior ou posteriomente à sua. Isto previne e limita o efeito de certos ataques man-in-the-middle.

 

Garantida a segurança dos dados na rede, é necessário ainda garantir a integridade e autenticidade dos mesmos ou seja, garantir que os dados não foram modificados quer através de erros, quer através de actos maliciosos intencionais e ainda que provêm da origem esperada. Vários ataques como ataques pollution, usam este tipo de vulnerabilidades para colocar aquilo a que se chama junk data na stream de modo a corromper esta última ou a máquina do receptor. Para tal, no SRTP faz-se uso do algoritmo HMAC-SHA1 que, usando uma chave específica e várias informações presentes no cabeçalho do pacote a ser enviado, gera uma tag de autenticação enviada com o pacote. Este processo é repetido do lado do receptor que, computando também ele a tag do pacote recebido e verificando que é igual à tag nele contida, confirma assim a integridade e autenticidade da origem da mensagem recebida. Qualquer tentativa de alteração dos pacotes de dados por parte de algum atacante seria rapidamente descoberta pois iria alterar a tag calculada pelo receptor. Este mecanismo evita ataques que explorem falhas no processo de autenticação da fonte de onde originam os pacotes. As referidas tags são ainda guardadas pelo recetor para evitar possíveis ataques replay ou seja, evitar a reutilização de uma tag por parte de nós maliciosos.

 

Outro protocolo de interesse que merece ser mencionado é o Real-Time Messaging Protocol S (RTMPS) que establece uma sessão RTP normal encapsulada numa sessão SSL/TLS, fazendo uso das medidas de segurança implementadas por este último. Existem ainda outros protocolos para comunicações streaming seguras desenvolvidos por pequenas empresas de segurança embora sejam menos usados ou usados para aplicações muito específicas. Podendo existir algumas diferenças, a base criptográfica deste tipo de protocolos é muito semelhante à descrita nesta secção.

SEGURANÇA

bottom of page