Mistérios do SMS – bits, bytes, mitos e modelos mentais

10 06 2012

Ainda sobre mitos

Call flow for the Mobile Terminated short mess...

Call flow for the Mobile Terminated short message service (Photo credit: Wikipedia)

Quando eu atuava com desenvolvimento de soluções para  Telematics Security, certa vez, conversando com um engenheiro de suporte que me apresentaram como o papa dos SMS (Short Message Service) de uma representante local de um fabricante de módulos de comunicação GSM, perguntei a ele o quanto o  módulo dele era compliance com o  padrão 3GPP TS 23.040 (Technical Realization of the Short Message Service) e a resposta dele foi que não tinha nada a ver uma coisa com a outra, que o manual do produto deveria ser seguido sempre.  Eu repeti a questão de uma outra forma e  a resposta foi similar! Aquela resposta não fazia sentido algum, até poucos meses antes eu havia testado um módulo de comunicação de um outro fabricante e encontrei problemas de aderência que reportei ao fabricante;  ele comentou que era um problema conhecido e que em breve isto seria corrigido, de verdade levou 3 anos para isto ocorrer, mas tudo bem. Porém preferi  ignorar a resposta deste engenheiro brasileiro e preferi falar sobre outros assuntos, que de verdade estavam mais ligados a nossa pauta.

Noutro momento, perguntei para um engenheiro de suporte de um outro fornecedor, como eu ativava o MUX do módulo para operar com canais simultâneos de GPRS e SMS, o mesmo falou que isto não era possível; bom olhando o manual do módulo dele em alguns minutos vi referências ao MUX e pedi exatamente o manual no qual aquela linha daquela página do manual estava se referindo, ele me perguntou para que eu queria aquele documento? Pois tudo o que eu precisava estava no manual no qual eu estava lendo. Com o tempo fui descobrir que entre application notes, datasheets e manuais, o produto dele tinha cerca de 9 documentos e só aquele manual era insuficiente.

Bit nosso de cada dia

Tempos depois, numa certa empresa, verifiquei que havia uma tabela que informava com que tipo de módulo de segurança se comunicava com seu gateway de segurança  usando que tipo de configuração ou operadora de telecom. Achei aquilo tudo muito estranho! Isto porque era um contexto no qual eu conhecia (SMS e Interconexões de SMSC entre redes GSM heterogêneas) , sendo-se que não fazia sentido aquela quantidade de restrições e desde o primeiro momento aquilo tinha cara e cheiro de bug!   Perguntei para algumas pessoas sobre aquilo e fui recebendo os mais diversos feedbacks, onde fui percebendo que havia uma série de modelos mentais no qual eu não concordava, pois não faziam sentido!  E quando eu comentava que aquilo não podia ser daquela forma eu recebia os mais diversos feedbacks, normalmente que eles tinham grande experiência naquilo e era assim que tudo funcionava.

Pouco tempo depois descobri uma função de uma biblioteca (utilizada numa série de produtos)   que possuía uma série de controles de segurança para buffer overflow e só utilizava métodos seguros, totalmente MISRA C Compliance, mas fazia um parser equivocado, não compliance com o standard  3GPP TS 23.040, onde o tratamento de um dado byte ( FIRST OCTET) em determinadas mensagens (do tipo SMS DELIVER), era a causa raiz deste e de outros problemas para o qual existia toda uma árvore de processos e que gerou muitos efeitos colaterais por anos para a empresa. Este byte é de verdade um bitfield onde deveria ser tratado apenas 2 bits mas em (aproximadamente) 25% dos  casos o valor do byte era o mesmo e num dado contexto ele era 100% dos caso daquele forma, dependendo dos cenários em bancada. E ao questionarem um parceiro que dava suporte sobre esta tecnologia, o suporte afirmou que não havia nada de errado nesta rotina!

O fato é que já havia um modelo mental de que a comunicação com SMS é problemática, onde este muitas vezes acabava atrapalhando muitos engenheiros de realizar um troubleshooting mais profundo e rastrear a causa raiz de alguns problemas, não só este como de vários outros relacionado a esta tecnologia.

Olhando os manuais do módulo de comunicação, realmente pelos exemplos era possível chegar a conclusão equivocada, mas o engenheiro de suporte não poderia ter deixado aquilo passar por uma razão simples, esta é uma questão básica no parser de SMS; e o pior, com o tempo fui analisando outras rotinas de tratamento de SMS e este não foi o único caso; onde sempre que eu tentava entender eu recebia o feedback que quem falou para fazer assim foi um fulano ou um sicrano que eram papas no assunto, o mais legal foi receber o feedback de que uma empresa especializada contratada vez um security code review e a aplicação era segura. Puxa vida! A empresa verificou as construções de código, mas ela desconhecia os 11 standards e 5 protocolos implementados ali, isto ela não tinha condição alguma de alegar que estava implementado de forma correta apenas que empregava construções de código seguro. E outro modelo mental, mais específico estava presente ali.  E com o tempo, conversando com os engenheiros pais das crianças, eles foram muito sinceros comigo e disseram que SMS era algo que eles conheciam muito superficialmente e quem dizia que eles eram experts no assunto eram os outros, não eles. Pois é, eu conheço muito bem este cenário e só por esta sinceridade e humildade, eles até hoje tem o meu respeito, até pelo seu amplo domínio de várias tecnologias entre outras razões.

Por incrível que pareça num encontro fechado de um comitê de  Telematics Security, quando estávamos tratando o assunto SMS percebi que muitos mitos sobre SMS estavam arraigados nas mentes da maioria das pessoas que ali estavam,  por exemplo que era impossível enviar mensagens com mais de 140 bytes! Oras bolas, no mesmo FIRST OCTET citado acima, há um bit chamado TP-UDHI que é utilizado especialmente para indicar quando se está trabalhando com mensagens que podem chegar até a 4K. Quando comentei isto, um engenheiro (um cara excelente diga-se por passagem) comentou que já havia visto este bit mas não entendeu exatamente para que ele servia; ponto para este cara, ele foi muito honesto! E quase tudo o que comentei foi colocado em xeque, porque eu era desconhecido naquele meio, então foi perguntado para um representante de uma operadora de telecom que estava ali, ele não tinha condições de confirmar, então ele viu com a engenharia dele e então tudo o que comentei foi confirmado! Ufa, que ciclo complexo de confirmação.

Na esmagadora maioria das vezes, a limitação em trabalhar com este tipo de mensagem está por trás daqueles que implementam os parsers de SMS parcialmente  e vão gerando firmwares, softwares aplicativos e servidores não “compliance” com a 3GPP TS 23.040 e tornam-se grandes vetores de propagação de mitos e  modelos mentais equivocados por trás desta tecnologia. Da mesma forma acontece com a criptografia, é mais comum encontrar problema nas implementações de software do que nos algoritmos em si.

Por final, neste comitê e em outros grupos, seja empresas, SMS virou minha especialidade e às vezes por falta de outra opção, já ajudei a homologar brokers de comunicação, modelo de segurança de arquiteturas de aplicação e até a “condenar players” que se recusavam a implementar o standard básico e insistiam em mitos estapafúrdios; algumas vezes eu tive a sensação que estava entre farsantes, onde aquela velha máxima de que nada é tão horrível que não possa piorar apresentava provas de conceitos constantes. Tudo bem que por trás de uma implementação há toda uma cadeia de serviços que deve ser analisado, como custos implicados em se utilizar o recuso, suporte da operadora, entre outros fatores; mas em absolutamente todos os casos que analisei, o problema estava justamente no desconhecimento das possibilidades.

Por exemplo, SMS não tem confirmação! Outro mito, no padrão há um tipo de mensagem chamado SMS‑DELIVER‑REPORT  pelo qual é possível se saber se a mensagem foi entregue com sucesso ou não. Aliás, eu gostaria muito de entender como alguém que desenvolve soluções de Telematics Security,  que seja apenas de “Segurança” tem a coragem de desenvolver um parser de SMS sem este tipo de suporte  e afirmar que sua  implementação é segura e  completa!  A resposta que eu sempre ouvi é que a confirmação é sempre feita por TCP ou UDP,  oras bolas! Isto é uma coisa completamente diferente! Tudo bem, há operadoras GSM que não externam mensagens de REPORT, isto é uma outra história. Neste caso, minha recomendação é simples:  não desenvolvam soluções de segurança com esta operadora, e fim de papo.

Quem certifica o certificador?

Curiosamente, certa vez passei por uma situação muito sinistra, onde 21 soluções técnicas estavam sendo avaliadas num processo de operação assistida,  e apenas duas estava sendo reprovadas num determinado teste com SMS. E uma delas era a pelo qual eu era responsável,  curiosamente um broker de SMS estava enviando uma mensagem com formatação ERRADA, indicando que ele estava enviando a mensagem num dado formato, mas na realidade ele estava enviando em outro, porém as soluções pelo qual eu era responsável e a de uma outra empresas que fazia parte desta fase específica de testes, realizava o parser de forma correta e os outros players não.  Veja que situação confusa: quem havia  implementando um parser errado  estava passando no teste e quem havia implementado corretamente estava sendo reprovado, por que os erros estavam em compliance com um histórico erro de parser. E então eu tinha duas opções: se adequar ao erro  ou forçar o modelo correto? Adivinha qual foi a opção que eu escolhi? Pois é, e por mais que eu explicasse o que estava ocorrendo, eu estava representando quem estava sendo reprovado. No final tudo se acertou e participei do troubleshooting até o último bit e naquele momento ficou a exposição de uma clássica dificuldade de mercado.

Mas não foi a primeira vez que isto ocorreu, certa vez um equipamento de segurança pelo qual eu era responsável estava sendo reprovado numa homologação simplesmente porque estávamos implementando um protocolo de foram correta, porém a plataforma de testes tinha um bug e o auditor estava considerando o resultado que o software dele estava utilizando como correto, tive que decodificar os datagramas para ele na hora e mostrar que a implementação da plataforma estava errada e em mais de um caso. Foi um processo cruel, mais passei por ele. Porém eu havia ficado com uma dúvida, como os outros equipamentos passaram neste teste?  Eu então questionei colegas de empresas concorrentes e alguns deles responderam: cara, não questionávamos o auditor, se ele diziam que o datagrama tinha que estar de certa forma, nós o fazíamos. Naquele exato momento, eu tive a sensação que estava num show de horrores.

E justamente por questões básicas como desconhecimento dos princípios mais elementares sobre SMS, acaba ocorrendo falhas na:

  • Engenharia de Requisitos
  • Arquitetura de Sistemas
  • Gerenciamento de Aquisições, por uma pura falta de RFI (Request For Information) para a contratação de serviços
  • Engenharia de Suporte
  • Cadeia de Serviços
  • etc….

Por exemplo,  já vi casos onde  contratos foram  fechados indevidamente e geraram problemas técnicos diversos apenas pelas pessoas não saberem o que estavam comprando em matéria de large account para SMS e porque os técnicos falharam na validação do contrato  ou porque os técnicos especificaram corretamente, mas a operadora de telecom entregou outro serviço. Ou porque a plataforma de testes funcionava de um jeito e a plataforma de produção funcionava de outra forma. Tudo num efeito cascata tragicômico  e em muitos casos haviam conceitos não compreendidos amparados por mitos e modelos mentais baseados no vapor, em ilusões.

…o universo e tudo mais!

No fundo, este problema não é só com SMS, nem com operadoras de telecom, nem com módulos de segurança inseguros, ele está ligado a um comportamento  mais sintomático relacionado com o comportamento humano: as pessoas tem uma tendência muito grande a caírem em farsas e trapaças, e não estou falando da famosa série que exibia filmes de Hitchcock.

Por outro lado, em 1990,  no meu primeiro emprego trabalhando com computação, onde eu lá realizava manutenções em códigos  desenvolvidos em IBM BASICA e COBOL, e nas horas vagas eu era digitador (que na época tinha um grande status), ganhei o apelido de Hitchcock. Talvez, porque eu sempre tinha uma história de terror para contar. Outro dia no trabalho um colega comentou: cara, seria muito legal se você pudesse visitar um cliente, você conta suas histórias de terror e eu como a empresa pode ajudar a resolver os problemas dele, que tal? Engraçado, e parece que 22 anos depois eu não mudei muito!

Por outro lado ir a fundo nos problemas custa caro! E muitas vezes os clientes não estão dispostos a pagar por isto, isto gera uma outra tendência sintomática, que não poderia de forma alguma interferir o trabalho das engenharias, mas infelizmente a realidade é outra.

De verdade em alguns momentos saber escovar neurônios e axiomas  pode ser até  mais importantes do que saber escovar bits.  E mitos e modelos mentais sempre existirão, por mais que tentemos combater os mentirosos sintomáticos e os efeitos colaterais de um equívoco ou de uma mentira  bem contada e repetida com exaustão, muitas vezes não temos tempo para isto,  temos mais o que fazer pois estas são tarefas hercúleas de resultado imediato duvidoso, mas sempre vale tentar! Afinal, é como diz o velho ditado, água mole em pedra dura…

Namastê!


Ações

Information

One response

30 07 2012
techberto

Na realidade você não tem que homologar nas operadoras, de verdade você tem que apenas firmar contratos com as operadoras para adquirir uma Large Account. Porém muito cuidado nesta hora, há um grande potencial para brokers com capacidade de envio de mensagens binárias (8 bits) e normalmente os contratos do gênero são apenas para mensagens texto (7 bits). Tome bastante cuidado nesta contratação.

Mas querendo mais informações envio email para alberto+sms at g-hc.org

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s




(in)security, threats, risks, hackings and some insights of my hermetic box or from the interesting authors

Nota Bene

NOTES, COMMENT AND BUZZ FROM EUGENE KASPERSKY – OFFICIAL BLOG

CYBER ARMS - Computer Security

Cyber War News and Business Computer Tips

Delirios Digitais

mais delirios, mais digital.

Kumpera

Just another Wordpress.com weblog

Durepoxi Deluxe

Just another WordPress.com weblog

Information Security

Just another WordPress.com weblog

Sérgio Storch

Meu percurso de idéias, pensamentos, livros, filmes, relacionamentos

Prof. Ricardo Castro - Auditoria de Sistemas e Segurança da Informação

Blog do Prof. Ricardo Castro para divulgação de notícias relevantes para os

Clebeer's Pub

Drinks, Hack and Linux...

agaelebe

master of n00bs - now at www.agaelebe.com.br

#O Blog Seguro#

Seguro 100% tal qual divisão por 0!

freak, as in freakdom

Just another WordPress.com weblog

The Cryptography Developer

Tips and tricks for coding the PKI world

Letras sem música

Letras que procuram uma música

Python Fluente

Just another WordPress.com site

Zero Zero Confirma

Política, atualidades e bizarrices.

Galeno's Blog

Just another WordPress.com site

Fotografia de Gabriela Barreto

www.gabrielabarreto.com.br

meifumadō

Just another WordPress.com weblog

Communication and Digital Marketing

Seminário de Los Hermanos S.J.

I Encontro Latino Americano e Caribenho dos Irmãos Jesuítas - 16-29/07/2011

lsec

Just another WordPress.com site

Sobre historia

Um blog para registrar, refletir e conversar sobre história.

Outro Espectro

Just another WordPress.com weblog

caderninho do belasco

notas, impressões e outras coisas sem muita importância

Blog do Sergio Prado

O Universo dos Sistemas Embarcados

Acorda!

Cutucando quem dorme para o próprio futuro!

Bcsanches's Weblog

Opinião e um pouco de código

Ana&Max

Bem vindos!

Ijé Ófè

Raça Livre

Life, the Universe and Everything...

Life in the Cloud, the Java Universe and Everything else.

Luís Leão

Arduino, Processing, APIs e outras coisas interativas

Brazilian RTOS blog

O blog oficial do BRTOS, um sistema operacional 100% brasileiro.

FIXA SAMPA

fixas encontros dicas trocas idéias cultura arte esporte etc

SouJava

Sociedade de Usuários da Tecnologia Java

coberturapoetica

um portal de livre exposição autoral

Alan C. Assis

a blog about computers and other funny things

Beer Hacking

Profissionais de Segurança da Informação se metendo a fazer cerveja no melhor estilo DIY. E tentando ser o mais opensource possível.

Nelson Biagio Jr

Life, Project Management, Leadership, Business, Politics and other little things

%d blogueiros gostam disto: