- PGEE-HOME

Transcrição

- PGEE-HOME

Universidade Federal do ABC
Pós-graduação em Engenharia Elétrica
Daniel Pinheiro Carlésimo
Análise de vulnerabilidades dos sistemas gsm/gprs
por meio de recursos complementares de hardware
e software
Dissertação
Santo André - SP
2013
Daniel Pinheiro Carlésimo
Análise de vulnerabilidades dos sistemas gsm/gprs
por meio de recursos complementares de hardware
e software
Dissertação
Dissertação apresentada ao Curso de Pós-graduação da
Universidade Federal do ABC, como requisito parcial
para obtenção do grau de Mestre em Engenharia
Elétrica
Orientador: Prof. Dr. Carlos Eduardo Capovilla
Coorientador: Prof. Dr. Ivan Roberto Santana Casella
Santo André - SP
2013
Dedicado a Jayme Rocha
Pinheiro, o formidável.
i
Agradecimentos
Agradeço,
ao Prof. Carlos E. Capovilla por ter acreditado neste trabalho, abrindo-me novamente as
portas do mundo acadêmico com maestria e muita dedicação.
ao Prof. Ivan R. S. Casella e sua valiosa coorientação.
aos prezados Alexsander Loula, André Bassoli, Arnaldo Clemente e João Machado da NI
do Brasil.
ao Prof. Dr. Francisco Müller e alunos Edgleyson Dias, Jeferson Leite e Andrey Silva,
estimados colegas da Universidade Federal do Pará.
ii
Uma viajem de mil milhas inicia-se com
o movimento de um pé.
LaoTzu
iii
Resumo
Concebido para ser seguro e confiável, o sistema de telefonia móvel de segunda
geração conhecido como GSM (Global System for Mobile Communication) teve
com o passar dos anos sucessivas fragilidades identificadas. Com a eliminação
gradativa de fatores que indiretamente contribuı́am para sua robustez (como
o elevado custo da infraestrutura de hardware, softwares proprietários e informações protegidas), observou-se a criação de diferentes frentes de estudo
que culminaram no surgimento de técnicas de ataque ao sistema. Tendo sua
contemporaneidade assegurada através da associação com o GPRS (General
Packet Radio Service), o sistema ainda vigora entre as diversas frentes de
serviço da atualidade, tais como transações financeiras, rastreamento veicular, sensoriamento e monitoramento em redes inteligentes de energia elétrica
(Smart Grids) e até mesmo conexão alternativa para aparelhos celulares de
terceira geração. Em particular, o presente trabalho visa retratar a real segurança dos sistemas GSM/GPRS, explorando lacunas conceituais que permitam
contornar o modelo de segurança em vigor. Para tal, os capı́tulos seguintes
descrevem as principais caracterı́sticas do GSM/GPRS, seguido pelo estudo e
identificação de vulnerabilidades inerentes aos próprios requisitos que o originaram e, finalmente, a comprovação experimental de suas fragilidades com o
auxilio de hardware e softwares abertos ao público em geral.
Palavras-chave: GSM. GPRS. Segurança. Vulnerabilidade.
iv
Abstract
Designed to be safe and reliable, the second-generation mobile phone system
known as GSM (Global System for Mobile Communication) had some weaknesses identified over the years. The gradual elimination of factors that indirectly contributed to its robustness (like the high cost of hardware infrastructure,
proprietary software and protected information) has considerably simplified the
researches, consequently allowing the creation of different system attack techniques. Lately associated to the GPRS (General Packet Radio Service), the
system still prevails in different contemporary applications, such as financial
transactions, vehicle tracking, smart grids systems and even alternative connection to third-generation handsets. In particular, this master thesis aims
to reveal the actual security of GSM/GPRS by exploring conceptual gaps that
may be used to bypass the security model in place. To this end, the following
chapters describe the main GSM/GPRS characteristics, the requirements gap
and its resulting vulnerabilities, finally followed by some experimental practice
making use of open-hardware and open-software.
Key-words: GSM. GPRS. Security. Vulnerability.
v
Lista de Figuras
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
Arquitetura simplificada GSM . . . . . . . . . . . . . . . .
Arquitetura simplificada GPRS . . . . . . . . . . . . . . .
Interfaces entre os elementos de rede . . . . . . . . . . . .
Modelo de camadas da interface Um . . . . . . . . . . . .
Canais fı́sicos versus canais lógicos . . . . . . . . . . . . .
Alocação do espectro segundo FDD . . . . . . . . . . . . .
Acesso múltiplo por divisão de tempo e frequência . . . . .
Tipos de burst e suas caracterı́sticas . . . . . . . . . . . . .
Classificação geral dos canais lógicos . . . . . . . . . . . .
Diagrama sequencial de autenticação e encriptação . . . .
Algoritmo de autenticação A3 . . . . . . . . . . . . . . . .
Diagrama sequencial de encriptação . . . . . . . . . . . . .
Algoritmo calculador de chave de seção, A8 . . . . . . . .
Algoritmo COMP128 de autenticação e cálculo de chave de
Algoritmos-cifra de encriptação pertencentes à famı́lia A5 .
3.1
3.2
3.3
3.4
3.5
Arquitetura GSM com hardware e softwares abertos . . . . .
Visão geral sobre a USRP1 . . . . . . . . . . . . . . . . . . .
Leitores e programadores de SIM card . . . . . . . . . . . .
Derivação do Ki de SIM cards contendo o COMP128v1- SIM
Testes com USRP1 na câmara anecóica da UFABC . . . . .
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
Registro de falhas, OpenBTS P2.8 . . . . . . . . . . . . . . . . . . . . .
Tentativas e incompatibilidades observadas durante etapa de integração
Registro de falhas, OpenBTS-UHD . . . . . . . . . . . . . . . . . . . .
Obtenção do IMSI em cleartext . . . . . . . . . . . . . . . . . . . . . .
Atribuição de TMSI ao IMSI capturado . . . . . . . . . . . . . . . . . .
Leitura dos identificadores de rede através da MS . . . . . . . . . . . .
Handover inesperado do iPhone . . . . . . . . . . . . . . . . . . . . . .
Configurações do Galaxy SIII referentes à conexão GSM . . . . . . . .
Spoofing de rede em ambiente controlado (câmara anecóica) . . . . . .
Envio de SMS através do OpenBTS-UHD . . . . . . . . . . . . . . . .
Recebimento do SMS transmitido . . . . . . . . . . . . . . . . . . . . .
vi
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
seção
. . . .
. . .
. . .
. . .
Easy
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
13
14
15
16
17
19
20
22
28
29
31
32
32
33
. . . .
. . . .
. . . .
V8.20
. . . .
.
.
.
.
.
39
40
45
48
56
.
.
.
.
.
.
.
.
.
.
.
58
59
60
61
62
62
64
64
66
66
67
.
.
.
.
.
.
.
.
.
.
.
Lista de Tabelas
2.1
Faixas de Frequência GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1
3.2
Cálculo de impactos do clock sobre as faixas de frequência GSM . . . . . . 42
Frequências de trabalho das antenas quad-band . . . . . . . . . . . . . . . 44
vii
Lista de Acrônimos
3GPP
AB
ADC
AP
ARFCN
AuC
BCCH
BN
BSC
BSIC
BSS
BTS
CA
CBCH
CC
CC
CCCH
CCH
CIA
CPU
DAC
DB
DCCH
DoS
EEPROM
EIR
ERB
ETSI
FAC
FACCH
FB
FCCH
FDD
FDMA
FN
3rd Generation Partnership Project
Access burst
Analog to Digital Converter
Access Point
Absolute Radio Frequency Channel Number
Authentication Center
Broadcast Control Channel
Bit Number
Base Station Controller
Base Transceiver Station Identity Code
Base Station Subsystem
Base Transceiver Station
Cell Allocation
Cell Broadcast Channel
Call Control
Country Code
Common Control Channel
Control Channels
Confidentiality, Integrity and Availability
Central Processing Unit
Digital to Analog Converter
Dummy burst
Dedicated Control Channel
Denial of Service
Electrically Erasable Programmable Read-Only Memory
Equipment Identity Register
Estação Radio Base (vide BTS)
European Telecommunications Standards Institute
Final Assembly Code
Fast Associated Control Channel
Frequency correction burst
Frequency Correction Channel
Frequency Division Duplexing
Frequency Division Multiple Access
Frame Number
viii
GEA
GGSN
GMSC
GMSK
GPRS
GSM
GSN
GTP
HLR
HTTP
ICCID
IMEI
IMSI
IP
ISDN
ISM
ITU
Kc
Ki
LA
LAC
LAI
LCH
LMSI
MA
MCC
ME
MITM
MM
MNC
MS
MS-DOS
MSC
MSIN
MSISDN
MSK
NB
NDC
NMSI
NSAPI
NSS
OCXO
OSI
OSS
PBX
GPRS Encryption Algorithm
Gateway GPRS Support Node
Gateway Mobile Switching Center
Gaussian Minimum-Shift Keying
General Packet Radio Service
Global System for Mobile Communications
GPRS Support Nodes
GPRS Tunneling Protocol
Home Location Register
Hyper Text Transfer Protocol
Integrated Circuit Card ID
International Mobile Equipment Identity
International Mobile Subscriber Identity
Internet Protocol
Integrated Services Digital Network
Instrumentation, Scientific and Medical
International Telecommunication Union
Chave de encriptação ou chave de seção (Ciphering Key / Session Key)
Chave de autenticação do assinante (Subscriber Authentication Key)
Location Area
Location Area Code
Location Area Identification
Logical Channel
Local Mobile Station Identity
Mobile Allocation
Mobile Country Code
Mobile Equipment
Man-In-The-Middle
Mobility Management
Mobile Network Code, ou código de operadora
Mobile Station
MicroSoft Disk Operating System
Mobile Switching Center
Mobile Subscriber Identification Number
Mobile Subscriber Integrated Services Digital Network Number
Minimum Shift Keying
Normal Burst
National Destination Code
National Mobile Subscriber Identity
Network Layer Service Access Point Identifier
Network and Switching Subsystem
Oven-Controlled Crystal Oscillator
Open Systems Interconnection
Operations Suport System
Private Branch Exchange
ix
PCH
PDN
PIN
PLMN
ppm
PSTN
P-TMSI
PUK
RACH
RAM
RAND
RF
ROM
RPTC
RR
SACCH
SB
SCH
SDCCH
SDR
SGSN
SIM
SIP
SMS
SMS-G
SN
SNR
SRES
SS7
TAC
TCH
TDMA
TID
TLLI
TMSI
TN
TS
TTL
Um
UMTS
USB
USRP
VCTCXO
VLR
VoIP
Physical Channel
Paket Data Network
Personal Identification Number
Public Land Mobile Network
parts per million
Public Switched Telephone Network
Packet Temporary Mobile Subscriber Identity
Personal Unblocking Key
Random Access Channel
Random Access Memory
Random Challenge
Radiofrequência
Read Only Memory
Rede Publica de Telefonia Comutada (vide PSTN)
Radio Resource
Slow Associated Control Channel
Synchronization burst
Synchronization Channel
Standalone Dedicated Control Channel
Software-Defined Radio
Serving GPRS Support Node
Subscriber Identity Module
Session Initiation Protocol
Short Message Service
Short Message Service Gateway
Subscriber Number
Serial Number
Signed RESponse
Signalling System No.7
Type Approval Code
Traffic Channel
Time Division Multiple Access
Tunnel Identifier
Temporary Logical Link Identity
Temporary Mobile Subscriber Identity
Timeslot Number
Timeslot
Transistor-Transistor Logic
Interface aérea de radiofrequência entre MS e BTS
Universal Mobile Telecommunications System
Universal Serial Bus
Universal Software Radio Peripheral
Voltage Controlled, Temperature Compensated Crystal Oscillators
Visitor Location Register
Voice over Internet Protocol
x
VPN Virtual Private Network
XO
Crystal Oscillator
xi
Sumário
1 Introdução
1
2 GSM/GPRS: Uma visão geral
2.1 INTRODUÇÃO . . . . . . . . . . . . . . . . .
2.1.1 GSM . . . . . . . . . . . . . . . . . . .
2.1.2 GPRS . . . . . . . . . . . . . . . . . .
2.2 ARQUITETURAS DE REDE . . . . . . . . .
2.2.1 Arquitetura GSM . . . . . . . . . . . .
2.2.2 Identificação do assinante móvel . . . .
2.2.3 Mobile Station . . . . . . . . . . . . .
2.2.4 Base Station Subsystem . . . . . . . .
2.2.5 Network and Switching Subsystem . . .
2.2.6 Operations Support System . . . . . . .
2.2.7 Arquitetura GPRS . . . . . . . . . . .
2.3 INTERFACES GSM . . . . . . . . . . . . . .
2.3.1 Considerações iniciais . . . . . . . . . .
2.3.2 Interfaces . . . . . . . . . . . . . . . .
2.4 APROFUNDAMENTO NA INTERFACE Um
2.4.1 Considerações iniciais . . . . . . . . . .
2.4.2 Canais Fı́sicos . . . . . . . . . . . . . .
2.4.3 Canais Lógicos . . . . . . . . . . . . .
2.4.4 GPRS . . . . . . . . . . . . . . . . . .
2.5 MODELO DE SEGURANÇA . . . . . . . . .
2.5.1 Conceitos de Segurança . . . . . . . .
2.5.2 GSM: Funções e Serviços de Segurança
2.5.3 Autenticação . . . . . . . . . . . . . .
2.5.4 Encriptação . . . . . . . . . . . . . . .
2.5.5 Considerações adicionais para o GPRS
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
6
6
6
7
8
10
10
12
12
13
13
14
15
15
16
20
23
24
25
26
27
29
33
3 Arquitetura dos Sistemas GSM/GPRS sob a ótica da atualidade
3.1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 ELEMENTOS DA ARQUITETURA . . . . . . . . . . . . . . . . . . . . .
3.2.1 Equipamentos e periféricos utilizados . . . . . . . . . . . . . . . . .
37
37
38
39
xii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.3
3.4
3.2.2 Software . . . . . . . . . . .
VULNERABILIDADES . . . . . .
3.3.1 IMSI Catcher . . . . . . . .
3.3.2 MITM . . . . . . . . . . . .
CONSIDERAÇÕES FINAIS . . . .
3.4.1 Espectro de Radiofrequência
3.4.2 Clock . . . . . . . . . . . .
3.4.3 Identificadores da Rede . . .
3.4.4 Câmara Anecóica - UFABC
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
49
49
50
54
55
55
55
55
4 Análise Técnica por meio de Recursos de Hardware e Software
57
4.1 FASE DE INTEGRAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2 FASE DE VERIFICAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.1 IMSI Catcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5 Conclusões e Perspectivas Futuras
69
5.1 CONSTATAÇÕES E CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . 70
5.2 RECOMENDAÇÕES PARA TRABALHOS FUTUROS . . . . . . . . . . 71
Bibliografia
73
Apêndices
80
A Tutorial de Instalação e Configuração
A.1 Introdução . . . . . . . . . . . . . . .
A.2 Instalação das dependências . . . . .
A.3 Instalação das bibliotecas boost . . .
A.4 Edição dos paths . . . . . . . . . . .
A.5 Instalação do GNU Radio 3.3.0 . . .
A.6 Adição de permissão de usuário . . .
A.7 Teste de interface com a USRP1 . . .
A.8 Upgrade para GNU 3.6.5.1 . . . . .
.
.
.
.
.
.
.
.
GNU
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
Radio
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
81
81
82
83
83
83
85
86
89
B Tutorial de Instalação e Configuração - USRP Hardware Driver (UHD) 91
B.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
B.2 Library Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
C Tutorial de Utilização - pySim
C.1 Introdução . . . . . . . . . . .
C.2 Download da ferramenta . . .
C.3 Compreendendo o pySim . . .
C.4 Exemplos de Escrita e Leitura
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
xiii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
95
95
95
95
96
xiv
D Tutorial de Instalação e Configuração - OpenBTS
D.1 Introdução . . . . . . . . . . . . . . . . . . . . . . .
D.2 Instalação das Bibliotecas . . . . . . . . . . . . . .
D.3 Construção e Instalação do OpenBTS-UHD . . . .
D.4 Outras versões de OpenBTS . . . . . . . . . . . . .
D.4.1 Versão P2.8 . . . . . . . . . . . . . . . . . .
D.4.2 Variante GPRS baseada no P2.8 . . . . . . .
D.4.3 OpenBTS-OSMO . . . . . . . . . . . . . . .
D.4.4 OpenBTS 2.6 . . . . . . . . . . . . . . . . .
D.4.5 Versões anteriores . . . . . . . . . . . . . . .
E Tutorial de Instalação - Asterisk
E.1 Introdução . . . . . . . . . . . .
E.2 Instalação - Asterisk v1.8.7.1 . .
E.3 Possı́veis Erros . . . . . . . . .
E.4 Configuração . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
99
99
99
100
101
101
104
104
104
105
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
107
. 107
. 107
. 107
. 110
Capı́tulo
1
Introdução
Os sistemas analógicos de telefonia móvel marcaram o inı́cio de uma grande revolução
no campo das telecomunicações. Conhecidos como sistemas de primeira geração (1G),
a telefonia móvel analógica caracterizava-se pela baixa qualidade de voz, pela facilidade
de interceptação das chamadas e pela ausência de um padrão internacional, impedindo
que um único aparelho móvel fosse utilizado em diferentes paı́ses. Sobretudo no continente europeu, onde as fronteiras territoriais sobressaem com maior frequência, notava-se
claramente em meados dos anos 80 problemas derivados da incompatibilidade entre as
diferentes tecnologias 1G. Sob o ponto de vista do usuário, os sistemas eram limitados
tanto em qualidade quanto em segurança, confidencialidade e abrangência dos serviços.
Sob o ponto de vista dos desenvolvedores, a incompatibilidade entre tecnologias restringia
os ganhos de produção em larga escala, encarecendo o produto final e consequentemente
reduzindo os lucros. Não menos importante observar que os telefones celulares analógicos
eram grandes e necessitavam de recargas constantes de bateria.
Neste contexto, criou-se no inı́cio dos anos 80 o GSM (Groupe Spécial Mobile) para
endereçar justamente os problemas e limitações observados na época. Posteriormente
chamado de Global System for Mobile Communications, o GSM tornou-se rapidamente o
padrão de telefonia móvel mais utilizado no mundo. Dentre as caracterı́sticas que potencializaram este rápido crescimento, destacam-se a melhor qualidade de voz, o aumento da
capacidade de tráfego dos sistemas, a vasta gama de serviços (como acesso à Internet e
envio de SMS, Short Message Service), a implementação de algoritmos de autenticação e
encriptação de dados, a maior robustez do canal e finalmente a padronização internacional
que tornou possı́vel utilizar um único número de telefone e/ou um único aparelho celular
em todo o mundo (roaming internacional).
Posteriormente, o aumento na demanda por serviços de dados como SMS e Internet
marcou a transição para os sistemas conhecidos como 2.5G. Caracterizado por uma arquitetura sobreposta à rede GSM (XENAKIS et al., 2008; XENAKIS; L.MERAKOS, 2002), o
GPRS (General Packet Radio Service) é um sistema 2.5G que reutiliza grande parte da
infraestrutura anteriormente implantada nas redes GSM, adicionando os novos nós SGSN
(Serving GPRS Support Node) e GGSN (Gateway GPRS Support Node) responsáveis pelo
1
Capı́tulo 1. Introdução
2
fornecimento de serviços de comutação de pacotes. Desta forma, o GPRS possui taxas de
transmissão que podem variar de 14.4 kbps (utilizando apenas um timeslot) até 115kbps
(múltiplos timeslots) (USHA COMMUNICATIONS TECHNOLOGY, 2000; ALMEIDA, 2010),
sendo que diferentes BTSs (Base Transceiver Station) podem ser utilizadas para o envio
de pacotes (PESONEN, 1999). Os pacotes transmitidos são finalmente reconstruı́dos na
SGSN, garantindo assim uma vantagem frente às transmissões alocadas em um único canal.
Apesar de ter sido superado pelas tecnologias mais modernas da terceira geração (3G),
as vantagens descritas anteriormente não apenas garantiram uma sobrevida ao GSM/GPRS como também proporcionaram a ampliação da gama de possı́veis aplicações fora a
tradicional telefonia celular, consolidando definitivamente sua ampla área de cobertura.
Seja pela infraestrutura já instalada, seja pela qualidade de serviços e relativa robustez
que o sistema demonstrou até então, emprega-se esta solução 2.5G em transações financeiras, rastreamento veicular (CONTRAN, 2007), sensoriamento e monitoramento em redes
inteligentes de energia elétrica (Smart Grids) e até mesmo como conexão alternativa para
aparelhos celulares 3G.
Porém, estudos recentes apontam que esta relativa harmonia pode estar chegando ao
fim. Fragilidades e técnicas de ataque previamente identificados por PESONEN ganharam
fortes aliados após a maior exposição do tema dentro da comunidade cientı́fica, aumentando a severidade dos ataques e criando novas frentes antes não exploradas (PERKOV;
KLISURA; PAVKOVIé, 2011; PAGET, 2010b). O vazamento de algoritmos (MEYER; WETZEL,
2004), a compilação dos resultados de pesquisas correlacionadas ao tema e a realização
de engenharia reversa culminaram na simplificação da infraestrutura necessária para estudar e interagir com a rede. A possibilidade de combinar hardwares menos complexos
com softwares abertos e gratuitos viabilizou o surgimento de alternativas de baixo custo
em relação à arquitetura GSM tradicional, tornando público o que antes estava restrito à
poucas empresas do ramo.
Com relação à privacidade do assinante, tem-se no IMSI (International Mobile Subscriber Identification) um dos grandes alvos de ataque. Correspondendo ao identificador
exclusivo de cada assinante, verifica-se que o sigilo do IMSI possui relação direta com a
privacidade do usuário, e por este motivo, define-se que sua transmissão pela rede deve ser
evitada a todo custo. Para tal, cada assinante recebe também uma identidade temporária
chamada TMSI (Temporary Mobile Subscriber Identity), a qual efetivamente identifica
o usuário na rede. A relação entre TMSI e IMSI é mantida apenas em determinados
elementos de rede, os quais serão abordados ao longo do presente trabalho. A eficácia
desta função parte do pressuposto que o IMSI não deve ser transmitido de forma corriqueira (ETSI, 1996b), porém brechas foram criadas para o caso de MSs que acabam de
ser ligadas, ou casos em que a MS não consegue se conectar ao HLR (Home Location Register ). Por não conseguir reconhecer a identidade do usuário, a rede consequentemente
não consegue estabelecer uma encriptação, dando margem à hipótese de transmissão do
IMSI em cleartext (ERIKSSON, 2005; OLAWSKI, 2011) pela rede.
3
Sob o ponto de vista da transmissão de dados, o GSM utiliza algoritmos-cifra de encriptação pertencentes à famı́lia A5, onde o A5/0 representa a ausência de encriptação
(cleartext), A5/1 constitui a encriptação padrão, A5/2 estabelece uma versão mais fraca do
A5/1 e finalmente o A5/3 implementa uma encriptação semelhante ao algoritmo KASUMI
utilizado no UMTS (Universal Mobile Telecommunications System). Enquanto (EKDAHL;
JOHANSSON, 2003; GOLIC, ; BIHAM; DUNKELMAN, ; S.PETROVIC; FUSTER-SABATER, 2000;
BIRYUKOV; SHAMIR; WAGNER, 2001; GOLDBERG; WAGNER; GREEN, 1999) apresentam
técnicas de criptoanálise para decodificar e decifrar dados com o auxı́lio de recursos computacionais, temos em (PAGET, 2010b; MEYER; WETZEL, 2004) relatos que indicam a
possibilidade de simplesmente desabilitar a encriptação de dados entre a BTS e a estação
móvel (MS, Mobile Station). Justamente por se tratar de uma solução global, o GSM
prevê a transmissão em cleartext como uma condição válida para atender paı́ses nos quais
a encriptação de dados é proibida (PAGET, 2010b). Durante o processo de Security Setup
que ocorre imediatamente após a autenticação, a BTS define qual algoritmo criptográfico
deverá será utilizado. Neste momento, a hipótese de seleção do A5/0 (cleartext) acaba
por dispensar qualquer esforço posterior de criptoanálise.
A terceira hipótese fundamental do trabalho reside no processo de autenticação, no
qual determina-se que a MS precisa ser autenticada para ganhar acesso à rede, porém o
contrário não se verifica (XENAKIS et al., 2008; MEYER; WETZEL, 2004; STROBEL, 2007;
ERIKSSON, 2005; OLAWSKI, 2011). A hipótese da rede GSM não precisar ser autenticada
perante a MS constitui uma das principais vulnerabilidades do modelo de segurança GSM,
sendo este o ponto de partida para a etapa exploratória do presente trabalho.
Em particular, pretende-se com esta dissertação aprofundar nos conceitos de vulnerabilidade dos sistemas GSM/GPRS, utilizando recursos complementares de hardware e
software para comprovar a pertinência e veracidade das fragilidades identificadas. Para
tal, a verificação das hipóteses de autenticação unilateral, transmissão do IMSI em cleartext e seleção do A5/0 constituem os pontos chave do estudo visto a sua grande pertinência
e relativa simplicidade perante os demais métodos que envolvem criptoanálise.
Desta forma, a dissertação segue uma modalidade de pesquisa aplicada e exploratória,
visando investigar, comprovar ou rejeitar hipóteses sugeridas, ao mesmo tempo em que
proporciona maior familiaridade com o problema. A estrutura geral do trabalho toma
a forma de cinco capı́tulos, incluindo este capı́tulo introdutório. O capı́tulo II começa
estabelecendo as dimensões teóricas da pesquisa, apresentando uma visão geral das arquiteturas de rede GSM/GPRS e correlacionando seus principais elementos com o modelo
de segurança adotado nos sistemas. O terceiro capı́tulo aprofunda no estudo das vulnerabilidades e no detalhamento do hardware e software selecionados para a comprovação
prática. O capı́tulo IV apresenta os resultados da etapa experimental de comprovação das
hipóteses e fragilidades identificadas. Finalmente, o Capı́tulo V apresenta as conclusões
e fechamento do trabalho, contextualizando a real segurança dos sistemas GSM/GPRS e
identificando futuras oportunidades de pesquisa sobre o tema.
4
Capı́tulo
2
GSM/GPRS: Uma visão geral
2.1
INTRODUÇÃO
O GSM continua sendo o sistema de telefonia móvel mais utilizado na atualidade.
Complementado pelo GPRS que oferece uma alternativa viável para transmissão de dados,
o sistema conhecido como 2.5G ainda vigora e inclusive expande para novas aplicações, na
medida em que a conectividade e o monitoramento ganham maiores proporções em nosso
cotidiano. No entanto, algumas fragilidades recém exploradas pela comunidade cientı́fica
colocam em dúvida os limites e a robustez dos modelos de segurança dos sistemas. Antes
de abordar este assunto, torna-se necessário conhecer um pouco mais sobre ambos os
sistemas.
2.1.1
GSM
O Global System for Mobile Communications (originalmente Group Speciale Mobile)
é o padrão de telefonia móvel mais utilizado no mundo (PERKOV; KLISURA; PAVKOVIé,
2011; NATALIZIO et al., 2010). Assim como outras tecnologias, o GSM assegura a criação
de uma rede de telefonia móvel celular ao agregar múltiplas células com diferentes áreas
de cobertura. Porém, seus diferenciais em relação às tecnologias da primeira geração se
tornam evidentes ao avaliar, por exemplo, sua melhor qualidade de voz e sua padronização internacional, fatores primordiais que justificaram seu rápido crescimento e aceitação
em todas as regiões do mundo. Possuidor de uma tecnologia estável e geograficamente
consolidada na atualidade, o GSM continua sendo amplamente empregado mesmo diante
de tecnologias mais modernas. De tão significativo, o GSM estabelece uma interessante
alternativa para a ampliação da área de cobertura de tecnologias sucessoras: Se por um
lado isto constitui uma vantagem para o usuário final sob o ponto de vista da abrangência
dos serviços, por outro a compatibilidade se torna um problema ao considerar o fator
segurança da informação.
Tendo suas principais bandas definidas em 850MHz, 900MHz, 1800MHz e 1900MHz,
o padrão foi projetado para ser um sistema de telefonia móvel seguro contendo autenticação de assinante e criptografia para transmissão de dados aéreos. Controlado pelo 3GPP
(3rd Generation Partnership Project) do ETSI (European Telecommunications Standards
5
Capı́tulo 2. GSM/GPRS: Uma visão geral
6
Institute), o GSM possui grande parte de suas especificações publicadas no site do próprio Instituto (ETSI, 2013). Para evitar sua exposição, algumas informações referentes
ao modelo de segurança e seus respectivos algoritmos foram desenvolvidos e mantidos
em segredo (security by obscurity), o que não se mostrou ser suficiente para prevenir o
vazamento de informações e/ou quebras gradativas do segredo por criptoanálise.
2.1.2
GPRS
Com o passar do tempo, o aumento na demanda por serviços de dados como SMS e
Internet marcou a transição para os sistemas conhecidos como 2.5G. Caracterizado por
uma arquitetura sobreposta à rede GSM (XENAKIS et al., 2008; XENAKIS; L.MERAKOS,
2002), o GPRS é um sistema 2.5G que reutiliza grande parte da infraestrutura anteriormente implantada nas redes GSM, adicionando os novos elementos responsáveis pelo
fornecimento de serviços de comutação de pacotes. Desta forma, o GPRS atinge maiores
taxas de transmissão que seu antecessor, ao mesmo tempo em que expande a gama de
serviços ao viabilizar o acesso à Internet, e-mail, transferência de arquivos e aplicativos
em geral (gerenciamento de clima, notı́cias, entre outros).
Mesmo diante de tecnologias modernas 3G (amplamente empregados nos telefones celulares recentes), ainda encontramos algumas frentes de serviço onde os sistemas GSM/GPRS são extremamente atrativos e competitivos, tais como rastreamento veicular e transações financeiras envolvendo compras com cartão de crédito e débito.
2.2
2.2.1
ARQUITETURAS DE REDE
Arquitetura GSM
Uma rede GSM é composta por diferentes elementos com funções e interfaces especı́ficas. Podemos dividi-la basicamente em três partes, conforme Figura 2.1: a MS, o BSS
(Base Station Subsystem) e o NSS (Network and Switching Subsystem).
A MS é formada pela união do ME (Mobile Equipment) com um módulo de identificação do assinante (cartão SIM, Subscriber Identity Module), sendo que cada cartão possui
um número permanente de identificação do usuário no mundo, chamado IMSI. As MSs se
comunicam com o BSS através da interface de RF (radiofrequência) conhecida como Um.
O BSS é formado por BTSs e um BSC (Base Station Controller ). As BTSs realizam
a interface propriamente dita com a MS, enquanto o BSC agrupa diferentes BTSs para
formar um BSS e a espinha dorsal da rede.
O NSS (PAGET, 2010b; KAHABKA, 2004) constitui o núcleo da arquitetura, sendo formado por diversos subcomponentes dentre os quais se destacam o AuC (Authentication
Center ), o HLR e o MSC (Mobile Switching Center ). No NSS, adota-se o SS7 (Signalling
System No.7 ) como protocolo de sinalização, o mesmo adotado na grande maioria das
7
PSTN (Public Switched Telephone Network ) para estabelecimento de chamadas telefônicas.
AuC – Authentication C
Center
BSC – Base Station Controller
BSS – Base Station Subsystem
BTS – Base Transceiver Station
EIR – Equipment Identity Register
HLR – Home Location Register
ISDN – Integrated Services Digital Network
ME – Mobile Equipment
MS – Mobile Station
MSC – Mobile Switching Center
NSS – Network and Switching Subsystem
OSS – Operations Support System
PLMN – Public Land Mobile Network
PSDN – Public Switched Data Network
PSTN – Public Switched Telephone Network
SIM – Subscriber Identity Module
VLR – Visitor Location Register
Figura 2.1: Arquitetura simplificada GSM
As seções seguintes irão abordar maiores detalhes sobre cada um dos elementos que
integram a arquitetura de rede.
2.2.2
Identificação do assinante móvel
International Mobile Subscriber Identification
Cada assinante na rede GSM é identificado por seu IMSI. Trata-se de um número
exclusivo de 15 dı́gitos armazenado no SIM card, sem o qual nenhuma MS consegue
acessar os serviços GSM. O IMSI é composto por três partes distintas (ETSI, 1996a):
• MCC (Mobile Country Code), correspondente a identificação do paı́s de origem do
usuário (3 dı́gitos);
• MNC (Mobile Network Code), que identifica a PLMN (Public Land Mobile Network )
de origem do assinante (2 dı́gitos);
• MSIN (Mobile Subscriber Identification Number ), o qual identifica o usuário móvel
dentro de determinada PLMN (até 10 dı́gitos).
Tipicamente, atribui-se o nome de NMSI (National Mobile Subscriber Identity) ao conjunto formado pelos identificadores MNC e MSIN.
Como exemplo, o IMSI 72405 0123456789 pode ser decomposto em:
• MCC = 724 (Brasil);
• MNC = 05 (Claro
#### BR);
8
Nota: #### para privacidade da
operadora local.
• MSIN = 0123456789.
Embora seja um tema a ser discutido nos próximos capı́tulos, vale observar que a privacidade do assinante está fortemente atrelada ao sigilo do IMSI. Como uma tentativa de
proteger o IMSI, o padrão GSM criou uma identidade temporária chamada TMSI.
Em alguns paı́ses como os Estados Unidos, o IMSI guarda uma estreita relação com o ICCID (Integrated Circuit Card ID), sendo este último o número de série impresso no SIM
card. Neste caso, pode-se facilmente obter o IMSI a partir do ICCID (PAGET, 2010b).
Temporary Mobile Subscriber Identity
Visando garantir a confidencialidade do assinante, o VLR (Visitor Location Register,
banco de dados do MSC cujos detalhes serão abordados posteriormente) atribui um número temporário exclusivo para cada assinante móvel dentro da área controlada por seu
MSC. Além de atualizá-lo sempre que necessário, o VLR detém a importante tarefa de
correlacionar o IMSI do assinante com o respectivo TMSI.
O TMSI constitui desta forma o identificador temporário do assinante utilizado em todos
os segmentos da rede GSM, minimizando desta forma as chances do usuário ser identificado ou rastreado. Com o advento do TMSI, verifica-se que o IMSI é transmitido na rede
apenas em algumas condições especificas, como por exemplo, quando o telefone é ligado
pela primeira vez. Vale antecipar que os próximos capı́tulos abordarão formas de se obter
o IMSI dos assinantes utilizando recursos conhecidos como IMSI Catchers.
Constituı́do por quatro octetos (32 bits), o TMSI é um número válido apenas dentro de
determinada Location Area (LA) (ERIKSSON, 2005), que por sua vez pode ser interpretado
como um conjunto de células geograficamente reunidas. Por este motivo, o TMSI está
sempre associado à determinada LAI (Location Area Identification), e requer atualização
sempre que o assinante móvel se desloca para uma nova região (novo MSC).
Visando garantir que os dados não serão perdidos ao se desligar o aparelho, a MS armazena
o TMSI e o LAI na memória não volátil do SIM card.
2.2.3
Mobile Station
A MS representa o conjunto formado pelo ME (tipicamente um aparelho telefônico
celular) e o SIM card, o qual pode ser removido e inserido em aparelhos diversos.
ME e IMEI
O ME constitui o dispositivo móvel utilizado para acessar a rede GSM, tipicamente
(mas não necessariamente) um aparelho telefônico celular. Cada ME é identificado por um
único IMEI (International Mobile Equipment Identity), número este que permite bloquear
o acesso à rede em caso de aparelhos roubados (basta digitar *♯06♯ para obter o IMEI de
um ME). O IMEI é composto por 15 dı́gitos decimais, subdivididos em (ETSI, 1996a):
9
• TAC (Type Approval Code), um código de 6 dı́gitos;
• FAC (Final Assembly Code), com 2 dı́gitos, identificando o local de manufatura;
• SNR (Serial Number ), com 6 dı́gitos, representando cada equipamento produzido
em um TAC e FAC;
• Dı́gito de verificação, sendo este o dı́gito final.
Como exemplo, o IMEI 35077055 8889287 pode ser decomposto em:
• TAC = 350770;
• FAC = 55;
• SNR = 888928;
• Dı́gito de verificação = 7.
SIM Card
O termo SIM card refere-se ao cartão inteligente utilizado nos sistemas GSM para
armazenamento de informações importantes na MS. Por se tratar de um cartão removı́vel,
o SIM card desvincula definitivamente o usuário do aparelho.
O SIM é composto por um único chip contendo sistema operacional, arquivos de sistema
e aplicativos. Uma configuração tı́pica segundo STEPANOV inclui uma CPU (Central
Processing Unit) de 8 bits, 16K de memória ROM (Read Only Memory), 256 bytes de
RAM (Random Access Memory) e 4K de EEPROM (Electrically Erasable Programmable
Read-Only Memory). Suas demais caracterı́sticas (tamanho, contatos elétricos, protocolos
de I/O, etc) são padronizadas segundo ISO/IEC.
O SIM é responsável por armazenar:
• o IMSI;
• o TMSI;
• o PIN (Personal Identification Number );
• o LAI;
• o MSISDN (Mobile Subscriber Integrated Services Digital Network Number ), que
nada mais é do que o numero de telefone propriamente dito, sendo este conhecido
pelos usuários e formado pela união do CC (Country Code), NDC (National Destination Code) e o SN (Subscriber Number );
• os algoritmos A3 e A8 (que serão estudados ao longo dos próximos capı́tulos);
• a chave de autenticação do usuário, Ki, com 128 bits.
10
Cada assinante contém uma chave de autenticação Ki armazenada em seu SIM card, sendo
esta informação compartilhada única e exclusivamente com o AuC (Authentication Center ) de sua rede de origem. Esta chave é utilizada para autenticar o usuário na rede,
sendo esta a base para o modelo de segurança do GSM.
O acesso ao SIM card é controlado por um código de 4 dı́gitos denominado PIN, sendo
que em caso de perda ou esquecimento, o usuário ainda conta com o recurso do PUK
(Personal Unblocking Key) para reset do PIN. Tipicamente, inutiliza-se o SIM card caso
o PUK seja digitado incorretamente por 10 vezes consecutivas durante tentativas de desbloqueio (CLAROCHIP, 2012).
2.2.4
Base Station Subsystem
O BSS é responsável por integrar as MSs ao NSS. Basicamente, o BSS é composto
por:
• BTS, também conhecida no Brasil como ERB (Estação Rádio Base);
• BSC.
Base Transceiver Station
A BTS constitui o conjunto rádio transmissor que realiza a conexão entre a MS e
o MSC, transmitindo e recebendo dados de forma a suportar a demanda por chamadas
em determinada região. A área de cobertura total de uma rede GSM é composta por
diversas células, cujas áreas de cobertura variam conforme a densidade populacional e
(consequentemente) a quantidade de chamadas simultâneas a ser suportada. Cada célula
contém ao menos uma BTS, sendo comum encontrar múltiplas BTSs em setores de uma
mesma célula.
Além de viabilizar a conectividade, as BTSs também participam do processo de codificação
e decodificação do canal. Diversas BTSs podem ser gerenciadas por um único BSC.
Base Station Controller
O BSC gerencia os recursos de diversas BTSs através da interface Abis, tais como
o frequency hopping, controle de potência, sincronismo de clocks e handover (ALMEIDA,
2010). Além disso, o BSC também proporciona interconexão com o OSS (Operations
Support System).
Apesar de abordar estas funções em capı́tulos posteriores, vale ressaltar especificamente
que o handover ocorre sempre que uma MS se desloca de uma célula para outra, porém
nos casos em que o deslocamento se dá entre BTSs não subordinadas a um mesmo BSC,
a responsabilidade pelo processo acaba sendo escalada para o MSC (STROBEL, 2007).
2.2.5
Network and Switching Subsystem
Mobile Switching Center
Constituindo o elemento central de um NSS, o MSC atua como comutador da rede
fixa ao mesmo tempo em que fornece as funcionalidades necessárias para lidar com um
11
assinante móvel (registro, autenticação, atualização de localização, cobranças, handovers
e roteamento de chamada para usuários em roaming). Caso o MSC também contenha a
função gateway para comunicar com outras redes, costuma-se classificá-lo como GMSC
(Gateway MSC ).
Cada MSC é responsável por gerenciar um grupo de células geograficamente relacionadas,
denominadas Location Area. Por sua vez, cada LA possui seu respectivo Location Area
Identity, número este formado pela união de (ETSI, 1996a):
• MCC (Mobile Country Code);
• MNC (Mobile Network Code);
• LAC (Location Area Code), um código de 16 bits que identifica as LAs dentro de
uma PLMN GSM.
Dá-se o nome de home network às redes originalmente atribuı́das aos assinantes móveis.
Porém, conforme dito anteriormente, tais assinantes GSM são livres para trafegar por
diferentes regiões, incluindo cidades, estados e até mesmo paı́ses. Sempre que os limites
de sua home network são extrapolados, os assinantes precisam se conectar a outras redes
denominadas visited networks pelo padrão GSM.
Além disso, sabe-se que o TMSI está sempre associado à determinada LAI, necessitando
de atualização sempre que o assinante móvel se deslocar para uma nova região (novo
MSC).
Para lidar com estas condições, cada MSC conta com o auxı́lio de 4 bases de dados
importantes, as quais serão apresentadas a seguir:
• HLR;
• VLR;
• AuC;
• EIR (Equipment Identity Register ).
Home Location Register
Como o próprio nome sugere, o HLR é a base de dados utilizada para guardar as
informações de seus respectivos assinantes móveis, tais como o IMSI, o MSISDN e o
último LA visitado pelo assinante. A cópia dos dados para o HLR é feita no momento em
que a operadora GSM associa um SIM card à determinado assinante e, a partir de então,
seus dados são mantidos em segurança.
Visitor Location Register
Sempre associado a um MSC, o VLR é o banco de dados que mantém o registro de
todos os usuários (seja proveniente de redes externas, seja de sua própria rede) que por
ventura adentrarem a LA de seu MSC. Estes registros são temporários e devem durar
apenas enquanto o usuário estiver dentro da LA. Neste perı́odo, o VLR irá armazenar os
12
números de identificação do assinante, seus respectivos serviços autorizados e os dados de
segurança necessários para autenticar o usuário e criptografar a interface aérea (PERKOV;
KLISURA; PAVKOVIé, 2011).
A busca por determinado assinante pode ser acelerada pelo VLR ao criar uma correlação
entre o TMSI e o IMSI do usuário. Neste contexto, um número de 32 bits denominado
LMSI (Local Mobile Station Identity) pode ser criado pelo VLR (ETSI, 1996a).
Equipment Identity Register
O EIR é a base de dados que detém uma lista de todos os equipamentos válidos dentro
de uma rede, lembrando que cada estação móvel é identificada por seu respectivo IMEI.
O EIR por sua vez é composto por 3 bases de dados:
• Lista Branca: contendo os IMEIs sem restrições;
• Lista Cinza: para aparelhos/IMEIs sob suspeita;
• Lista Negra: para aparelhos roubados ou não conformes.
Authentication Center
O AuC é uma base de dados protegida que grava uma cópia da chave secreta Ki
armazenada em cada SIM card dos assinantes, a qual é utilizada para autenticação do
usuário e encriptação do canal de rádio. O AuC provê segurança adicional contra fraudes
ao gerar os vetores de autenticação previstos no modelo de segurança GSM. Normalmente,
o AuC está integrado ao HLR nas redes GSM.
2.2.6
Operations Support System
O OSS é um sistema de gerenciamento que supervisiona os blocos funcionais da rede
GSM. Ele auxilia os operadores de rede na manutenção do sistema, implementando redundâncias de hardware e mecanismos inteligentes de detecção de erros que ajudam a
prevenir o downtime da rede (KAHABKA, 2004). O OSS é responsável por controlar e
manter o MSC, BSC e BTS. Ele pode ser responsável por uma PLMN inteira ou apenas
partes de uma PLMN.
2.2.7
Arquitetura GPRS
A arquitetura GPRS consiste de uma rede sobreposta à rede GSM, reutilizando a
maioria de seus elementos porém adicionando alguns novos nós responsáveis pelo fornecimento de serviços de comutação de pacotes (XENAKIS et al., 2008; XENAKIS; L.MERAKOS,
2002).
Os nós de apoio GPRS, ou simplesmente GSNs (do inglês GPRS Support Nodes), são
responsáveis pelo roteamento e entrega de pacotes de dados das MSs para a rede PDN
(Paket Data Network ), e vice-versa.
13
A SGSN (Serving GSN ) encaminha os pacotes de/para determinada MS dentro de sua
área de cobertura, enquanto a GGSN (Gateway GSN ) faz a interface entre a rede GPRS
principal (backbone) e as redes PDNs externas como a Internet (pública) ou redes privadas
(VPNs). A comunicação entre GSNs é feita através do protocolo de encapsulamento GTP
(GPRS Tunneling Protocol ).
A arquitetura de rede GPRS segue ilustrada na Figura 2.2:
GPRS
backbone
Internet
Pública
Figura 2.2: Arquitetura simplificada GPRS
Na prática, o GPRS atinge maiores taxas de transmissão ao permitir que uma MS
envie pacotes utilizando múltiplos timeslots que por fim serão reconstruı́dos na SGSN, o
que constitui uma vantagem frente às transmissões alocadas em um único canal.
2.3
2.3.1
INTERFACES GSM
Considerações iniciais
Em uma rede GSM, diferentes protocolos são necessários para habilitar o fluxo de
dados e sinalização entre os subsistemas e seus componentes (partindo da interface Um
entre MS e BTS, passando pela interface Abis entre BTS e BSC, seguido pela interface A
entre BSC e MSC, e assim por diante, conforme ilustrado na Figura 2.3).
14
Figura 2.3: Interfaces entre os elementos de rede
2.3.2
Interfaces
- Interface Um: Interface de RF que utiliza uma combinação de FDMA (Frequency
Division Multiple Access) e TDMA(Time Division Multiple Access), conforme detalhes
abordados mais adiante. Para fins introdutórios, considera-se que o FDMA permite dividir
a banda de frequência em diversas portadoras, separadas em 200KHz uma da outra. Por
sua vez, o TDMA permite segmentar cada uma das portadoras em 8 canais separados no
tempo, multiplicando desta forma o número de canais disponı́veis.
- Interface Abis: Responsável por realizar operações entre BTS e BSC, tais como a
transmissão de canais de tráfego e o gerenciamento dos canais de rádio.
- Interface A: Interface de comunicação entre MSC e BSC.
- Interface B: Interface entre MSC e VLR, sendo utilizada sempre que o MSC precisa acessar os dados sobre uma MS localizada em sua área de cobertura. Emprega um
protocolo conhecido como MAP/B. Como a maioria dos VLRs está inserida no próprio
hardware do MSC, isto faz com que a interface seja meramente uma interface interna.
- Interface C: Interface entre HLR e GMSC ou um SMS-G (chamadas feitas de uma
rede externa).
- Interface D: Interface entre VLR e HLR, executa a troca de dados relacionados à
localização do ME e o gerenciamento do assinante.
- Interface E: Interface entre duas MSCs.
- Interface F: Interface entre MSC e EIR.
- Interface G: Interconexão entre duas VLRs de diferentes MSCs.
- Interface H: Interconexão entre MSC e SMS-G.
2.4
2.4.1
15
APROFUNDAMENTO NA INTERFACE Um
Considerações iniciais
Conforme o padrão GSM, a interface Um refere-se à interface de RF utilizada para
unir os subsistemas MS e BSS. Conforme observa-se na Figura 2.4, a interface Um engloba as três camadas inferiores referenciadas no modelo OSI (Open Systems Interconnection) (BURGESS; SAMRA, 2008):
• Camada Fı́sica, responsável pela transmissão propriamente dita da informação;
• Camada de Enlace (Data Link Layer ), cuja função é segmentar as mensagens de
camadas superiores em frames ordenados para transmissão. A camada de enlace
GSM é chamada de LAPDm (Link Access Protocol on the D-Channel );
• Camada de Rede (L3), que permite o gerenciamento das conexões da Interface Um,
a identificação do assinante e o gerenciamento de serviços adicionais como SMS
e encaminhamento de chamadas. Existem três subdivisões da camada L3, sendo
elas o RR (Radio Resource, responsável pelo gerenciamento dos canais de rádio),
MM (Mobility Management, com foco na autenticação de usuário e roteamento de
chamadas para áreas geográficas especı́ficas) e o CC (Call Control, gerenciamento
de conexão para telefonia de voz).
Figura 2.4: Modelo de camadas da interface Um
Como uma visão geral introdutória das principais caracterı́sticas da Interface Um,
pode-se dizer que a transmissão do sinal emprega o formato de modulação digital 0,3GMSK
(Gaussian Minimum-Shift Keying). Cada canal de rádio possui uma largura de banda de
270,833KHz, sendo suas portadoras espaçadas de 200KHz. Para evitar a sobreposição de
frequências (overlap), o padrão GSM não permite que canais adjacentes sejam utilizados
em uma mesma célula (BURGESS; SAMRA, 2008). Como o espectro de frequência constitui
um recurso limitado, a interface Um emprega uma combinação de FDMA e TDMA para
compartilhar a banda disponı́vel com o máximo número de usuários, sendo esta a base
16
da estrutura dos canais fı́sicos previstos no modelo. Empregando a técnica de FDD (Frequency Division Duplexing), cada canal possui um par de frequências (uma para uplink
e a outra para downlink ) identificados por seu respectivo ARFCN (Absolute Radio Frequency Channel Number ). Por sua vez, cada canal fı́sico acaba sendo multiplexado em
canais lógicos (traffic channels e control channels), permitindo desta forma separar as informações do usuário das informações de gerenciamento. A Figura 2.5 elucida a diferente
natureza dos canais:
Figura 2.5: Canais fı́sicos versus canais lógicos
2.4.2
Canais Fı́sicos
Conforme visto anteriormente, os canais GSM são divididos em canais fı́sicos (PCH,
do inglês Physical Channel ) e canais lógicos (LCH, do inglês Logical Channel ). Os canais
fı́sicos resultam da combinação da frequência dos canais de rádio ARFCN com os TS
(timeslots) gerados pela subdivisão TDMA, possibilitando a criação de 8 canais fı́sicos
por portadora com duração de 576,9 µs cada. Maiores detalhes serão abordados ao longo
dos próximos tópicos.
Modulação 0,3GMSK
A modulação adotada pelo padrão GSM foi a GMSK, um tipo de modulação por chaveamento de frequência onde os bits são representados por deslocamento na frequência
de portadora em aproximadamente 67,708 kHz. Constituindo um tipo especial de MSK
(Minimum Shift Keying), o GMSK reduz a interferência entre canais adjacentes ao ter
seus sinais binários formatados por um filtro Gaussiano antes de sofrer a modulação MSK
propriamente dita. Desta forma, garante-se que 95% da energia do sinal modulado estará
contida dentro da banda de 200kHz (CASELLA, 2012).
Ao respeitar a correlação de 1 bit por sı́mbolo, o GMSK proporciona uma taxa de sı́mbolos total de 270,833ksı́mbolos/s. A taxa de sı́mbolos GSM será visitada novamente ao
longo do próximo capı́tulo, junto ao tema clock de rede.
Frequency Division Duplexing
FDD é a técnica na qual uma banda de frequência é utilizada para transmitir e outra
para receber informações. Conforme mostra a Figura 2.6, um bloco de espectro eletromagnético é alocado para o uplink carregando dados das MSs para as BTSs, enquanto
outro bloco do espectro é alocado para downlink carregando dados das BTSs para as MSs.
17
Figura 2.6: Alocação do espectro segundo FDD
Frequency Division Multiple Access
O FDMA é uma técnica que nos permite dividir a banda alocada (recurso limitado)
em múltiplos canais fı́sicos de RF, previamente denominados ARFCNs, cada um com uma
largura de 200 kHz conforme adotado no padrão GSM.
Cada célula GSM recebe um determinado subconjunto de canais de RF, sendo este processo conhecido como CA (Cell Allocation). Obrigatoriamente, um dos canais alocados
à célula será utilizado para carregar informações de sincronização e BCCH (Broadcast
Control Channel ) (ETSI, 1996f), os quais serão apresentados mais adiante.
Dentro de cada célula realiza-se ainda o MA (Mobile Allocation), sendo este a alocação
de alguns canais da célula à determinada MS.
- Radio frequency channel sequence: Corresponde ao mapeamento do FN (Frame
Number ) TDMA com o canal de RF alocado à determinada MS dentro da célula. Por
este motivo, a relação entre FN e ARFCN é única dentro de cada célula (ETSI, 1996f).
Por sua vez, cada MS possui um algoritmo que viabiliza a transmissão no correto timeslot
do canal.
- Frequency Hopping : A técnica de salto de frequências constitui uma alternativa
para aumentar a eficiência da codificação e do entrelaçamento dos dados (interleaving).
Com ela, verifica-se que os timeslots utilizados por uma MS durante processo de recepção
ou transmissão estarão vinculados a uma sequência especı́fica de frequências, e não mais a
uma frequência fixa. Desta forma, uma vez encerrada a transmissão em um TS (duração
de 576,9 µs), a MS precisa primeiramente executar o salto de frequência antes de utilizar
o próximo frame TDMA (ETSI, 1996d).
Questionavelmente, pode-se considerar o frequency hopping como sendo uma camada adicional no modelo de segurança GSM. Vale ressaltar, porém, que sua eficácia no campo
da segurança restringe-se apenas a poucos passos adicionais, como o monitoramento dos
parâmetros transmitidos no momento do MA e a execução adequada do salto de frequências.
- Aparelhos Multibanda: As diferentes bandas de frequências criadas pelo ITU (International Telecommunication Union) para operação de sistemas GSM foram adotadas
18
por cada região, segundo suas necessidades especı́ficas. Costuma-se nomear o sistema
segundo sua banda de frequência, como, por exemplo, o GSM-900 que opera na faixa
próxima aos 900MHz conforme indicado na Tabela 2.1. Dentre as diferentes soluções existentes, os sistemas GSM-900 e GSM-1800 constituem os de maior disseminação em escala
global.
Para que os usuários do sistema possam tirar vantagem do roaming oferecido pelo GSM, os
aparelhos precisam estar aptos para trabalhar nas diferentes bandas disponı́veis em cada
paı́s. Por este motivo, não é difı́cil encontrar aparelhos celulares que suportam múltiplas
bandas de frequência, como por exemplo os aparelhos dual-band (GSM900 e 1800), tripleband ou quadri-band (suportando na maioria das vezes GSM-850, GSM-900, GSM-1800 e
GSM-1900, como no caso do mercado Brasileiro).
Tabela 2.1: Faixas de Frequência GSM
TDMA, Time Division Multiple Access
Conforme observamos na Figura 2.7, o TDMA é uma técnica que nos permite dividir
cada canal de RF em 8 intervalos de tempo (timeslots), sendo que cada um dos 8 intervalos
será associado a um usuário do sistema.
19
TTempo
Tem
mpo
o
Figura 2.7: Acesso múltiplo por divisão de tempo e frequência
- TS e Frame TDMA: Conforme introduzido anteriormente, o TS constitui o recurso
básico para transmissão no canal de RF. Com duração de 576,9 µs, verifica-se que cada
TS comporta 156,25 bits em sua duração (multiplicando-se os 576,9 µs por 270,833 kbps).
O conteúdo fı́sico de um TS é chamado de burst, termo em inglês referente a rajada. ETSI
define um burst como sendo um perı́odo de portadora RF modulado por uma sequência
de dados. Diferentes tipos de bursts podem trafegar em um TS (ETSI, 1996d), conforme
ilustra a Figura 2.8:
• NB (Normal burst): contendo 116 bits criptografados, o NB transporta informações
sobre canais de tráfego e controle, exceto pelo RACH (Random Access Channel )
que será estudado mais adiante;
• FB (Frequency correction burst): rajadas visando a correção de frequência na MS.
Costuma-se classificar a repetição de FBs como sendo o FCCH (Frequency Correction Channel ) do padrão GSM;
• SB (Synchronization burst): transmitido junto com o FB, tem a função de sincronização da MS. Costuma-se classificar a repetição de SBs como sendo o SCH
(Synchronization Channel ) do padrão GSM;
• AB (Access burst): rajadas de acesso aleatório empregadas no RACH por MSs
efetuando seu primeiro acesso, MSs em handover ou MSs em disputa pelo uplink ;
• DB (Dummy burst): rajadas falsas.
Oito timeslots formam um frame TDMA, com duração aproximada de 4,62ms.
- Timeslot Number : Dentro de cada frame TDMA, os TS são identificados pelos
respectivos TN (Timeslot Number ), uma numeração crescente que varia de 0 a 7. Na prática, o TN é utilizado para assegurar que um determinado canal fı́sico sempre irá utilizar
o mesmo TN nos diferentes frames TDMA (ETSI, 1996e) empregados na comunicação.
- Bit Number : Conforme mencionado anteriormente, cada TS comporta até 156,25
bits em seu perı́odo. Por este motivo, cada bit também recebe um identificador chamado
BN (Bit Number ), sendo este uma numeração que varia de 0 a 156.
20
- TDMA Frame Number : Cada frame TDMA recebe uma numeração crescente e
cı́clica, partindo do 0 e excursionando até 2715647, tendo seu incremento computado ao
término de cada frame (ETSI, 1996e). Este identificador é conhecido como FN (Frame
Number ).
- Multiframes: Atribui-se o nome de multiframe ao conjunto formado por 26 frames
TDMA. Desta forma, cada multiframe possui duração aproximada de 120ms.
- Superframes: Atribui-se o nome de superframe ao conjunto formado por 51 frames
TDMA. Desta forma, cada superframe possui duração aproximada de 235,4ms.
- Hyperframes: Hyperframe foi o nome criado para representar o ciclo completo de
frames TDMA, ou seja, de 0 a 2715647, conforme visto anteriormente.
TB
3
Sequência
Se
Sequ
quên
ênci
ciaa De
Treinamento
Trei
Tr
eina
name
na
ment
me
nto
nt
o
26
Bits
Bi
ts En
Encriptados
Encr
crip
cr
ipta
ipta
tado
doss
do
58
TB
3
TB
3
TB
8
Bits En
Bits
Encriptados
Encr
crip
cr
ipta
tado
ta
doss
do
58
Bits
Bi
ts Fix
FFixos
ixos
os
142
14
2
Bits En
Bits
Encriptados
Encr
crip
cr
ipta
tado
ta
doss
do
39
TB GP
3 8,
8,25
25
TB GP
3 8,
8,25
25
bits encriptados
bi
encri
enc
nc
ript
ri
ptad
pt
ados
ad
os
Bits
Bi
ts
Encriptados
Encr
En
crip
cr
ipta
ip
tado
ta
doss
do
58 39
Sequência
Sequ
Se
quên
ênci
ciaa De Sincronismo
SSin
incr
in
cron
onis
ismo
mo
64
Sequência
Sequ
Se
quên
ênci
ciaa De Sincronismo
SSin
incr
in
cron
onis
ismo
mo
41
Bits En
Bits
Encriptados
Encr
crip
cr
ipta
tado
ta
doss
do
36
AB – Ac
Access
Acce
cess
ss Burst
Bur
B
urst
st
GP – Gu
Guard
Guar
ard
d pe
period
peri
riod
od
SB – Sy
Synchronization
Sync
nchr
hron
oniz
izat
atio
ion
n Bu
Burs
Burst
rstt
rs
FB – Fr
Frequency
Freq
eque
uenc
ncyy Co
Corr
Correction
rrec
ecti
tion
on Burst
Bur
B
urst
st
NB – No
Normal
Norm
rmal
al Bu
Burst
Burs
rstt
rs
TB – Ta
Tailil bi
bits
ts
TB
3
TB GP
3 8,
8,25
25
GP
68,25
68
68,2
,25
,2
5
Figura 2.8: Tipos de burst e suas caracterı́sticas
2.4.3
Canais Lógicos
Embora a seção anterior tenha tratado em sua grande maioria dos PCHs, alguns momentos apropriados foram utilizados para antecipação de termos de natureza lógica, tais
como o RACH, FCCH e SCH. Esses canais exemplificam a existência de LCHs (Logical
Channels) nas redes GSM, sendo os mesmos nada mais do que a multiplexação no tempo
21
dos canais fı́sicos comandada pelo clock da BTS (BURGESS; SAMRA, 2008).
Enquanto os PCHs são descritos no domı́nio da frequência e do tempo, os LCHs são
mapeados nos canais fı́sicos tendo funções diferentes em cada instante de tempo. Em
outras palavras, o canal lógico mostra a função que um canal fı́sico está assumindo em
um determinado momento.
Diferentes tipos de canais lógicos podem existir no subsistema de rádio. De toda
forma, os LCHs podem ser divididos em duas categorias principais:
• TCH (Traffic Channels), sendo estes os canais utilizados para transmissão de dados
e voz;
• CCH (Control Channels), utilizados como canais de sinalização e sincronização de
dados.
Traffic Channels
A transmissão de dados e voz do usuário ocorre nos TCHs, segundo um dos formatos
abaixo (ETSI, 1996e):
• TCH/H (Half Rate Traffic Channel ), com taxas de transmissão na ordem de 11,4
Kbits/s para voz e de 2,4 a 4,8 Kbits/s para dados do usuário;
• TCH/F (Full Rate Traffic Channel ), com taxas de transmissão na ordem de 22,8
Kbits/s para voz e de 2,4 a 9,6 Kbits/s para dados do usuário.
Control channels
Os CCHs são utilizados como meio de garantir a sinalização e o sincronismo de dados
na rede GSM. Os canais de controle podem ser agrupados em três categorias:
• Canais de difusão, ou Broadcast channels, dentre os quais se destacam:
– FCCH (Frequency Correction Channel ), responsável pela difusão de informações que possibilitam a correção de frequência da MS;
– SCH (Synchronization Channel ), responsável por difundir informações que possibilitam a sincronização da MS e a identificação da BTS (através do parâmetro
BSIC, do inglês Base Transceiver Station Identity Code);
– BCCH (Broadcast Control Channel ), que transmitem informações gerais que
variam conforme as BTSs envolvidas.
• Canais de Controle Comum, ou CCCH (Common Control Channels), sendo os principais:
– PCH (Paging Channel ), um canal apenas de downlink utilizado para chamar
as MSs;
22
– RACH (Random Access Channel ), canal apenas de uplink utilizado para solicitar a alocação de um SDCCH (Stand-alone Dedicated Control Channel );
– AGCH (Access Grant Channel ), um canal apenas de downlink utilizado alocar
um SDCCH ou diretamente um TCH;
– NCH (Notification Channel ), um canal apenas de downlink utilizado para
notificar as MS sobre chamadas de voz.
• Canais dedicados, ou DCCH (Dedicated control channel ), tal como o SDCCH que
constitui um canal bidirecional ponto-a-ponto usado para serviços de SMS, registro
e controle de sinalização quando uma chamada ainda não foi estabelecida.
A Figura 2.9 apresenta um resumo dos conceitos abordados acima.
Correção de
Frequência
Sincronização
Broadcast
Paging
Acesso Aleatório
Acesso Permitido
Dedicado “Stand alone”
“Slow Associated”
“Fast Associated”
Figura 2.9: Classificação geral dos canais lógicos
Sequência Tı́pica de Acesso
Visando encerrar este apanhado geral sobre os LCHs, segue abaixo o descritivo de uma
sequência tı́pica de acesso partindo do momento em que uma suposta MS é ligada (BURGESS; SAMRA, 2008; ALMEIDA, 2010):
1. Como primeiro passo, a MS inicia a avaliação dos ARFCNs disponı́veis em busca
do canal com sinal mais forte;
2. Ao selecionar o ARFCN, a MS procura obter a sincronização com a BTS através
da decodificação do SCH em questão. Caso não encontre o SCH neste canal, a MS
seleciona outro ARFCN com potência imediatamente inferior ao anterior;
23
3. Através da decodificação do SCH, a MS consegue ajustar seu clock interno com o
clock da BTS;
4. De forma semelhante, as correções de frequência são realizadas pela MS através da
verificação do canal lógico FCCH;
5. Com os devidos ajustes estabelecidos, a MS consegue iniciar a verificação do BCCH,
de onde obtém informações sobre os serviços disponibilizados na rede e as configurações do CCCH;
6. Nesta etapa, a MS é capaz de decodificar o CCCH e solicitar o acesso à rede utilizando o RACH;
7. A MS envia o primeiro RACH para a BTS, contendo um número aleatório como
identificador. Enquanto a confirmação não chega através do CCCH, a MS pode
encaminhar até 8 bursts de RACH respeitando um espaçamento da ordem de 1 a 2
segundos entre cada transmissão;
8. Ao receber o RACH da MS, a BTS utiliza o CCCH para encaminhar uma mensagem
de associação de canal, no caso um SDCCH;
9. A MS muda para o SDCCH atribuı́do pela BTS e encaminha uma solicitação de
atualização de localidade (Location Update Request). Neste momento, a MS compartilha informações com a BTS com o intuito de identificar-se;
10. De posse destas informações, o sistema GSM tem condições de verificar se a MS
pode ou não ser aceita;
11. Considerando que a operação pode prosseguir, a BTS responde com um Location
Update Accept, encerrando logo em seguida o canal SDCCH utilizado até então;
12. Cumprindo com o procedimento de associação à BTS, seja em sua rede preferencial
ou em roaming, a MS passa a partir de então a monitorar o canal PCH na espera
do recebimento de chamadas ou SMS;
13. Caso a MS deseje iniciar uma chamada ou transmitir um SMS, torna-se necessário
iniciar um novo RACH junto à BTS. Mediante ao recebimento de uma permissão
de acesso através do AGCH, a MS poderá enfim utilizar um TCH para transmissão
de dados de voz, por exemplo.
2.4.4
GPRS
Como visão complementar do que foi discutido até então, torna-se apropriado mencionar que o GPRS pode atingir taxas de transmissão de até 115 kbps contando com a
alocação de todos os 8 TS de forma exclusiva. Na prática, porém, a banda precisa ser
compartilhada entre o tráfego de voz e a transmissão de dados. A estratégia de alocação
de TS pode variar de operadora para operadora, de uplink para downlink, conforme horários e/ou datas com maior demanda. Diante de uma redução na demanda pelo tráfego de
24
voz, o sistema pode dinamicamente optar por alocar maior capacidade para a transmissão
de dados (UNIVERSITY OF MORATUWA, a).
2.5
MODELO DE SEGURANÇA
O modelo de segurança dos sistemas tem por objetivo evitar o acesso não autorizado à
rede e proteger a privacidade dos usuários móveis. As principais funções que os sistemas
oferecem incluem (XENAKIS et al., 2008) o módulo de identidade do assinante, o sigilo de
identidade do assinante, a autenticação do assinante e a proteção dos dados do usuário e
de sinalização.
Cada assinante móvel utiliza um cartão SIM, o qual contém um número permanente
e único de identificação do usuário no mundo, o IMSI. Além disso, o cartão SIM contém
uma chave secreta Ki de 128 bits utilizada para autenticação do usuário, um algoritmo de
autenticação (denominado A3) e um algoritmo gerador de chaves de seção Kc (conhecido
como A8).
A privacidade do assinante está atrelada ao sigilo do IMSI e da localização do usuário.
Tal sigilo é atingido através de uma identidade temporária chamada TMSI, o qual efetivamente identifica o usuário na rede. A relação entre TMSI e IMSI é conhecida apenas
pelo MS, VLR e SGSN.
A conexão da MS à determinada PLMN se dá através de um processo de challengeresponse, onde um número aleatório RAND (Random Challenge) é produzido para desafiar a MS, que por sua vez consegue computar a resposta SRES (Signed RESponse)
correta através de uma chave secreta Ki de 128 bits, compartilhada entre MS e AuC. Por
este motivo, define-se Ki como sendo a chave de autenticação do assinante (Subscriber
Authentication Key). Mais adiante serão apresentados os detalhes envolvidos neste processo, assim como o algoritmo de autenticação conhecido como A3.
Para complementar as bases do modelo de segurança GSM, outra chave de 64 bits
denominada Kc (Ciphering Key, também conhecida como Session Key) foi criada para
criptografar as informações que trafegam pela interface Um. A chave Kc é gerada pelo
algoritmo A8 descrito mais adiante.
Finalmente, a proteção dos dados na interface Um (XENAKIS et al., 2008) é dada pela
famı́lia de algoritmos GSM A5/x, onde A5/0 constitui o algoritmo sem nenhuma encriptação. Nomenclaturas de A5/1 em diante identificam os algoritmos com graus diferentes
na complexidade da encriptação.
Fazendo uma referência rápida à arquitetura de rede descrita anteriormente, têm-se
que as seguintes entidades estão envolvidas no armazenamento de informações de segurança (ETSI, 1996b):
25
• HLR e VLR, onde, para cada IMSI, são armazenados os respectivos conjuntos de
Kc, RAND e SRES;
• AuC, contendo a chave Ki de cada IMSI (base de cálculo para os algoritmos A3 e
A8, do lado da rede);
• MSC e BTS, onde se executa o algoritmo de encriptação A5;
• MS, contendo as chaves Ki e Kc, assim como os algoritmos A3, A5 e A8.
2.5.1
Conceitos de Segurança
Tendo como guia o modelo CIA (Confidentiality, Integrity and Availability) (PRASAD,
2011), torna-se interessante abordar alguns conceitos de segurança antes de aprofundar
na aplicação GSM propriamente dita:
- Confidencialidade: A confidencialidade pode ser definida como sendo a capacidade
do sistema em restringir o acesso à informação apenas aos usuários autorizados. Em
um sistema ideal, nenhuma entidade ou pessoa seria capaz de acessar uma informação
confidencial sem a devida autorização. No caso do GSM/GPRS, onde as informações
trafegam em um meio fı́sico aberto, a confidencialidade pode ser obtida através do uso de
criptografia na interface Um.
- Integridade: A integridade constitui a capacidade do sistema em evitar que as informações sejam alteradas indevidamente. Desta forma, assegura-se que a informação
original chegará a seu destino sem nenhum comprometimento.
- Disponibilidade: A disponibilidade pode ser descrita como sendo a capacidade de
pronto acesso às informações em todos os momentos, considerando que os princı́pios de
confidencialidade e integridade também sejam satisfeitos.
- Criptografia: A criptografia constitui técnica utilizada para eliminar a inteligibilidade da informação trafegando no meio, fazendo uso de uma codificação regida por chaves secretas conhecidas apenas pelos agentes autorizados a participar da comunicação.
Implementada através de algoritmos criptográficos, tem-se que o grau de segurança da
criptografia está diretamente relacionado ao (ERIKSSON, 2005):
• tempo necessário para quebrar seu algoritmo;
• custo envolvido no processo de quebra do algoritmo;
• relação entre a quantidade de informação protegida versus a quantidade de dados
necessários para quebrar o segredo;
Quanto mais difı́cil de quebrar a proteção, mais eficaz será a técnica de criptografia utilizada.
26
- Cleartext: Termo que se refere aos dados que foram transmitidos em seu formato
original, inteligı́vel, sem sofrer qualquer processo de encriptação.
- Plaintext: Termo utilizado muitas vezes como sinônimo de cleartext, mas que na
prática refere-se aos dados que serão submetidos ao algoritmo de encriptação. Por este
motivo, dados em plaintext também não passaram pelo processo de encriptação.
- Encriptação: Constitui o processo de transformação da mensagem plaintext em dados
criptografados, inteligı́veis apenas aos usuários e entidades possuidores da chave secreta
para sua devida decriptação (ou àqueles cuja capacidade ofensiva exceda o grau de proteção oferecido pelo algoritmo criptográfico do sistema).
- Decriptação: Processo contrário ao de encriptação, regido segundo as mesmas regras.
2.5.2
GSM: Funções e Serviços de Segurança
Os serviços e funções relacionados à segurança do sistema GSM podem ser agrupados
conforme abaixo(ETSI, 1996b):
- Identidade do assinante: A identidade do assinante é garantida pelo IMSI, um
número exclusivo de 15 dı́gitos armazenado no SIM card, sem o qual nenhuma MS consegue
acessar os serviços GSM. Conforme apresentado anteriormente, cada ME precisa estar
associado à um SIM card para constituir uma MS.
- Privacidade do assinante: A privacidade do assinante está atrelada ao sigilo do
IMSI e da localização do usuário. Tal sigilo é atingido através da identidade temporária
TMSI, o qual efetivamente identifica o usuário na rede. A relação entre TMSI e IMSI é
conhecida apenas pelo MS, VLR e SGSN (XENAKIS et al., 2008), eliminando consequentemente a relação direta com os respectivos assinantes em caso de escuta inadequada dos
canais de sinalização. Como resultado, tem-se o aumento da privacidade do usuário tanto
no que diz respeito à confidencialidade dos dados quanto à sua localização. A eficácia
desta função parte do pressuposto que o IMSI não deve ser transmitido em cleartext de
forma corriqueira (ETSI, 1996b), porém brechas foram criadas para o caso de MSs que
acabam de ser ligadas, ou casos em que a MS não consegue se conectar ao HLR. Por
não conseguir reconhecer a identidade do usuário, a rede consequentemente não consegue
estabelecer uma encriptação, sendo necessário transmitir o IMSI em cleartext (ERIKSSON,
2005; OLAWSKI, 2011).
- Autenticação do assinante: A autenticação do assinante ocorre segundo processo
detalhado na subseção 2.5.3, onde um número aleatório RAND é transmitido para a MS,
que por sua vez utiliza o algoritmo A3 e a chave Ki armazenada no SIM card para calcular a
resposta SRES. Por também conhecer a chave Ki do assinante, o sistema consegue verificar
a validade da resposta SRES e consequentemente autenticar o assinante.
27
- Confidencialidade na sinalização e transmissão de dados: A confidencialidade
das informações que circulam nos canais GSM (como, por exemplo, dados de voz transmitidos no TCH) precisam levar em consideração os quatro fatores abaixo (ETSI, 1996b):
• método de encriptação;
• configuração da chave de segurança;
• inı́cio e o término do processo de decriptação;
• sincronização.
Os mesmos serão abordados mais adiante, no tópico Encriptação.
2.5.3
Autenticação
Toda MS que deseje acessar a rede GSM precisa primeiramente autenticar-se perante
a rede. Supondo uma MS que acaba de ser ligada dentro de determinada visited network,
temos na sequência abaixo a descrição de todos os passos envolvidos no processo de autenticação:
1. Primeiramente, a MS é induzida a transmitir seu IMSI em cleartext para o VLR
da visited network, sendo este um dos bancos de dados do MSC conforme visto
anteriormente;
2. O VLR da visited network encaminha o IMSI ao HLR da home network do assinante;
3. Normalmente integrado ao HLR nas redes GSM, o AuC da home network detém
a chave secreta Ki do usuário. Desta forma, o AuC consegue gerar os Vetores de
Autenticação GSM, muitas vezes chamados de triples por conter (ETSI, 1996c):
• o desafio aleatório RAND, com 128 bits, também chamado de Authentication
Request;
• a resposta correta ao desafio aleatório, SRES, com 32 bits, também chamado de
Authentication Response. O RAND e SRES definem o par challenge-response
de autenticação;
• uma session key Kc, sendo esta a chave que será posteriormente utilizada para
encriptação da interface Um;
4. O HLR encaminha os vetores de autenticação para o MSC da visited network em
questão;
5. O MSC da visited network transmite o RAND à MS utilizando o subsistema BSS
como interface;
6. Considerando o RAND e a chave Ki armazenada no SIM card, a MS consegue
calcular o SRES’ através do algoritmo de autenticação A3 (este também armazenado
no SIM card );
28
7. Uma vez calculado, a MS transmite o SRES’ para o VLR da visited network ;
8. Caso o SRES’ recebido da MS seja igual ao SRES gerado pela AuC da home network,
o VLR da visited network poderá dar por completa a autenticação do assinante;
9. Por medida de segurança, o VLR também atribui um TMSI à MS visando evitar a
transmissão do IMSI do assinante pela rede.
A Figura 2.10 compila as informações acima apresentadas, ao mesmo tempo em que
antecipa os passos relativos à encriptação atribuindo uma ordem cronológica aos eventos.
(Ki)
Figura 2.10: Diagrama sequencial de autenticação e encriptação
Algoritmo A3
O algoritmo de autenticação é responsável pelo cálculo da resposta SRES (com 32 bits)
para o desafio aleatório. Conforme Figura 2.11, o valor de SRES é gerado pela combinação
dos seguintes parâmetros:
• desafio aleatório recebido do MSC (RAND, com 128 bits);
• chave secreta (Ki).
29
Figura 2.11: Algoritmo de autenticação A3
Quando o assinante está fora de sua rede local, como por exemplo viajando em um outro
paı́s, a Rede local solicita os triples (RAND, SRES e Kc) para o HLR da rede local do
assinante.
2.5.4
Encriptação
Conforme introduzido anteriormente, a criptografia constitui a técnica utilizada para
eliminar a inteligibilidade da informação trafegando no meio, fazendo uso de uma codificação regida por chaves secretas, conhecidas apenas pelos agentes autorizados a participar
da comunicação. A encriptação por sua vez constitui o processo de transformação da mensagem plaintext em dados criptografados, enquanto a decriptação estabelece o processo
inverso.
A encriptação dos dados na interface Um (transmitidos em DCCH ou TCH) ocorre
após a autenticação da MS na rede. Para cada frame enviado na interface Um, uma
diferente combinação de Kc e FN constitui o chamado keystream utilizado para encriptar/decriptar os dados. Como o FN varia a cada frame, temos um único keystream para
cada instante de transmissão. A complexidade da encriptação varia conforme o algoritmo
criptográfico negociado entre MS e BTS no momento do Security Setup, o qual será abordado mais adiante.
Por demandar grande capacidade computacional, os algoritmos criptográficos GSM
(pertencentes à GSM A5/x) não foram atribuı́dos ao SIM card (CPU de 8 bits) tal como
os algoritmos A3 e A8. Ao invés disso, os algoritmos A5 foram confiados ao ME da MS.
Key settings
Seguindo grande sinergia com a sequência de autenticação apresentada anteriormente,
a obtenção da chave Kc se dá de forma indireta na MS logo após o MSC enviar o RAND.
Com o auxı́lio do algoritmo A8, a MS consegue deduzir o valor da chave de encriptação
(também chamada chave de seção) ao combinar o conteúdo do RAND com o Ki armazenado no SIM card. O novo valor de Kc calculado a partir do challenge deve ser armazenado
no SIM card antes que o SRES’ seja encaminhado (ETSI, 1996c).
Na prática, o novo valor de Kc sobrescreve o valor da chave de seção anteriormente gravada no SIM, mantendo seu valor inalterado até que uma nova autenticação ocorra na
rede. Cabe a cada operadora GSM definir sua estratégia de autenticação, contanto que
atenda aos requisitos mı́nimos estabelecidos pelo padrão (como autenticar sempre que
30
uma chamada é originada pela MS, ou sempre que ocorrer uma atualização de localização) (MEYER; WETZEL, 2004). Desta forma, o valor de Kc pode ser mantido por um longo
perı́odo de tempo, mesmo em caso de diversas chamadas recebidas ou inclusive handover
para uma nova célula.
Do outro lado da interface Um, a BTS recebe Kc do MSC, que por sua vez obteve a
informação através dos triples do HLR.
A encriptação dos dados na interface Um ocorre após a autenticação da MS na rede. Ao
receber o Ciphering Mode Command, a MS faz com que o valor de Kc armazenado no
SIM card migre para o ME, onde o algoritmo A5 irá trabalhar.
Security Setup
Imediatamente após a autenticação, a MS e a BTS precisam entrar em comum acordo
sobre o algoritmo de encriptação a ser utilizado. Inicia-se portanto o processo de Security
Setup, onde (MEYER; WETZEL, 2004; STROBEL, 2007; ERIKSSON, 2005):
1. primeiramente a MS informa a BTS sobre as suas security capabilities. Neste momento, a MS esclarece quais algoritmos de encriptação são suportados em seu ME;
2. logo em seguida a BTS seleciona um dos algoritmos suportados pela MS;
3. finalmente, a BTS informa a MS sobre sua decisão através do Ciphering Mode Command. Tipicamente a rede GSM seleciona o algoritmo mais forte suportado pela MS.
Ciphering Mode Settings
Trata-se do procedimento de ajuste do modo de encriptação. Segundo este processo,
a rede compartilha com a MS sua decisão com respeito ao uso de criptografia na interface
Um e o algoritmo de encriptação selecionado (lembrando que A5/0 constitui uma opção válida, representando nenhuma encriptação). O processo é iniciado sempre que a rede
deseja mudar o modo de atuação, de ciphered para not ciphered, e vice versa (ETSI, 1996c):
1. Através do canal de sinalização DCCH, a rede inicia o processo encaminhando uma
mensagem de Ciphering Mode Command para a MS. O conteúdo da mensagem
indica se a interface fará o uso de criptografia, e qual o algoritmo a ser utilizado;
2. Ao receber o Ciphering Mode Command, a MS faz com que o valor de Kc armazenado
no SIM card migre para o ME, onde estão localizados os algoritmos criptográficos
suportados;
3. A partir deste momento, a MS inicia a migração para o modo (ciphered ou not
ciphered ) definido na mensagem de Ciphering Mode Command ;
4. Quando concluı́do o processo, a MS responde com a mensagem de Ciphering Mode
Complete;
5. Ao receber a mensagem de Ciphering Mode Complete, a rede inicia a transmissão
segundo o novo modo definido.
31
Iniciando o processo de encriptação e decriptação
Quando operando em modo ciphered, ambas MS e BTS precisam entrar em concordância sobre o momento em que a encriptação e decriptação dos dados será efetivamente
iniciada. De forma semelhante ao processo de Ciphering Mode Settings, segue que (ETSI,
1996b):
1. Através do canal de sinalização DCCH, a BTS encaminha uma mensagem especı́fica
de Start Cipher para a MS;
2. Ao receber o Start Cipher, a MS imediatamente inicia o processo de encriptação dos
dados;
3. Por sua vez, a BTS aguarda o recebimento do primeiro frame (ou mensagem) da
MS para dar inı́cio a encriptação dos dados.
A Figura 2.12 resume os passos descritos nos tópicos acima.
Capacidades de Segurança
(Security Capabilities)
Encriptação Selecionada
Enviar Kc
(armazenado no
SIM) para o ME
(Ciphering Mode Command)
ME
.
.
.
.
.
A5
Enviar primeiro
frame criptografado
Seleção do
Algoritmo
Criptográfico
Migração para o
modo “ciphered”
ou “not-ciphered”,
conforme comando
Migração Concluída
(Ciphering Mode Complete)
Iniciar Encriptação
(Start Cipher)
Dados= A5(Kc , FN)
Dados= A5(Kc , FN)
Iniciar
transmissão
criptografada
Dados= A5(Kc , FN)
Figura 2.12: Diagrama sequencial de encriptação
Algoritmo A8
Por sua vez, o A8 constitui o algoritmo gerador da chave de seção Kc (com 64 bits)
posteriormente adotada na encriptação da interface Um (vide algoritmo A5). Conforme
32
Figura 2.13, a MS consegue derivar o valor de Kc ao combinar os seguintes parâmetros:
• desafio aleatório (RAND) recebido do MSC;
• chave secreta (Ki).
Do outro lado da interface Um, a BTS recebe Kc do MSC, que por sua vez obteve a
informação através dos triples do HLR.
Figura 2.13: Algoritmo calculador de chave de seção, A8
Algoritmo COMP128
Na prática (PESONEN, 1999; BRICENO, 2008), o COMP128 se tornou o algoritmo
utilizado para implementar o A3/A8 na maioria das redes GSM. Conforme Figura 2.14, o
COMP128 gera de uma só vez ambos SRES e Kc em uma saı́da de 128 bits, ao combinar
os valores de RAND e Ki:
• SRES constituı́do pelos primeiros 32 bits de saı́da;
• Kc formado pelos últimos 54 bits de saı́da (10 bits zero são adicionados ao final da
chave Kc gerada pelo COMP128).
Em sua primeira geração, o algoritmo ficou conhecido como COMP128v1, uma versão
mais fraca do COMP128 tipicamente implementada em SIM cards até meados de 2002. A
partir de então, sucederam-se as gerações COMP128v2 e COMP128v3 : Apesar de pouca
informação disponı́vel, indı́cios (HACKING PROJECTS, 2013) apontam para o preenchimento dos bits zero acima mencionados. Conforme constatado nos próximos capı́tulos,
observa-se realmente uma evolução no algoritmo dos SIMs mais recentes.
Figura 2.14: Algoritmo COMP128 de autenticação e cálculo de chave de seção
33
Algoritmo A5
No GSM, a proteção dos dados na interface Um (XENAKIS et al., 2008) é dada por
algoritmos-cifra de encriptação pertencentes à famı́lia A5 (GSM A5/x), onde A5/0 significa nenhuma encriptação (cleartext) enquanto as nomenclaturas de A5/1 em diante
identificam graus diferentes na complexidade da encriptação:
• A5/1 constitui a encriptação padrão;
• A5/2 estabelece uma versão propositalmente mais fraca que o A5/1;
• A5/3 implementa uma encriptação mais forte, semelhante ao algoritmo KASUMI
utilizado no UMTS (Universal Mobile Telecommunications System).
Em termos gerais, cada frame enviado na interface Um considera um keystream diferente,
gerado com base na combinação:
• da chave de seção Kc, utilizado durante toda a chamada (ou mais);
• do FN a ser enviado, valor este que varia a cada frame. Como resultado, temos um
único keystream para cada frame.
Tal relação encontra-se representada na Figura 2.15.
Figura 2.15: Algoritmos-cifra de encriptação pertencentes à famı́lia A5
2.5.5
Considerações adicionais para o GPRS
Considerando que o GPRS foi construı́do sobre a infraestrutura GSM, o modelo de
segurança aqui implementado segue praticamente todas as caracterı́sticas descritas anteriormente, apenas com alguns ajustes que possibilitam lidar com os novos elementos de
rede (vide arquitetura GPRS) e o tráfego de dados orientados a pacote (XENAKIS et al.,
2008; XENAKIS; L.MERAKOS, 2002).
Aproveitando os conceitos recém-apresentados para fazer uma recapitulação, se por um
lado sabe-se que o GPRS é capaz de empregar múltiplos TS visando atingir maiores taxas
de transmissão, sabe-se também que os sistemas GSM tradicionalmente consideram que
34
cada usuário irá ocupar apenas um dos TS disponı́veis. Além desta diferença essencial
não comportada pelos elementos de rede GSM, verifica-se que as transmissões GPRS
podem perfeitamente ocorrer enquanto a MS executa um handover de uma BTS para
outra. Desta forma, a transmissão de pacotes não se dá apenas entre diferentes timeslots,
mas efetivamente pode envolver diferentes BTSs (PESONEN, 1999). Considerando que o
FN varia a cada frame transmitido, e que o mesmo constitui uma das entradas para a
formação do keystream de encriptação, verifica-se portanto o motivo pelo qual o GPRS
requer elementos adicionais para viabilizar a reconstrução dos pacotes provenientes da MS,
sua devida decriptação e encaminhamento das informações. Tal operação não poderia ser
confiada a uma BTS GSM tradicional.
Funções e serviços de segurança GPRS
Fazendo uma referência direta com o mesmo tópico previamente abordado para a rede
exclusivamente GSM, os serviços e funções relacionados à segurança do sistema GPRS
podem ser agrupados conforme abaixo (XENAKIS et al., 2008; XENAKIS; L.MERAKOS, 2002;
ERIKSSON, 2005):
• Identidade do assinante, sendo esta exatamente igual ao GSM;
• Privacidade do assinante, similar ao GSM, onde o P-TMSI (Packet Temporary Mobile Subscriber Identity) constitui a identidade temporária do assinante na rede;
• Autenticação do assinante, sendo este um processo semelhante ao GSM onde a SGSN
assume a responsabilidade previamente confiada ao MSC. Por este motivo, os triples
também são diferenciados, sendo eles denominados GPRS-RAND, GPRS-SRES e
GPRS-Kc;
• Confidencialidade na sinalização e transmissão de dados, empregando algoritmo próprio semelhante ao GSM-A5, denominado GPRS-A5, ou GEA (GPRS Encryption
Algorithm);
• Segurança do backbone GPRS, parcela exclusiva ao sistema GPRS.
Backbone GPRS
Mais conhecida pelo termo em inglês backbone, a espinha dorsal da rede GPRS pode ser
definida como sendo a estrutura responsável pela transmissão de dados e sinalização pela
rede, constituı́da pelos elementos fixos da arquitetura GPRS e suas respectivas conexões
(com caracterı́sticas e preocupações diferenciadas em relação à interface Um, escopo real
do trabalho). Os backbones GPRS podem ser classificados como:
• Intra-PLMN Backbone, referente aos elementos de rede e conexões fı́sicas sob responsabilidade de uma única operadora;
• Inter-PLMN Backbone, referente à porção da rede responsável por interconectar
diferentes Intra-PLMN Backbones sob os cuidados de diferentes operadoras.
35
Para acessar os serviços da rede, a MS precisa primeiramente ser autenticada por uma
SGSN. Ao verificar a autenticidade do assinante, a rede dá inı́cio ao processo de GPRS
attach, atribuindo à MS:
• um P-TMSI;
• um TLLI (Temporary Logical Link Identity), sendo este o identificador da interface
lógica entre a MS e a SGSN.
Após concluir o processo de GPRS attach, a MS precisa obter um endereço IP antes de
iniciar a troca de pacotes de dados com a Internet pública. O acesso à rede IP se dá
através da interface Gi das GGSNs, as quais se assemelham a simples Roteadores quando
vistas de fora para dentro da rede GPRS.
A comunicação entre SGSN e GGSN é baseada em túneis IP, onde cada pacote IP sofre
um novo encapsulamento seguindo o protocolo GTP. O cabeçalho GTP é formado por
campos padronizados que indicam o tipo de mensagem, o número de sequência e o TID
(Tunnel Identifier, formado pela união do IMSI com o NSAPI, Network Layer Service
Access Point Identifier ).
Por conceito, o protocolo GTP empregado entre as GSNs (SGSN e GGSN) não sofre
qualquer processo de criptografia. Referente à sinalização, a tecnologia SS7 empregada
na rede GPRS também não suporta medidas referentes à segurança dos dados. Como
resultado, tanto os dados do usuário quantos os de sinalização circulam em cleartext pelos
backbones GPRS, expondo os mesmos a diversas ameaças, principalmente ao considerar
que a conexão entre Inter-PLMNs Backbones se dá através da Internet pública (XENAKIS
et al., 2008; XENAKIS; L.MERAKOS, 2002; ERIKSSON, 2005).
Por este motivo, a segurança nos backbones GPRS depende basicamente de duas técnicas
adicionais ao padrão:
• Firewalls, que protegem os dados transmitidos dentro do backbone de eventuais
ataques externos, porém não impedem o acesso de outros usuários móveis mal intencionados ou de qualquer outra entidade com acesso ao meio (como por exemplo,
os próprios funcionários das operadoras);
• VPN, Virtual Private Networks, que estabelecem uma conexão entre os elementos
fixos de rede, o gateway de saı́da da rede GPRS e o gateway de segurança de uma
rede privada corporativa remota.
Por extrapolar os limites da interface Um inicialmente almejada, considera-se que o estudo
das vulnerabilidades associadas aos backbones GPRS está fora do escopo do presente
trabalho.
36
Capı́tulo
3
Arquitetura dos Sistemas GSM/GPRS sob a
ótica da atualidade
3.1
INTRODUÇÃO
Na medida em que a comunidade cientı́fica avança nos estudos do GSM e GPRS, novas possibilidades e novas ameaças surgem no caminho dos pesquisadores e projetistas de
sistemas. Enquanto frentes de pesquisa tratam de oportunidades de ampliação da área
de cobertura visando levar o desenvolvimento para regiões remotas do paı́s a um baixo
custo (CABRAL et al., 2009), outras frentes não menos importantes dedicam-se a estudar
fragilidades e vulnerabilidades pouco conhecidas pelos usuários finais dos sistemas.
Acompanhando os novos conhecimentos que surgem a este respeito, observa-se também a considerável redução no custo dos equipamentos (hardware) necessários para se
desenvolver uma rede funcional, bem como a crescente disponibilidade de softwares abertos e gratuitos, acessı́veis a quem quiser explorá-los (APVRILLE, 2011; NATALIZIO et al.,
2010; CABRAL et al., 2009). Por este motivo, sob a ótica da atualidade, os sistemas de
telefonia móvel antes blindados pelo alto custo de implementação tornaram-se perfeitamente acessı́veis, seja para fins acadêmicos, entusiásticos ou exploratórios.
Tendo sua contemporaneidade assegurada através da associação com o GPRS, o sistema ainda vigora entre as diversas frentes de serviço da atualidade, tais como transações
financeiras, rastreamento veicular e até mesmo conexão alternativa para aparelhos celulares de terceira geração. Por este motivo, o estudo das vulnerabilidades inerentes ao modelo
de segurança em vigor torna-se um tema de grande pertinência. O enquadramento dos
conhecimentos e hipóteses segundo critério cientı́fico acadêmico assegura o devido rigor
nas observações e conclusões, dando margem à continuidade das pesquisas levando em
consideração os resultados obtidos e expandindo as possibilidades para novas linhas de
estudos e hipóteses.
Dado a natureza do tema em debate, eventuais resultados obtidos através de simulação computacional dariam margem a questionamentos infindáveis referentes ao modelo
37
Capı́tulo 3. Arquitetura dos Sistemas GSM/GPRS sob a ótica da atualidade
38
adotado, premissas de modelamento ou até mesmo interpretações das especificações do
padrão. Pouco conclusivos seriam os resultados obtidos por meio exclusivamente virtual,
e por esta razão, priorizou-se a abordagem prática do tema.
Para viabilizar esta modalidade de pesquisa aplicada e exploratória, diversos quesitos
precisaram ser avaliados tais como o sistema operacional em que o experimento rodaria,
os equipamentos necessários para a construção de uma rede de baixo custo, a seleção dos
softwares abertos em função dos resultados almejados, a integração entre os diferentes
softwares e finalmente a integração entre o software de baixo nı́vel e o hardware responsável pela criação da interface Um propriamente dita. Sobretudo no que diz respeito à
obtenção dos equipamentos, a busca por parceiros que suportassem a pesquisa através do
empréstimo dos itens de maior valor comercial (tal como a workstation e a USRP, Universal Software Radio Peripheral, posteriormente abordados ao longo do presente capı́tulo)
também constituiu alvo de grande preocupação dado a inexistência de qualquer contato
anterior, bem como o prazo máximo estabelecido para um projeto de mestrado acadêmico.
Aspectos legais foram investigados e levados em consideração antes do inı́cio dos testes
visando evitar interferências com os sistemas de telefonia móvel, assim como a disponibilidade de serviços e a preservação de dados dos usuários (ANATEL, 2006a; ANATEL, 2013d;
ANATEL, 2008; ANATEL, 2007b; ANATEL, 2000; TUDE, 2003b; ANATEL, 2001; ANATEL,
2006b; ANATEL, 2007a; ANATEL, 2013b; TUDE, 2004; TUDE, 2003a; ANATEL, 2013a; COIMBRA, 2006; ANATEL, 2013c). Demonstra-se desta forma a máxima seriedade na conduta
dos experimentos ao incluir no planejamento eventuais itens de impacto social como parte
dos requisitos viabilizadores do experimento.
Antecipando os elementos que serão abordados ao longo do terceiro capı́tulo, a Figura 3.1 mostra a relação entre o mapeamento tradicional da arquitetura GSM (previamente introduzida no capı́tulo anterior) e a arquitetura adotada no presente trabalho.
Este capı́tulo destina-se à apresentação dos elementos que constituem a arquitetura
experimental que servirá de base para o experimento. Complementarmente, aprofundase também na análise de vulnerabilidades inerentes ao sistema de telefonia móvel em
questão, seus principais modos de falha e, consequentemente, os tipos de ataque com maior
probabilidade de sucesso. Finalmente, são apresentadas as considerações referentes aos
aspectos legais e social visando evitar interferências com os sistemas comerciais, bem como
a disponibilidade de serviços e a preservação dos dados de usuários móveis. Almeja-se
desta forma um melhor preparo para a etapa experimental subsequentemente abordada no
capı́tulo IV, servindo tais informações de guia para a condução e ajuste dos experimentos.
3.2
ELEMENTOS DA ARQUITETURA
Conforme a Figura 3.1 , alguns elementos de diferente natureza constituem os componentes desta arquitetura proposta:
39
Figura 3.1: Arquitetura GSM com hardware e softwares abertos
• Elementos de natureza fı́sica, tal como a USRP selecionada como sendo o dispositivo
de hardware central do experimento;
• Elementos computacionais, como os softwares especializados selecionados para cumprir determinadas tarefas do sistema;
Alguns elementos não referenciados na Figura 3.1 também integram o experimento
de forma decisiva, tais como dispositivos periféricos de menor relevância financeira e o
sistema operacional que serve de base para todo o trabalho de integração do experimento.
Neste contexto, desenvolve-se nos tópicos abaixo toda a conceituação dos elementos de
arquitetura selecionados.
3.2.1
Equipamentos e periféricos utilizados
Computador
Para a realização do experimento, utilizou-se uma Workstation STi com as seguintes
configurações:
• processador Intel Core 2 Duo E4700 2.60GHz;
• 3GB de memória RAM;
• disco rı́gido de 250GB, posteriormente particionado para lidar com dual boot entre
dois sistemas operacionais diferentes;
• unidade ótica DVD-RW, especialmente útil no momento de instalar os diferentes
sistemas operacionais verificados;
• três portas USB, tendo uma delas mapeada para o uso do gravador de SIM card e
a outra exclusiva para a interface com a USRP.
40
Universal Software Radio Peripheral
A famı́lia de produtos conhecida como USRP constitui solução criada pela Ettus Research (posteriormente adquirida pela National Instruments em 2010 (WEINMANN, 2010a))
para atender a demanda por equipamentos que suportassem os projetos SDR (SoftwareDefined Radio), onde fundamentalmente persegue-se a implementação em software de funções tipicamente atribuı́das ao hardware de rádio (ALMEIDA, 2010). Mais especificamente
(CABRAL et al., 2009), as USRPs foram concebidas para suportar o projeto GnuRadio,
cujos detalhes serão apresentados mais adiante.
Visão Geral – USRP1 Ettus
1) Placa mãe de propósito geral
2) Placa filha Flex900 (900MHz)
3) Placa filha Flex900 (900MHz)
4) Interface USB 2.0
5) Alimentação 6V-DC
6) Interface RF de recepção
7) Interface RF de transmissão
ADC ó Conversor analógico-digital
DAC ó Conversor digital-analógico
FPGA ó Arranjo de Portas Programável em Campo
Clock ó 64MHz (original)
Figura 3.2: Visão geral sobre a USRP1
Fruto de importante empréstimo realizado por parceiros da UFABC, o equipamento denominado USRP1 (precursor da famı́lia USRP) efetivamente possibilita a criação da interface Um, exercendo grande parte das funções desempenhadas pelas BTSs. Em sua versão
comercial, a USRP1 originalmente dispõe de:
• interface USB 2.0 padrão A/b (mesmo utilizado em impressoras);
• interface de alimentação para plugue P4 com positivo central;
• interface para antena de recepção padrão SMA;
• interface para antena de transmissão padrão SMA;
• uma placa-mãe de propósito geral, contendo:
41
– capacidade de acomodação (porém não equipadas com) para até 4 placas-filha
com operação definida segundo faixas determinadas de frequência, sendo 2
daughterboards para transmissão e 2 para recepção;
– 4 conversores analógico-digital (ADC);
– 4 conversores digital-analógico (DAC);
– arranjo de portas programável em campo (FPGA);
– clock de 64MHz, valendo-se de um oscilador XO (crystal oscillator ) de baixo
custo.
O equipamento acima descrito merece o devido destaque quando a sua estratégia de clock.
Por este motivo, o clock da USRP1 será tratado como item à parte.
Clock
Conforme antecipado no tópico anterior, a USRP1 originalmente emprega um clock
interno de 64MHz com baixa precisão. Esta configuração resulta em dois problemas
distintos:
• imprecisão na geração de frequências de RF e temporização;
• recursos computacionais adicionais para adequar-se à taxa de sı́mbolos GSM.
Para compreender cada um destes problemas, bem como racionalizar a questão da troca
ou permanência do clock original da USRP1 em experimentos GSM, torna-se necessário
observar alguns detalhes.
Conforme ETSI, a BTS deve usar uma única fonte de frequência com precisão absoluta
melhor que 0.05ppm (parts per million, unidade utilizada para especificar a variação de
frequência de osciladores e dispositivos de controle de frequência (LLC, 2013)) para gerar
as frequências de RF e a temporização de clock. A mesma fonte deve ainda ser usada por
todas as portadoras da BTS.
A questão da imprecisão torna-se evidente ao considerarmos que o clock da USRP1 usualmente apresenta variações na ordem de 20ppm (WEINMANN, 2010b). Para facilitar a
visualização do problema, encontra-se na Equação 3.1 (LLC, 2013) a correlação entre a
variação em ppm e os efeitos que esta variação traz na frequência:
∆f = (f.ppm)/106
(3.1)
A Tabela 3.1 sumariza o cálculo dos impactos para 4 diferentes frequências, visando simbolizar os efeitos que tal variação causaria sobre as principais bandas do GSM. Observa-se
que 0.05ppm corresponde à uma variação de apenas 45Hz na faixa dos 900MHz (faixa de
operação das placas de RF utilizadas no experimento), ao passo que 20ppm resultam em
um ∆f de 18kHz. Tamanha diferença também pode ser observada na escala temporal,
comparando-se os efeitos das variações sobre o perı́odo, em segundos. A mesma análise
também é válida para as demais frequências calculadas.
Estando fora do alcance para a configuração original da USRP1, a tolerância máxima
42
de 45Hz impõe o uso de osciladores muito mais precisos, tal como um VCTCXO (Voltage Controlled, Temperature Compensated Crystal Oscillators) disciplinados por GPS
ou até mesmo um OCXO (Oven-Controlled Crystal Oscillator ) (BURGESS; SAMRA, 2008;
OPENBTS, a).
Tipicamente, na outra extremidade, um ME emprega osciladores VCTCXO de média
qualidade, apresentando cerca de 20ppm (OPENBTS, a) no momento em que são inicializados (ou seja, sem a referência do clock externo da BTS). Tal valor constitui apenas
uma referência para o presente trabalho, sendo que na prática, a variação do oscilador de
cristal da USRP1 pode inclusive estar fora do range de busca por frequências de alguns
aparelhos GSM (BURGESS; SAMRA, 2008). Ao começar a busca por uma rede, cada MS
Tabela 3.1: Cálculo de impactos do clock sobre as faixas de frequência GSM
inicia uma varredura de frequências cobrindo toda a faixa de possibilidades, segundo a
precisão de seu próprio oscilador interno. Após cumprir com a sequência tı́pica de acesso
descrita no capı́tulo 2, a MS capacita-se a corrigir seu clock interno com base no clock da
BTS, agindo sobre a tensão de controle de seu oscilador de forma a equiparar-se à precisão
da rede.
Em caso de perda do sinal, a MS consegue em um primeiro momento realizar uma busca
mais seletiva de frequências, considerando que as variações de seu clock interno não distorceram mais do que algumas centenas de Hertz da frequência esperada (OPENBTS, a).
Tal premissa, porém, não pode ser sustentada por muito tempo, fazendo-se necessário
um relaxamento desta restrição e a consequente realização de varreduras mais amplas, na
medida em que se perde a antiga referência da BTS. Aparelhos que suportem múltiplas
bandas podem inclusive mudar para faixas de frequência diferentes, conforme abordado
anteriormente.
Tendo compreendido as questões relacionadas à precisão, torna-se necessário abordar o
problema da taxa de sı́mbolos GSM previamente apresentado. Recorrendo novamente
aos conceitos introduzidos no capı́tulo 2, verifica-se no GSM uma taxa de sı́mbolos total
de 270.833ksı́mbolos/segundo, resultantes da taxa de modulação de 270.833 kbits/s e da
correlação de 1 bit por sı́mbolo implementada no GMSK. Consegue-se facilmente derivar
esta taxa ao empregar clocks múltiplos de 13MHz, que ao sofrer uma divisão por múltiplos de 48, resultam nos desejados 270.833 kHz (13/48 MHz). Neste sentido, observa-se a
frequente adoção de clocks de 52MHz, sendo este um múltiplo inteiro de 13MHz (4 vezes
43
maior).
Ao analisar os 64MHz inerentes ao clock original da USRP1, verifica-se que a relação
entre o mesmo e a taxa de sı́mbolos GSM não se dá de forma direta. Para manter
os 270.833ksı́mbolos/s, precisa-se lançar mão de um numerador fracionário não inteiro
(aproximadamente 236,308). Esta adequação constitui uma complexidade adicional ao
software utilizado para fazer a interface com a USRP1.
Como alternativa, a USRP1 permite a substituição de seu clock por outro mais preciso. Opções comerciais tais como ClockTamer e Funkamateur (OPENBTS, a; WEINMANN,
2010a) (ambos indisponı́veis no momento em que a pesquisa foi conduzida) apresentam
grande aceitação nos projetos que utilizam USPR1 para redes GSM. Em uma quantidade
notoriamente reduzida de citações, encontra-se em NATALIZIO et al. um exemplo de criação
de fonte externa de sinal produzindo ondas quadradas de 52MHz com uma amplitude de
1,5 V (0-1.5V). Porém, conforme WEINMANN , deve-se ter muito cuidado em casos como
este para não danificar as USRPs: Algumas aplicações TTL (Transistor-Transistor Logic)
em 5 volts já teriam resultado em danos permanentes ao equipamento.
Assim como os demais trabalhos de natureza prática levados em conta durante o presente
experimento, verifica-se que a troca do clock não estabelece tema de menor preocupação.
Sugestões de modificação do hardware da USRP1 encontram-se disponı́veis em OPENBTS;
GNU RADIO, as quais propositalmente não serão seguidas por motivos melhor explicados
adiante. Obviamente, os cuidados descritos para a USRP1 não se aplicam aos demais
produtos da famı́lia USRP (como, por exemplo, a USRP2, E100, E110, N200, N210, B100
e B200): Para tais equipamentos, encontra-se em GNU RADIO um bom ponto de partida.
Finalmente, digna-se apenas dizer que a utilização de um novo clock também requer mudanças na configuração dos softwares que constituem os demais elementos da arquitetura,
tal como o GnuRadio e o OpenBTS.
Placas-filha
Apesar de conseguir comportar um maior número de placas-filha, o experimento valeuse de apenas 2 daughterboards adicionadas como acessório na USRP1:
• uma RF Daughterboard Flex900, capaz de transmitir na faixa entre 750 e 1050MHz,
com uma potência de transmissão de até 200mW (23dBm);
• uma RF Daughterboard Flex900, capaz de receber na faixa entre 750 e 1050MHz;
A combinação de ambas as placas periféricas possibilita o trabalho com redes GSM na
faixa dos 900MHz, conforme previamente apresentado na Tabela 2.1. Tal configuração
mostra-se a mais apropriada para lidar com os aspectos legais identificados durante a
etapa preparatória do trabalho: Visando transmitir dentro dos limites estabelecidos para
as faixas ISM (Instrumentation, Scientific and Medical ), verifica-se uma pequena sobreposição do espectro de frequências GSM e o segmento de espectro ISM entre 902 MHz e
928 MHz (PAGET, 2010b; ANATEL, 2006a).
Para a faixa dos 900MHz em questão, tem-se as opções do P-GSM (Primary GSM), EGSM (Extended GSM) e GSM-R (GSM Rail ). Porém, conforme Tabela 2.1, verifica-se
44
que as frequências de downlink dos ARFCNs 1 a 124 disponibilizados no P-GSM extrapolam os limites do segmento ISM. Para ajustar a frequência de transmissão aos limites
desejados, pode-se recorrer ao canal mais baixo da porção estendida do E-GSM, o qual
também integra a gama de canais presentes no GSM-R.
O ARFCN 975 constitui portanto uma saı́da elegante ao problema, permitindo ajustar o
sistema para transmitir (downlink ) em 925.2MHz, frequência esta contida na faixa ISM
e também reconhecida pelos MSs GSM capazes de operar na faixa de 900MHz. Para
todos os efeitos, não se infringe o critério estabelecido pela ANATEL para operação de
equipamentos de radiação restrita (ANATEL, 2008).
Antenas
Para trabalhar na faixa descrita no tópico anterior, foram adquiridas duas antenas
Quad-Band padrão SMA para uso celular segundo as bandas de frequência descritas na
Tabela 3.2, conforme dados do Fabricante SPK. Os pequenos desvios de frequência de
uplink e downlink considerados no presente trabalho não chegam a ter relevância para
a condução do experimento, sobretudo considerando a natureza aproximada dos valores
estabelecidos pelo Fabricante.
Tabela 3.2: Frequências de trabalho das antenas quad-band
Fonte de Alimentação
As fontes originais comercializadas pelo fabricante (ETTUS RESEARCH, b) possuem
capacidade de fornecimento limitada em 3A. Visando não comprometer o desempenho
da USRP com as 2 placas filhas adicionais, optou-se pela utilização de uma fonte com
capacidade estendida para 5A.
ME
Para a outra ponta do experimento, foram adquiridas duas unidades de aparelho celular
Nokia modelo 3310. Objetiva-se com isto a obtenção de múltiplos MEs para testes práticos
na rede, sendo o modelo 3310 da Nokia escolhido por seu baixo custo e também por conter
a função NetMonitor, a qual pode ser ativada com o auxilio de um data cable e software
especı́fico para monitoramento de rede. Dificuldades na obtenção do data cable necessário
para tal ativação impossibilitaram a utilização da função NetMonitor durante a fase de
estabelecimento da rede.
45
SIM Card Programável
Complementando a MS, foram comprados dois programadores de SIM card e 3 cartões
SIM programáveis de duas diferentes marcas, conforme ilustra a Figura 3.3.
Para desvincular os cartões SIM de qualquer operadora, adotou-se como padrão no momento da escrita:
• MCC = 001 (Identificador universal para testes);
• MNC = 01 (Operando em modo de teste);
• MSIN = 10 dı́gitos aleatoriamente escolhidos
A escrita e leitura dos SIM cards pode ser realizada através do software pySim relacionado
mais adiante.
Figura 3.3: Leitores e programadores de SIM card
3.2.2
Software
Os softwares pesquisados para viabilizar este experimento podem ser agrupados e três
categorias, sendo elas:
• Sistema Operacional;
• Elementos da Arquitetura de Rede;
• Softwares Auxiliares.
Os próximos tópicos serão utilizados para detalhar cada um destes grupos.
Sistema Operacional
Considerando que a grande maioria dos softwares selecionados para o experimento são
aplicativos Unix de código aberto, a escolha do sistema operacional torna-se algo relevante.
Alguns dos sistemas operacionais comumente comercializados no mercado não constituem
46
uma alternativa para o experimento, tal como o Windows e suas diversas revisões baseadas
em MS-DOS (MicroSoft Disk Operating System).
Derivados da plataforma Unix, observa-se que os sistemas operacionais Ubuntu, Redhat,
Fedora, Debian e BackTrack figuram dentre as opções mais utilizadas por pesquisadores
do GSM. As vantagens e desvantagens de cada um dos sistemas podem ser alvo de uma
longa discussão, porém resguardando-se às questões práticas, a quantidade de citações foi
o critério adotado para seleção do Ubuntu como base para o experimento.
Construı́do a partir do sistema operacional GNU/Linux, resultado da união entre o núcleo
Linux (kernel ) com os códigos-fonte das ferramentas desenvolvidas pelo projeto GNU,
o Ubuntu é um sistema operacional de código aberto caracterizado por suas revisões
semestrais e amplo suporte técnico após cada lançamento (UBUNTU, 2013).
- Ubuntu Versão 12.04: Versão atual mantida pelos desenvolvedores, encontrandose na revisão 12.04.02 no momento em que os testes foram executados; Comportamento
estável, atualizações que garantem um bom desempenho e vasto suporte da comunidade
são diferenciais frente às versões anteriores. Mesmo sem possuir referências adotando o
Ubuntu 12.04.02 em conjunto com os demais softwares utilizados no presente trabalho,
nenhuma incompatibilidade foi observada.
- Versões anteriores do Ubuntu: Iniciar os trabalhos com versões descontinuadas
(tal como a 10.04 ou a 10.10) mostrou-se uma complexidade adicional no desenvolvimento
dos trabalhos. Não foram encontradas vantagens em manter versões anteriores do sistema
operacional.
Elementos da Arquitetura de Rede
- UHD: Sendo compatı́vel com as principais plataformas disponı́veis na atualidade (incluindo Linux, Windows e Mac), o software UHD (USRP Hardware Driver ) foi criado para
desempenhar a função de hardware driver para todas as USRPs (ETTUS RESEARCH, d).
Suportando a USRP1 em sua configuração original ou já com o clock modificado (ETTUS
RESEARCH, c), o UHD pode ser utilizado em conjunto com outros softwares tais como
o GNU Radio, LabVIEW, Simulink e OpenBTS. O Apêndice B descreve os passos para
download , instalação e configuração do UHD no Ubuntu.
- GNU Radio: Ferramenta gratuita para desenvolvimento de projetos de sistemas de
rádio que visa a máxima transferência de complexidade do hardware para o software. Ao
maximizar as funcionalidades de software, o GNU Radio permite minimizar a complexidade e os custos do hardware necessário para criação de um sistema de rádio. A interface
com o usuário é feita através de gráficos e blocos que representam as fases de processamento de sinal e realçam seu respectivo fluxo de dados.
Sua correta instalação, configuração e integração com a USRP1 representam um processo
repleto de detalhes, exigindo relativo grau de expertise dos interessados no que tange a
análise dos erros reportados pelo sistema. O Apêndice A apresenta os passos e cuidados
47
necessários para baixar, instalar e configurar o GNU Radio 3.3.0, bem como as principais
dicas para se trabalhar com outras versões da ferramenta.
- OpenBTS: Aplicativo Unix de código aberto que utiliza a USRP para criar a interface
Um através do o ambiente GNU Radio. Em sua outra frente de trabalho, o OpenBTS
utiliza o software de PBX (Private Branch Exchange) Asterisk como suporte às demais
funções descritas na arquitetura GSM, garantindo a conectividade das chamadas através da tecnologia Voz sobre IP (VoIP) (APVRILLE, 2011; CABRAL et al., 2009; PERKOV;
KLISURA; PAVKOVIé, 2011). O Apêndice D apresenta os passos e cuidados necessários
para baixar, instalar e configurar o OpenBTS-UHD, bem como as principais dicas para
se trabalhar com outras versões da ferramenta.
- Asterisk: Por sua vez, o Asterisk desempenha as funções tradicionalmente implementadas no BSC, HLR, VLR e MSC. O Asterisk é um software de PBX que utiliza o VoIP
através do Protocolo de Inicialização de Seção (SIP, do inglês Session Initiation Protocol ). Cada MS é visto pelo Asterisk como um usuário SIP, ou seja, cada IMSI será visto
pelo Asterisk como um cliente SIP, permitindo desta forma que chamadas e mensagens
de texto sejam trocadas entre dispositivos GSM e terminais VoIP (NATALIZIO et al., 2010;
CABRAL et al., 2009).
Softwares Auxiliares
Os softwares mencionados abaixo exercem papel secundário, porém importante no
preparo da infraestrutura básica para o experimento.
- pySim: Ferramenta que permite a programação dos Magic SIMs (SIMs programáveis)
de diferentes marcas através de linhas de comando descarregadas diretamente no Terminal
do sistema operacional. O Apêndice C serve como tutorial para download, escrita e leitura
de SIM cards (exemplifica-se o procedimento com a escrita do IMSI 00101 2462443021).
- SIM Easy V8.20: Ferramenta fornecida junto com o gravador de SIM da marca SuperSIM. Rodando em Windows, apresenta uma interface com o usuário mais agradável,
dispensando a utilização de linhas de comando para fazer leitura e gravação dos SIMs.
Porém, seja por um erro proposital ou um bug em sua implementação, o fato é que os
números efetivamente mostrados na tela não correspondem aos números reais gravados
no SIM. Por exemplo, o número correspondente ao IMSI é representado com 18 dı́gitos
ao invés de 15. Guardando-se esta ressalva e abstraindo ao fato de que a informação real
não chega aos olhos do operador, a ferramenta permite a reprodução dos dados de um
SIM card em outro SIM sem distorções, conforme verificado com o auxı́lio da ferramenta
pySim.
Mesmo assim, o SIM Easy V8.20 ainda possui seu valor para o presente trabalho. Elaborado para possibilitar a cópia de cartões SIM comercializado pelas operadoras de telefonia
móvel (seja para criação de backups de segurança, seja por outros motivos), a ferramenta
apresenta uma interessante relação entre a leitura constante do SRES em função do RAND
48
visando mapear o Ki residente dentro do SIM card. Através de uma sucessão de RANDs e
suas respectivas respostas, os algoritmos internos implementados no software são capazes
de encontrar o valor de Ki dos SIM cards, contanto que os mesmos contenham o algoritmo COMP128v1, uma versão mais fraca do COMP128 tipicamente implementada na
primeira geração de SIMs conforme descrito anteriormente. De fato, conforme Figura 3.4,
verificou-se que esta limitação impede a ferramenta de clonar SIMs mais modernos, o
que não significa que os algoritmos deixem de ser aperfeiçoados em novas versões de software para fins comerciais (acessı́veis ao público, como este caso) ou até mesmo para fins
exploratórios (conhecimento restrito).
Figura 3.4: Derivação do Ki de SIM cards contendo o COMP128v1- SIM Easy V8.20
- EaseUS Partition Master 9.2.2: Versão gratuita que auxilia no particionamento
do HD. Rodando em Windows, torna-se de grande valia para a criação de discos com dual
boot permitindo o chaveamento entre diferentes sistemas operacionais na mesma máquina.
Nenhum dano fı́sico ou perda de informações foi detectada após particionamentos da
ordem de até 60GB, mesmo assim, recomenda-se a criação de backups antes de iniciar
qualquer processo. A unidade particionada foi utilizada para instalação dos sistemas
operacionais Ubuntu.
3.3
49
VULNERABILIDADES
Além das três hipóteses centrais apresentadas no primeiro capı́tulo, encontram-se resumidas neste item as principais vulnerabilidades identificadas durante a etapa conceitual
do trabalho. Objetiva-se desta forma enriquecer a etapa experimental seguinte, ao mesmo
tempo em que vulnerabilidades não exploradas tornam-se objeto de pesquisa para trabalhos futuros.
Tomando em consideração os princı́pios de autenticação do assinante e encriptação de
dados durante a transmissão, o padrão se vê desde o princı́pio protegido contra ataques
meramente passivos (eavesdropping), caracterizados pela interceptação e escuta do meio
fı́sico tal como ocorria com as tecnologias 1G. Por outro lado, o mesmo empenho não
foi dado na prevenção de ataques ativos, provavelmente por serem considerados na época
uma ameaça improvável dados os conhecimentos necessários e principalmente o elevado
custo de implementação de uma BTS tradicional (OLAWSKI, 2011). Conforme apresentado anteriormente, o atual processo de autenticação se dá apenas em um dos sentidos:
A rede precisa legitimar as MSs, porém as MSs não conseguem verificar a idoneidade das
redes às quais se conectaram.
Ataques ativos, tal como o MITM (man-in-the-middle attack ) e o jamming detalhados a seguir, são caracterizados pela injeção de dados visando o distúrbio de comunicação,
privação de serviços, modificação de dados ou impersonalização (PERKOV; KLISURA; PAVKOVIé, 2011).
3.3.1
IMSI Catcher
Valendo-se da ausência de autenticação das redes perante as MSs, as falsas BTSs conhecidas como IMSI Catchers exploram a busca constante das MSs por melhores sinais,
criando através da interface Um uma estrutura convidativa que apresente melhores condições competitivas frente às demais redes comercialmente oferecidas pelas operadoras
cadastradas.
Dentro de sua área de cobertura, o IMSI Catcher apresenta condições suficientes para
arrebanhar MSs das redes locais. Configurando uma das hipóteses principais deste trabalho, neste momento o dispositivo seria capaz de induzir as MSs a transmitir o IMSI ao
invés do último TMSI atribuı́do pela rede visitada. De uma só vez, o IMSI Catcher consegue contornar a entidade temporária TMSI (criada para evitar a transmissão do IMSI
pela rede) e receber em cleartext o IMSI do usuário. Por este motivo, dá-se tal nome ao
dispositivo.
Ter a identificação do assinante em mãos constitui um importante passo para a elaboração de novas frentes de ataque. Apenas para esclarecimento, emprega-se o termo
ataque no presente trabalho para representar a tentativa de se contornar o modelo de
segurança lançando mão de lacunas conceituais ou vulnerabilidades identificadas. Não se-
50
rão explorados os diferentes desdobramentos de abordagem/motivações/efeitos que cada
tipo de modalidade identificada poderia ganhar, salvo em casos pontuais de grande valor
ilustrativo.
3.3.2
MITM
Segundo ERIKSSON, ataques MITM (mediados pelo homem) configuram-se sempre que
um agressor se posiciona entre o assinante e a entidade legı́tima com a qual o cliente deseja
estabelecer conexão. Neste contexto, desenvolvem-se os itens abaixo:
Monitoramento do usuário
Apesar de não conseguir definir a posição exata do usuário cujo IMSI foi identificado,
consegue-se através do IMSI Catcher delimitar a presença do assinante dentro da área de
cobertura estabelecida. Tal ataque pode ser interessante, por exemplo, em sistemas de
monitoramento veicular, partindo-se do pressuposto que a BTS de ataque não apresenta
limitações fı́sicas que impeçam seu deslocamento. Cria-se com isso as condições para criação de um scanner móvel, trazendo as eventuais consequências segundo estratégia adotada
pelo prestador de serviços de rastreamento. Conforme dito anteriormente, esta vulnerabilidade pode ser explorada com outras intenções, animada por diferentes motivações e
efeitos, os quais não serão exercitados no presente trabalho.
Obtenção do IMEI
Com um pouco mais de investimento nas linhas de código que regem o IMSI Catcher, aponta-se (STROBEL, 2007; WEINMANN, 2010b) a possibilidade de criação de um
procedimento que possibilita a obtenção dos IMEIs de cada ME conectado à rede.
DoS (Denial of Service)
Constitui simplesmente a negação da prestação de serviços para determinado assinante. Sem saber estar sendo vı́tima de uma rede falsa, o usuário torna-se inacessı́vel à
sua rede original. Sob o ponto de vista da operadora, o assinante pode ter intencionalmente desligado o aparelho (assumindo tratar-se de um telefone celular), ou quem sabe
ter entrado em uma área fora de sua zona de cobertura. Sob o ponto de vista da MS, ela
ainda está conectada à rede. Caso nenhum esforço adicional seja empregado na rede falsa
visando à conectividade deste usuário, criam-se as condições necessárias para executar um
ataque do tipo DoS. Tanto para sistemas de telefonia móvel quanto para suas variantes
(como o rastreamento veicular, telemetria, etc), verifica-se a grande pertinência dos efeitos causados pela privação de serviços (sob o ponto de vista do usuário) e visibilidade do
assinante (sob o ponto de vista da operadora).
Como alternativa, o jamming constitui forma menos refinada de ataque DoS, onde realizase a transmissão de ruı́do nas faixas de frequência até o ponto de inviabilizar a comunicação. Porém, podem ser mencionadas como desvantagens do jamming DoS:
• não possui qualquer seletividade, afetando a todos os usuários de uma determinada
região;
51
• requer a transmissão em diversas faixas de frequência, visando efetivamente privar
os usuários multi-band dos serviços de rede;
• pode ser facilmente detectado pelo usuário (ausência de rede).
Fora as questões acima abordadas, a técnica de jamming não será empregada na etapa
seguinte por incorrer na transmissão em faixas de frequência destinadas exclusivamente
às operadoras de telecomunicação.
IMSI spoofing
Justamente por conhecer o IMSI do assinante e ter a certeza de que o mesmo encontrase indisponı́vel para a operadora, um agressor devidamente instruı́do pode se fazer passar
pelo usuário de forma fraudulenta visando tirar proveito da situação.
Após clonar o IMSI do assinante, o agressor passa a se apresentar como sendo o detentor
do mesmo. Com relação ao processo de autenticação, três alternativas seriam possı́veis:
a) Tentar evitar que uma nova autenticação seja iniciada: Segundo PESONEN
e MEYER; WETZEL, cada operadora GSM pode definir sua estratégia de autenticação
contanto que os requisitos mı́nimos estabelecidos pelo padrão sejam cumpridos, tais como
autenticar sempre que uma chamada é originada pela MS ou sempre que ocorrer uma
atualização de localização (chamadas recebidas ou handover para novas células a princı́pio
não seriam considerados obrigatórios). Desta forma, encontra-se um possı́vel artifı́cio para
protelar o processo de autenticação se assim for desejado. Durante este perı́odo, nenhum
RAND será produzido, o que também fará com que o mesmo valor de Kc seja mantido.
b) Iniciar um processo de autenticação: Neste caso, inicia-se propositalmente um
processo de autenticação. Após receber da rede um RAND como desafio aleatório, dá-se
inı́cio ao processo de impersonalização discutido mais adiante. Tal premissa também serve
de base para as teorias de criptoanálise que almejam a quebra do Ki através da interface
Um (PAGET, 2010b; OLAWSKI, 2011; ERIKSSON, 2005; STROBEL, 2007; CRYPTOME, 2010).
Este tema será novamente abordado em tópico especı́fico, porém adianta-se que, como toda
a criptografia do meio reside sobre o segredo do Ki, a quebra deste sigilo constitui a última
fronteira para a escuta irrestrita (eavesdrop) de chamadas telefônicas e/ou mensagens de
SMS terminadas ou originadas pelo usuário.
c) Múltipla apresentação de IMSIs: Neste último caso poderiam ser geradas cópias
de IMSIs respondendo de formas diferentes ao RAND da operadora (diferentes valores de
Ki). Sob o domı́nio de uma mesma BTS ou espalhados por diferentes localidades, trata-se
do método mais trivial dentre os 3 relacionados. Não foram localizadas referências que
apontassem as consequências de tal ataque.
Spoofing da rede
Seja para tornar o ataque imperceptı́vel às vı́timas ou para acelerar a migração de
MSs, o spoofing de redes configura qualquer tentativa de uma rede se fazer passar por
52
outra, tipicamente de uma operadora de telefonia móvel devidamente autorizada.
Normalmente, os identificadores de rede resumem-se a uma combinação do MCC com o
MNC, conforme exemplos abaixo:
• ####
Claro Brasil: MCC = 724; MNC = 05;
• ####
TIM Brasil: MCC = 724; MNC = 03;
Nota: #### para privadade
da operadora local.
Segundo PAGET, algumas MSs podem utilizar o Network Name como critério complementar para hand-over. Desta forma, a alteração destes três parâmetros de rede inviabiliza
efetivamente a distinção entre as redes verdadeiras e a rede falsa.
Impersonalização
Caso o objetivo não seja privar a vı́tima dos serviços móveis caracterı́sticos, podem-se
criar as condições necessárias para interligar a rede falsa aos demais sistemas de telefonia móvel/fixa/dados, utilizando softwares de PBX baseados em VoIP como o Asterisk,
FreeSwitch ou Yate (OPENBTS, c).
a) Apenas chamadas originadas pelo usuário: Conforme visto anteriormente, sob o
ponto de vista das operadoras de telefonia, os usuários conectados à rede falsa encontramse fora da área de cobertura ou desligados. Isto faz com que todas as chamadas destinadas
ao usuário sejam encaminhadas para a caixa postal. Em contrapartida, a rede falsa pode
completar eventuais chamadas originadas pela MS através do VoIP, algo semelhante com
o que ocorre com diversos aplicativos que oferecem serviços de comunicação através da
Internet. O roteamento de chamadas é garantido pelas ferramentas especializadas descritas anteriormente.
No que tange a criptografia entre a MS e a estação, observa-se a possibilidade de simplesmente desativar o uso do Kc no envio dos frames. Como as MSs são obrigadas a
respeitar os modos de operação estabelecidos pelas BTSs, basta que a estação negocie o
A5/0 (cleartext) e o entrave deixa de existir.
Na verdade, tomando o projeto OpenBTS por base, verifica-se que até pouco tempo (BURGESS; SAMRA, 2008) não se cogitava sequer a implementação de criptografia e autenticação
como parte do conteúdo entregue no software de código aberto. Tal decisão foi tomada
por questões legais, uma vez que os algoritmos necessários eram protegidos por termos de
confidencialidade. Parte dos esforços em andamento nas últimas liberações públicas do
software (OPENBTS, d) incluem a possibilidade de se adicionar os processos de autenticação (restrita apenas aos SIMs contendo COMP128v1, segundo OPENBTS) e encriptação.
Partindo-se da versão pública disponibilizada para download, descrevem-se em OPENBTS
os passos adicionais que precisam ser levados em conta caso haja o interesse de criar uma
BTS que suporte algum tipo de encriptação.
Com o auxı́lio de ferramentas como o Wireshark ou da função MixMonitor do Asterisk (VOIP-INFO, 2011a; PAGET, 2010b; PAGET, 2010a; VOIP-INFO, 2011b) pode-se realizar
a escuta e gravação de todo o tráfego de voz entre a MS e a estação criada. Conforme
(VOIP-INFO, 2011a), o Wireshark permite a reprodução do conteúdo tanto em tempo real
quanto após a gravação dos arquivos (entrando em Statistics > VoIP calls).
53
Finalmente, cabe apenas reforçar que tal configuração limita-se exclusivamente à captura
de chamadas originadas pelo usuário. Enquanto sob o domı́nio da rede falsa, as eventuais
chamadas destinadas ao assinante serão encaminhadas para a caixa postal.
b) Chamadas originadas e destinadas ao usuário: Neste ponto apresenta-se a impersonalização em seu sentido completo, onde o suposto agressor apresenta-se em lugar do
assinante capturado em sua rede (IMSI spoofing), iniciando uma verdadeira intermediação
de dados entre a operadora e a MS sob seu controle. Tal intermediação se faz necessária
para contornar a autenticação em um primeiro momento, e logo após, tentar realizar a
quebra da chave secreta Ki.
Ao receber o RAND da operadora, o agressor pode encaminhar o desafio aleatório à MS,
que por sua vez irá calcular o SRES com base no Ki conforme Figura 2.10. Sem se preocupar a princı́pio em quebrar o Ki, o agressor contorna a autenticação ao retransmitir
para a rede o conteúdo gerado pela MS (replay attack, segundo ERIKSSON).
Para obter a chave de segurança Ki, OLAWSKI propõe o bombardeamento de solicitações
de autenticação através da emissão de diversos challenges e o monitoramento dos respectivos responses, fazendo uso da mesma teoria apresentada pela ferramenta SIM Easy
V8.20, porém desta vez através da interface Um. Por não ser algo corriqueiro, tal método
pode levar ao descarregamento precoce da bateria da MS (ERIKSSON, 2005).
Como alternativa, o agressor pode negociar com a rede a utilização de um algoritmo mais
fraco através dos security capabilities anteriormente descritos. Apesar de ser a escolha
mais fácil, o A5/0 provavelmente não seria aceito pelas operadoras (BURGESS; SAMRA,
2008; PAGET, 2010b), o que leva o A5/2 a se tornar a melhor opção. Neste caso, portanto, ainda seria necessário realizar a criptoanálise dos dados até efetivamente conseguir
derivar o valor de chave secreta do usuário.
Como toda a criptografia do meio reside sobre o segredo do Ki, a quebra deste sigilo
constitui a última fronteira para a escuta irrestrita (eavesdrop) de chamadas telefônicas
e/ou mensagens de SMS terminadas ou originadas pelo assinante.
Reconstrução de pacotes GPRS
Recorda-se que a transmissão de pacotes GPRS pode se dar não apenas entre diferentes timeslots, mas também entre diferentes BTSs em casos de handover. Desta forma,
eventuais interceptações de transmissões de pacotes que já tenham sido iniciadas em suas
redes originais constituem portanto um modo de falha especialmente ligado ao GPRS,
prejudicando a devida reconstrução dos pacotes na SGSN.
Porta dos fundos
Tecnologias modernas de telefonia celular que ainda guardem sua compatibilidade
com o padrão GSM (visando tirar proveito de sua ampla e consolidada área de cobertura)
também estão expostas. Apesar das melhorias de segurança introduzidas nos padrões
mais recentes, tal compatibilidade torna-se uma espécie de porta dos fundos sempre que
habilitada nos MS (lembrando que os aparelhos celulares tipicamente apresentam esta
54
configuração disponı́vel caso o usuário deseje desabilitar).
De certa forma, todos os ataques anteriormente descritos podem ser classificados como
MITM, apresentando apenas diferentes graus de complexidade segundo suas finalidades.
Neste contexto, nota-se que mesmo ataques menos complexos (sem envolver a criptoanálise
do meio, por exemplo) podem ganhar proporções expressivas.
3.4
CONSIDERAÇÕES FINAIS
A atribuição de faixas de frequência no Brasil (ANATEL, 2006a) encontra-se sob responsabilidade da ANATEL (Agência Nacional de Telecomunicações), muito embora a
regulação e comunização do espectro de RF seja objeto de preocupação internacional
(COIMBRA, 2006).
Segundo TUDE, o uso da radiofrequência pode estar atrelado à emissão de uma autorização para prestação de serviços, autorização temporária, licenciamento da estação e à
certificação dos equipamentos.
Neste cenário, verifica-se ainda a existência de faixas especı́ficas do espectro reservadas
para a prática de atividades que configurem uso próprio, sem apelo comercial nem prestação de serviços (ANATEL, 2013d; TUDE, 2004). Ao empregar aparelhos denominados
de radiação restrita (limites caracterizados segundo ANATEL), observa-se concordância
do órgão regulador com relação à dispensa das autorizações para uso de tais faixas e o
respectivo licenciamento da estação (como um dos diversos exemplos existentes, vide o
caso de telefones sem fio residenciais).
Por outro lado, caso seja preciso invadir as faixas de frequência reservadas do espectro
(como diante de grandes eventos, demonstrações, etc), pode-se ainda lançar mão de requisições de uso temporário de determinadas bandas. Segundo ANATEL, o uso temporário
de radiofrequência pode ser concedido para qualquer faixa do espectro de RF visando a
condução de serviços especiais de fins cientı́ficos ou experimentais.
Tendo estes fatores em vista, encerra-se o presente capı́tulo descrevendo as principais
considerações realizadas visando evitar interferências com os sistemas comerciais, bem
como a disponibilidade de serviços e a preservação dos dados de usuários móveis. Para
todos os efeitos, buscou-se atribuir o máximo esforço na interpretação e cumprimento das
cláusulas aplicáveis.
Se por um lado estas preocupações impõe um atraso na condução dos experimentos, por
outro lado asseguram a continuidade destas linhas investigativas de maior importância.
3.4.1
55
Espectro de Radiofrequência
Conforme visto anteriormente, a combinação de ambas as placas periféricas Flex900
possibilita o trabalho com redes GSM na faixa dos 900MHz, segundo apresentado na Tabela 2.1. Tal configuração mostra-se a mais apropriada para lidar com os aspectos legais
identificados durante a etapa preparatória do trabalho: Visando transmitir dentro dos limites estabelecidos para as faixas ISM, verifica-se uma pequena sobreposição do espectro
de frequências GSM e o segmento de espectro ISM entre 902 MHz e 928 MHz.
O ARFCN 975 permite ajustar o sistema para transmitir (downlink ) em 925.2MHz,
frequência esta contida na faixa ISM e também reconhecida pelas MSs GSM capazes de
operar na faixa de 900MHz. Não conseguimos transmitir na faixa ISM ao selecionar os
ARFCNs de 1 a 124 (Primary GSM), logo precisamos recorrer ao canal mais baixo da
porção extendida do E-GSM para cair dentro da faixa ISM de downlink.
3.4.2
Clock
Conforme antecipado, a USRP1 originalmente emprega um clock interno de 64MHz
com baixa precisão, ao passo que o sistema GSM precisa trabalhar com frequências clock
múltiplas de 13MHz com alta precisão.
Apesar de ciente das grandes dificuldades impostas para o estabelecimento da rede,
decidiu-se em um primeiro momento manter o clock original da USRP1 visando perder
ainda mais a sinergia com as redes comerciais. Em condições normais de atenuação do
sinal das operadoras coexistentes, a rede criada no presente experimento sequer pode ser
vista pelas MSs já sincronizadas.
- Observação: Caso os testes de vulnerabilidade estivessem sendo realizados em ambiente aberto, encontrar-se-ia na técnica de jamming (PAGET, 2010b) uma das formas
de acelerar a migração de MSs para a rede. Por motivos já citados anteriormente, está
técnica não será sequer cogitada durante a execução dos experimentos.
3.4.3
Identificadores da Rede
Por medida de segurança, sempre que inicializada a rede terá como padrão:
• MCC = 001 (Identificador universal para testes);
• MNC = 01 (Operando em modo de teste);
Qualquer teste diferente disso precisará levar em conta os cuidados descritos no item
seguinte.
3.4.4
Câmara Anecóica - UFABC
A condução responsável de testes que explorem a vulnerabilidade de sistemas de telefonia móvel deve levar em conta a existência de um ambiente controlado e completamente
56
isolado do meio externo. Assegura-se desta forma a criação de um espectro independente
capaz de confinar os efeitos de todo e qualquer experimento ali realizado.
Para tal, conforme Figura 3.5, utilizou-se uma câmara anecóica ETS-Lindgren modelo
H26 para medidas de radiopropagação na faixa de 30MHz à 18GHz, com atenuação in-out
de 110dB, operando em modo semi-anecóico.
Figura 3.5: Testes com USRP1 na câmara anecóica da UFABC
Capı́tulo
4
Análise Técnica por meio de Recursos de
Hardware e Software
4.1
FASE DE INTEGRAÇÃO
Constituindo o primeiro passo da etapa experimental, a integração dos elementos de
rede foi iniciada tendo por objetivo o uso do OpenBTS P2.8 como elemento central, considerando para tal as recomendações e suporte dos desenvolvedores e entusiastas (esforços
incondicionalmente voltados às últimas liberações), correções de eventuais problemas no
software e sinergia com as atualizações dos sistemas operacionais, dependências e bibliotecas.
Conforme apresentado no Apêndice A, esta decisão impôs limitações na escolha da
versão do elemento de integração com o hardware do experimento. Primeiramente, notase que as versões mais recentes do GNU Radio acompanharam a tendência apresentada
pelo próprio fabricante das USRPs ao substituir a interface libusrp1 pelo driver universal UHD. Por outro lado, a interface do OpenBTS P2.8 com a USRP1 somente se dá
através da antiga interface libusrp1. Por este motivo, dentre as opções mencionadas no
Apêndice A, optou-se a princı́pio pela versão 3.3.0 do GNU Radio.
Prosseguindo com as instalações e configurações, verificou-se que o OpenBTS P2.8 é
incapaz de comunicar com a USRP1 sem que o clock original de 64MHz seja substituı́do.
Estruturalmente, observou-se que os códigos desta nova versão deixaram de compilar e
construir o diretório Transceiver, tal como se dava em versões anteriores. Em uma referência direta ao clock de 52MHz abordado anteriormente, nota-se o surgimento de um
substituto intitulado Transceiver52M.
Como última alternativa, tentou-se copiar a antiga estrutura disponibilizada em versões descontinuadas do software, alterando-se os arquivos configure e make do OpenBTS
P2.8 de forma a construir e associar durante a compilação toda a porção responsável pelo
ajuste da taxa de sı́mbolos. Conforme se observa na Figura 4.1, os esforços valeram apenas no sentido de ganhar mais intimidade com os arquivos que constroem o OpenBTS.
57
Capı́tulo 4. Análise Técnica por meio de Recursos de Hardware e Software
58
Em momento algum a rede chegou a se estabelecer.
Figura 4.1: Registro de falhas, OpenBTS P2.8
Devido às questões relacionadas ao clock de rede levantadas ao longo do presente
trabalho, inviabilizou-se a utilização da versão P2.8 do OpenBTS. Como consequência,
exauriram-se também as expectativas com relação à verificação da variante GPRS baseada
no P2.8 (Apêndice D).
Deixando a troca de pacotes GPRS como algo a ser perseguido em trabalhos futuros,
voltou-se o foco especificamente para a implementação da rede GSM. Avaliando porém
outra variante do OpenBTS denominada OSMO (Apêndice D), observou-se que a mesma
também demonstrou não suportar o clock de 64MHz. As subsequentes tentativas de configuração resultaram em problemas que sequer viabilizavam o inı́cio das tentativas de
transmissão, tal como observado na Figura 4.1.
Seguindo o leque de possibilidades, partiu-se para a análise do OpenBTS 2.6.0-Mamou
e sua respectiva variante mantida no repositório de versões descontinuadas do OpenBTS
(Apêndice D). Apesar de conter a estrutura desejada e teoricamente suportar a construção
da interface junto à USRP1 com clock original, incompatibilidades não contornadas no momento da construção impediram o estabelecimento da rede. O erro obtido (segmentation
fault - core dumped) parece estar associado a algum tipo de incompatibilidade com
a versão das dependências instaladas, mudança imprevista nas bibliotecas ou até mesmo
o cruzamento destas com a versão atual do sistema operacional. Infelizmente, dado a
ausência de suporte para versões descontinuadas, nenhuma referência foi encontrada para
auxiliar no contorno de tal entrave.
59
Recorrendo a liberações de software ainda anteriores, o mesmo problema foi observado
ao empregar versões do OpenBTS 2.5.x-Lacassine. Testes realizados em todas as variantes
localizadas (2.5.1 , 2.5.3 e 2.5.4) resultaram no mesmo erro (segmentation fault - core
dumped), fortalecendo a hipótese de incompatibilidade.
Figura 4.2: Tentativas e incompatibilidades observadas durante etapa de integração
Desistindo de retroceder ainda mais, optou-se por avaliar a variante já descontinuada
do OpenBTS denominada OpenBTS-UHD. Baseada na antiga versão 2.6, esta versão não
havia sido priorizada justamente por conter apenas o diretório Transceiver52M (efetivamente, o Transceiver deixou de ser disponibilizado na versão 2.6). Como primeiro
passo, visando a adequação da interface com o hardware, migrou-se a versão do GNU
Radio para a revisão 3.6.5.1 seguido da instalação do software UHD, tal como descrito
nos Apêndices A e B. Conforme visto no capı́tulo 3, o UHD constitui o hardware driver
criado para interagir com todas as USRPs, suportando inclusive a USRP1 em sua configuração original ou com o clock modificado.
Voltando as atenções para as diferenças e semelhanças com relação à versão P2.8,
iniciaram-se os testes com o OpenBTS-UHD explorando principalmente as configurações
disponibilizadas apenas na versão descontinuada do software. A nova série de tentativas
culminou finalmente na resolução da incompatibilidade com a taxa de sı́mbolos imposta
pelo clock original da USRP1 (Apêndice D).
Um último entrave ainda precisou ser removido antes que a rede fosse efetivamente
estabelecida. A Figura 4.3 mostra o relatório de falhas devolvido pelo sistema ao tentar
iniciar a rede.
60
Figura 4.3: Registro de falhas, OpenBTS-UHD
Tal problema se deve a um fato inesperado: Ao contrário do que o próprio nome sugere,
o OpenBTS-UHD não suporta a interface com a USRP1 através do driver UHD, sendo
necessário iniciar um novo processo de compilação desta vez considerando o libusrp1
presente nas liberações anteriores do GNU Radio.
Regredindo novamente ao GNU Radio 3.3.0, pôde-se pela primeira vez estabelecer uma
rede funcional que combinasse o clock de 64MHz com o OpenBTS-UHD. De fato as limitações do clock impuseram considerável atraso na realização dos experimentos práticos,
invadindo os prazos inicialmente estabelecidos a ponto de se aproximar do limite máximo
estabelecido para o programa de Mestrado. Com algumas concessões, felizmente ainda foi
possı́vel restabelecer muitas das análises propostas no capı́tulo anterior.
4.2
FASE DE VERIFICAÇÃO
Uma vez contornadas as dificuldades encontradas durante a etapa de integração,
iniciou-se a fase de verificação das vulnerabilidades previamente descritas no capı́tulo
terceiro. Ao longo do experimento, foram utilizados celulares das seguintes marcas e
modelos:
• Apple iPhone 4S modelo A1387 16GB;
• Motorola A853 Milestone;
• Nokia E63;
• Nokia 3310;
• Samsung Galaxy SIII.
61
Cabe ressaltar que o presente trabalho não possui qualquer intenção de caracterizar o
comportamento de um aparelho frente ao outro. Os aparelhos serviram apenas de instrumento para constatação das vulnerabilidades, e por este motivo, não serão desenvolvidos
comentários a este respeito.
4.2.1
IMSI Catcher
Para as verificações iniciais, ajustou-se o parâmetro GSM.MCC de forma a obter um
MCC igual a 001, sendo este um identificador universal para testes. Da mesma forma,
o parâmetro de rede GSM.MNC foi ajustado em 01, complementando a indicação de
operação em modo de teste. Finalmente, o parâmetro GSM.ShortName foi utilizado
para identificar o nome da rede como sendo OpenBTS.
Primeiramente, digna-se mencionar que a rede realmente não pôde ser vista pelas
MSs já sincronizadas às redes de outras operadoras. Mesmo ao executar uma busca manual pelas redes disponı́veis, as MSs sequer listavam a rede de testes como uma opção.
Confirma-se com isso o estreitamento de varredura previamente apresentado durante as
considerações iniciais sobre o clock de rede.
O experimento do IMSI Catcher valeu-se inicialmente de um celular Nokia 3310 equipado com o SIM card de IMSI 00101 2462443021, sendo este conhecido após processo
de escrita executado com o auxı́lio da ferramenta pySim (Apêndice C). Observa-se que
o MCC e MNC presentes no IMSI conferem com os indicadores da rede, estabelecendo
desta forma um critério de busca preferencial pela rede de testes. Na prática, observou-se
o inı́cio do processo de conexão tão logo a MS foi ligada, seguindo com a obtenção do
IMSI em cleartext conforme indicado na extremidade inferior da Figura 4.4. Verifica-se
que o IMSI reportado confere com o IMSI gravado no SIM card, validando desta forma
uma das hipóteses centrais levantadas no capı́tulo primeiro.
Figura 4.4: Obtenção do IMSI em cleartext
Sem se preocupar a princı́pio com a devida autenticação do usuário (afinal, não se
trata da operadora), a estação prontamente aceita o assinante. Conforme indicado na
Figura 4.5, cria-se um TMSI para ser associado ao IMSI capturado, tal como o comportamento de uma rede comercial.
62
Figura 4.5: Atribuição de TMSI ao IMSI capturado
Incapaz de validar a rede, a MS simplesmente obedece aos comandos da nova BTS.
Uma vez finalizado o processo, configurou-se a MS para mostrar em seu display os identificadores da rede à qual estava conectada. A Figura 4.6 indica que o processo se deu sem
maiores problemas, validando a segunda hipótese central identificada no inı́cio do trabalho: Sem dispor de quaisquer artifı́cios para validar a rede, a MS simplesmente migra para
novas BTSs tendo no máximo a capacidade de discernir entre os diferentes identificadores
disponı́veis. Em outras palavras, sob o ponto de vista das MSs, parte-se do pressuposto
de que todas as redes são autênticas.
Figura 4.6: Leitura dos identificadores de rede através da MS
Torna-se interessante mencionar que, depois de estabelecido o sincronismo com a rede
de testes, tal MS apresentada na Figura 4.6 (composta pelo ME Nokia 3310) não reportou a disponibilidade de outras operadoras após a realização de uma busca manual
pelas redes disponı́veis. No mesmo local, as demais MSs experimentavam o efeito inverso,
atribuindo-se tal comportamento ao clock anteriormente discutido. De fato, sem o recurso
do pySim que possibilitou o estabelecimento de uma conexão preferencial com a rede 001
01, as chances de visualização da rede com clock original da USRP1 seriam drasticamente
reduzidas.
Abstraindo das amarras propositalmente mantidas no experimento, observa-se que o
IMSI spoofing pode ser iniciado tão logo se tenha obtido o IMSI de um usuário. Ignorando
a princı́pio a quebra do Ki, bastaria utilizar novamente a ferramenta pySim para criar outro SIM card com o mesmo IMSI. Visando evitar a configuração de clonagem indevida de
IMSIs, não foram avaliadas as consequências da apresentação simultânea de IMSIs com
63
diferentes respostas (SRES) ao desafio aleatório. Embora trivial, tal investigação deve
apenas ser conduzida em trabalhos futuros caso haja o consentimento de alguma operadora, com a certeza do devido respaldo legal para a execução do experimento.
Como consequência da preocupação exposta no parágrafo anterior, não foram feitas
quaisquer investigações no sentido de protelar o processo de autenticação nem tampouco
submeter a MS ao processo de impersonalização frente à operadora. Especialmente com
relação a este último, a presença de criptoanálise certamente demandaria considerável
esforço adicional em uma linha investigativa à parte.
Considerando a grande atenuação sofrida pelo sinal das operadoras ao adentrar o subsolo da UFABC (onde localiza-se o laboratório de testes, bem como as câmaras anecóicas),
verificou-se a possibilidade de handover de MSs para a rede de testes criada, na medida
em que a mesma ganha relevância em relação ao sinal das redes externas. Interessante
observar que, mesmo tratando-se de uma rede de testes (MCC 001, MNC 01 e nomeada OpenBTS) mantida por um clock de baixa precisão e transmitindo na faixa ISM,
foram constatados casos inesperados de handover de MSs equipadas com SIM cards comerciais, talvez estando na iminência da perda do sinal ou diante da completa ausência
de serviços impostas pelo ambiente confinado do subsolo. A Figura 4.7 mostra a tela de
um iPhone conectado à rede no momento em que a câmara anecóica encontrava-se aberta.
Ao mesmo tempo, a Figura 4.7 também antecipa a confirmação da teoria da porta
dos fundos apresentada no capı́tulo III: Mesmo tecnologias mais modernas de telefonia
celular ainda podem guardar sua compatibilidade com o padrão GSM, carregando como
consequência uma vulnerabilidade eminente que só é eliminada após ação do usuário.
Ameniza-se o fato ao considerar que tal handover tenha ocorrido mediante uma condição
extrema observada no subsolo da UFABC. Em contrapartida, baliza-se a possibilidade de
implantação de técnicas adicionais de ataque como o spoofing de rede ou jamming das
faixas de frequência, as quais haviam não sido empregadas naquele momento.
64
Figura 4.7: Handover inesperado do iPhone
Por sua vez, a Figura 4.8 mostra a configuração tı́pica encontrada em aparelhos celulares 3G, visando tirar proveito da ampla e consolidada área de cobertura GSM. Retrata-se
da mesma forma a possibilidade de desativação destas conexões alternativas, o que poderia
configurar uma solução para assinantes que priorizem a segurança frente à disponibilidade
de serviços (lembrando que a última depende muito da região visitada).
Figura 4.8: Configurações do Galaxy SIII referentes à conexão GSM
65
Seguindo com a análise das vulnerabilidades, confinou-se em definitivo o experimento
para a condução de métodos de ataque mais agressivos. Com 110dB de atenuação,
verificou-se primeiramente o eficaz bloqueio de todo e qualquer sinal produzido dentro
da câmara anecóica. Uma vez certificado este importante ponto, deu-se inı́cio ao spoofing
de redes conforme apresentado no capı́tulo anterior. Com a alteração dos parâmetros de
rede, observou-se a possibilidade de plagiar os identificadores tı́picos das redes convencionais, mascarando definitivamente a rede às MSs. Além de acelerar o handover de MSs
associadas à tal operadora, o spoofing de rede impossibilita a distinção entre redes.
Observa-se na Figura 4.9 a imagem da tela de um celular Galaxy SIII no momento
onde se fazia o spoofing de rede de uma operadora em ambiente controlado. Dado a atenuação imposta pela câmara, nenhuma outra rede pôde ser localizada pelas MSs presentes
no experimento. Por este motivo, seja com SIM cards de uma operadora ou de outra,
todos os aparelhos conectaram à rede em questão sem maiores delongas. Em condições
normais, espera-se que as MSs busquem conexão tipicamente com suas redes preferenciais.
Sob o ponto de vista das MSs, especialmente em relação àquelas conectadas à sua rede
preferencial, nenhum fenômeno anormal está ocorrendo. Para todos os efeitos, o que se
observa é uma rede de sua operadora sendo apresentada com boa intensidade por uma
BTS GSM. Jamais se desconfia que a MS esteja na verdade sendo vı́tima de um spoofing.
Caso alguém tente ligar para um usuário nestas condições, constatou-se que a chamada
será direcionada para a caixa postal. De fato, aos olhos da operadora, a MS encontra-se
desligada ou fora da área de serviço. De igual maneira, eventuais tentativas de iniciar uma
chamada também fracassarão, salvo se algum esforço adicional for realizado no sentido de
impersonalizar uma triangulação. Descrevem-se desta forma as condições para o ataque
DoS introduzido no capı́tulo anterior.
Apesar de não correlacionar o IMSI ao usuário propriamente dito nem tampouco dizer
a localização precisa do mesmo, confirma-se a capacidade de delimitar e monitorar a
presença de assinantes dentro da área de cobertura estabelecida. Dado o confinamento
do experimento, não se realizou a tentativa de correlacionar determinado usuário a seu
IMSI através de um scanner móvel. Em teoria, criam-se as condições para que, ao seguir
o deslocamento de uma MS especı́fica, verifique-se a entrada de novos IMSIs e a saı́da dos
antigos, restando apenas o IMSI alvo.
66
####
Nota: #### para privacidade da
operadora local.
Figura 4.9: Spoofing de rede em ambiente controlado (câmara anecóica)
Dados os atrasos impostos pela questão do clock, não foi possı́vel preparar os ataques
de impersonalização para chamadas originadas pelo usuário. Ao contrário da impersonalização completa envolvendo a quebra do Ki, tal método estava previsto no escopo prático
como forma de comprovar a última hipótese central faltante: a possibilidade de negociar o
A5/0 e consequentemente eliminar o entrave da criptografia entre MS e BTS. A constatação de uma chamada telefônica seguida de sua reprodução constituiria prova irrefutável,
mesmo diante das evidências apresentadas no capı́tulo anterior que apontam a necessidade
de passos adicionais para habilitar qualquer tipo de criptografia através do OpenBTS. De
forma menos expressiva, demonstra-se a capacidade do sistema em concretizar a troca
inteligı́vel de dados através do envio de SMSs, partindo do OpenBTS para cada MS, de
forma individual e personalizada (uma mensagem diferente endereçada para cada IMSI).
A Figura 4.10 indica o comando utilizado no OpenBTS, bem como o texto selecionado
e o IMSI de destino.
Figura 4.10: Envio de SMS através do OpenBTS-UHD
Nas MSs, observou-se o pronto recebimento da mensagem e seu conteúdo original,
conforme mostra a Figura 4.11.
67
Figura 4.11: Recebimento do SMS transmitido
Do capitulo 2, sabe-se que que os dados na interface Um (transmitidos tanto em TCH
quanto em DCCH, como no caso dos SMSs) sofrem o processo de encriptação após a
autenticação da MS na rede. Para cada frame enviado na interface Um, uma diferente
combinação de Kc e FN constitui o chamado keystream utilizado para encriptar/decriptar
os dados. Sabe-se também que a obtenção da chave Kc se dá de forma indireta na MS
ao combinar o conteúdo do RAND com o Ki armazenado no SIM card. Do outro lado da
interface Um, a BTS recebe Kc do MSC, que por sua vez obteve a informação através dos
triples do HLR. Tomando em consideração que o presente trabalho não lançou mão da
quebra do Ki em momento algum (reconhecidamente um processo trabalhoso), verifica-se
a impossibilidade de reconstituição de dados na outra extremidade (diga-se, de forma inteligı́vel e precisa) a menos que o algoritmo criptográfico negociado durante o Ciphering
Mode Settings tenha sido o efetivamente A5/0.
68
Capı́tulo
5
Conclusões e Perspectivas Futuras
Concebido para ser seguro e confiável, o sistema de telefonia móvel de segunda geração conhecido como GSM teve com o passar dos anos sucessivas fragilidades identificadas.
Tendo sua contemporaneidade assegurada através da associação com o GPRS, o sistema
ainda vigora entre as diversas frentes de serviço da atualidade, tais como transações financeiras, rastreamento veicular e até mesmo conexão alternativa para aparelhos celulares de
terceira geração.
Através da análise de vulnerabilidades dos sistemas GSM/GPRS por meio de recursos
complementares de hardware e software, o presente trabalho se dispôs a iniciar uma frente
de pesquisa prática e investigativa de aspectos relacionados à segurança dos sistemas
sob a ótica da atualidade. Longe de abordar toda a gama de possı́veis desdobramentos,
tal análise priorizou a execução de ataques com grande valor conceitual, essencialmente
construı́dos através da exploração de lacunas e vulnerabilidades identificadas ao longo do
trabalho.
Especialmente nos dias de hoje em que a espionagem e quebra indevida de privacidade se tornam assunto de grande relevância em âmbito nacional, reforça-se a pertinência
desta frente de pesquisa consideravelmente menos explorada que a segurança em outros
meios, tal como a Internet. O conhecimento das vulnerabilidades, técnicas de ataque e
possı́veis desdobramentos (associados às mais diversas aplicações que utilizam o GSM/GPRS) trazem à tona uma importante linha investigativa já debatida no exterior, de caráter
responsável e bem intencionada, assegurando ao Brasil a manutenção da soberania nesta
importante área do conhecimento.
Pouco conclusivos seriam os resultados obtidos por meio exclusivamente virtual, e
por esta razão, priorizou-se a abordagem prática do tema. Partindo do aprofundamento
conceitual necessário para compreender os sistemas, identificar a melhor configuração do
experimento e os principais aspectos para verificação, precisou-se também enquadrar no
cronograma de Mestrado itens como a obtenção do hardware, familiarização com diferentes softwares envolvidos e finalmente a devida integração de todo o experimento. Ao
mesmo tempo, foram considerados aspectos legais e social visando evitar interferências
69
Capı́tulo 5. Conclusões e Perspectivas Futuras
70
com os sistemas comerciais, bem como a disponibilidade de serviços e a preservação dos
dados de usuários móveis.
5.1
CONSTATAÇÕES E CONCLUSÕES
Por estar diretamente associado à privacidade do assinante, define-se que a transmissão do IMSI pela rede deve ser evitada a todo custo. Visando descaracterizar o usuário,
atribui-se ao assinante uma nova entidade temporária denominada TMSI, cuja eficácia
parte do pressuposto que o IMSI não será transmitido ordinariamente. Valendo-se das
brechas previstas no próprio padrão, observou-se a possibilidade de obter o IMSI das
MSs em cleartext, comprovando a primeira hipótese apresentada no capı́tulo 1. Mais do
que uma simples quebra da descaracterização imposta pelo TMSI, tal passo mostrou-se o
ponto de inı́cio para uma série de novos ataques.
Sob o ponto de vista da transmissão de dados, verifica-se a utilização de algoritmoscifra de encriptação (pertencentes à famı́lia A5) para proteção dos dados transmitidos
através da interface Um. Para cada frame enviado, uma diferente combinação de Kc e
FN constitui o chamado keystream utilizado para encriptar/decriptar os dados, sendo Kc
a chave de seção derivada a partir da chave secreta Ki armazenada apenas no SIM card
e no AuC. Tendo porém a possibilidade de selecionar o A5/0 (cleartext) como uma opção válida de algoritmo criptográfico, verifica-se a possibilidade de interagir com as MSs
mesmo desconhecendo o valor do Ki presente nos SIM cards. Através do envio de SMSs
oriundos de uma estação falsa, observou-se o devido recebimento e reconstituição do conteúdo originalmente encaminhado, comprovando a hipótese de troca de dados inteligı́vel
ponto a ponto sem empregar técnicas de ataques ao Ki.
Essencialmente, consegue-se explorar estas e outras vulnerabilidades devido à constatação da terceira e última hipótese fundamental do trabalho. No tocante ao processo de
autenticação, verificou-se que o padrão apenas prevê que a MS seja autenticada perante
a rede. Sem que existam mecanismos reais de autenticação de uma rede perante a MS, os
identificadores de rede constituem a única possibilidade de filtro disponı́vel.
Através da condução de experimentos em ambiente controlado, caracterizou-se a possibilidade de plagiar os identificadores tı́picos das redes convencionais, mascarando este
último recurso disponı́vel e consequentemente eliminando qualquer entrave remanescente
para a prática do chamado spoofing de rede.
De igual maneira, verificou-se a possibilidade de praticar o spoofing de IMSIs perante
a rede das operadoras tão logo se tenha obtido o IMSI dos assinantes. Diferentes desdobramentos foram apresentados no capı́tulo 3, ao passo que o capı́tulo quarto apresenta os
motivos da suspensão de tal prática no presente experimento. Se por um lado recomendase a obtenção do comum acordo com as operadoras antes de seguir adiante, por outro
lado verifica-se a completa ausência de representatividade em executar o spoofing de IM-
71
SIs através de uma rede de testes. Tendo em vista estas questões, constatou-se apenas a
possibilidade iminente da prática de tal técnica.
Especialmente em relação às MSs conectadas a uma rede falsa sob efeito da técnica de
spoofing, verificou-se a implantação do ataque DoS em toda a sua plenitude, impedindo
que as MSs originassem ou recebessem qualquer chamada ou troca de dados com sua rede
original. Sem qualquer capacidade de discernimento, as MSs do experimento simplesmente migraram e permaneceram conectadas à rede criada dentro da câmara anecóica.
Caso nenhum esforço adicional seja empregado na rede falsa visando à conectividade deste
usuário, criam-se as condições necessárias para executar um ataque do tipo DoS. Tanto
para sistemas de telefonia móvel quanto para suas variantes (como o rastreamento veicular, telemetria, etc), verifica-se a grande pertinência dos efeitos causados pela privação
de serviços (sob o ponto de vista do usuário) e visibilidade do assinante (sob o ponto de
vista da operadora).
Valendo-se da ausência de autenticação das redes perante as MSs, as falsas BTSs conhecidas como IMSI Catchers exploram a busca constante das MSs por melhores sinais,
criando através da interface Um uma estrutura convidativa que apresente melhores condições competitivas frente às demais redes comercialmente oferecidas pelas operadoras
cadastradas. Apesar de não conseguir definir a posição exata do usuário arrebanhado,
verifica-se a possibilidade de delimitar sua presença dentro da área de cobertura estabelecida. Extrapolando esta caracterı́stica a uma eventual perseguição do alvo desejado,
rascunhou-se a possibilidade de correlacionar o IMSI com sua respectiva MS, seja ela um
carro, um telefone ou qualquer outro alvo. Embora não seja difı́cil planejar sua execução
(visando a comprovação da teoria), tal ataque não foi efetivado por demandar o spoofing
de redes em ambiente aberto.
Verificou-se também que mesmo tecnologias mais modernas de telefonia celular ainda
podem guardar a compatibilidade com o padrão GSM, sendo este utilizado como método alternativo de conectividade. Tal caracterı́stica justifica-se ao considerar a ampla e
consolidada área de cobertura GSM, não apenas uma realidade no Brasil, mas em todo
o mundo. A menos que seja desativada pelo usuário, tal compatibilidade constitui um
atalho para eventuais ataques que não se disponham a quebrar os modelos de segurança
dos padrões mais recentes.
5.2
RECOMENDAÇÕES PARA TRABALHOS FUTUROS
Objetivando a continuidade desta linha investigativa, recomenda-se primeiramente a
adoção de um clock de 52MHz de forma a evitar os problemas de visualização de rede
(sentidos ao confirmar a teoria de estreitamento de varredura), evitar as limitações de software impostas pela conversão da taxa de sı́mbolos e conjecturando quanto ao contorno de
72
eventuais instabilidades durante chamadas de maior duração por questões relacionadas à
imprecisão.
Apesar de caracterizar-se por uma arquitetura sobreposta à rede GSM e utilizar a
mesma BTS como meio de acesso às MSs, torna-se justo observar que, dado os problemas
com o clock relacionados anteriormente, não foi possı́vel desenvolver qualquer verificação
prática direcionada especificamente ao GPRS. Como as vulnerabilidades exploradas no
capı́tulo 4 estão intrinsecamente relacionadas ao GSM, recomenda-se a condução de experimentos práticos complementares visando a devida retratação dos aspectos de segurança
inerentes ao GPRS.
Como grande perda do que fora inicialmente planejado, menciona-se a falta de tempo
para concretizar a impersonalização das chamadas originadas pelos usuários. Com um
grande apelo expositivo (uma vez já comprovadas as três hipóteses centrais), complementarse-ia o experimento com a evidência de que chamadas originadas pelas vı́timas podem ser
monitoradas pelo agente MITM. Justamente por dispensar a utilização de técnicas de
criptoanálise, considera-se esta verificação como sendo uma sequência natural do trabalho. Para tal, recomenda-se o devido preparo da câmara anecóica com ponto de acesso à
Internet, bem como a utilização do novo elemento de software denominado Wireshark.
A própria criptoanálise constitui vertente relacionada, porém quase independente de
investigação. Envolvendo diferentes conhecimentos e técnicas, trata-se de uma ampliação
do atual escopo, que em sua essência buscou contornar o modelo de segurança ao invés de
encará-lo de frente em sua face mais protegida. Por outro lado, a coexistência de ambas
as frentes configuraria algo de extremo interesse, guardando-se os devidos limites legais.
No tocante aos aspectos legais, torna-se importante uma aproximação junto aos órgãos
reguladores e operadoras de telefonia móvel de forma a assegurar o máximo proveito e
alinhamento de interesses.
Por fim, partindo da última liberação de software disponı́vel, recomenda-se a capacitação de alunos quanto ao desenvolvimento de novas linhas de código que possibilitem,
dentre outras coisas, a obtenção do IMEI mencionada ao longo do presente trabalho.
Bibliografia
ALMEIDA, I. Estudo de viabilidade e implementação de sistema de comunicação
GSM utilizando projetos open-source e open-hardware. Dissertação (Mestrado) —
Universidade Federal do Pará, Belém, Pará, 2010.
ANATEL. Regulamento para Certificação e Homologação de Produtos para
Telecomunicações. Novembro 2000. Resolução N.242.
. Regulamento de Uso do Espectro de Radiofrequências. Abril 2001. Anexo à
Resolução N.259.
. Atribuição de Faixas de Frequência no Brasil. 2006. Disponı́vel em:
http://www.anatel.gov.br/Portal/verificaDocumentos/documento.asp?
numeroPublicacao=98580&assuntoPublicacao=Quadro%20de%20Atribui%E7%E3o%
20&caminhoRel=null&filtro=1&documentoPath=radiofrequencia/qaff.pdf. Acesso
em: 23 de dezembro de 2013.
. Regulamento Sobre Condições de Uso de Radiofreqüências nas Faixas de 800MHz,
900MHz, 1.800MHz, 1.900MHz E 2.100MHz. Dezembro 2006. Anexo à Resolução N.454.
. Orientações para Homologação de Produtos Destinados aos Serviços de
Radioamador, de Radio Do Cidadão, Móvel Marı́timo e Móvel Aeronáutico. Maio 2007.
. Regulamento sobre Autorização de Uso Temporário de Radiofreqüências. Janeiro
2007. Anexo à Resolução N.457.
. Regulamento sobre Equipamentos de Radiocomunicação de Radiação Restrita.
Julho 2008. Resolução N.506.
. Instruções Para Homologar Produtos Por Declaração De Conformidade Com
Relatório De Ensaio. Abril 2013.
. Principais Inovações Ocorridas em Função da Aprovação do Novo Regulamento
para Certificação e Homologação de Produtos para Telecomunicações. Abril 2013.
. Procedimento Para Requerimento De Homologação De Produtos Para
Telecomunicações. Abril 2013.
73
Bibliografia
74
. Uso de radiofrequência. 2013. Disponı́vel em: http://www.anatel.gov.br/
Portal/exibirPortalNivelDois.do?acao=&codItemCanal=1029&codi. Acesso em: 23
de dezembro de 2013.
APVRILLE, A. An OpenBTS GSM replication jail for mobile malware. In:
Virus Bulletin Conference. Barcelona, Spain: [s.n.], 2011. Disponı́vel em: http:
//www.virusbtn.com/conference/vb2011/abstracts/Apvrille.xml. Acesso em: 23
APVRILLE, A.; FORTINET. OpenBTS for dummies. Janeiro 2013. Helsinki University
of Technology. Disponı́vel em: gnuradio.org/redmine/attachments/420/fordummies.
pdf?. Acesso em: 23 de dezembro de 2013.
BIHAM, E.; DUNKELMAN, O. Cryptanalysis of the A5/1 GSM stream cipher. Progress
in Cryptology, p. 43–51.
BIRYUKOV, A.; SHAMIR, A.; WAGNER, D. Real time cryptanalysis of A5/1 on a pc.
Advances in Cryptology, proceedings of Fast Software Encryption 00, v. 1978, p. 1–18,
2001.
BLUM, J. [U SRP − users] Test ./usrp benchmark usb.py in Ubuntu 12.04. 2012.
Disponı́vel em: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/
2012-December/005935.html. Acesso em: 23 de dezembro de 2013.
BRICENO, M. A pedagogical implementation of the GSM A5/1 and A5/2 voice privacy
encryption algorithms. 2008.
BURGESS, D.; SAMRA, H. The Open BTS Project. [S.l.], 2008.
CABRAL, M. et al. Low-cost GSM telephony in the Amazon region based on
open-source/open-hardware projects. In: IEEE Latin-American Conference on
Communications. Medellı́n, Colombia: [s.n.], 2009.
CASELLA, I. EEL-108, Sensores e Dispositivos de Comunicação sem Fio. 2012. Material
de Aula.
CLAROCHIP. Senhas de Segurança. 2012. Miniguia Claro.
COIMBRA, T. R. Regulação do Espectro de Radiofreqüências: Análise Técnica do
Modelo Brasileiro. Novembro 2006.
CONTRAN. Instalação de equipamento obrigatório, denominado antifurto, nos veı́culos
novos veı́culos saı́dos de fábrica, nacionais e estrangeiros. Julho 2007. Resolução N.245.
CRYPTOME. GSM A5 Files Published on Cryptome and Elsewhere. 2010. Disponı́vel
em: http://cryptome.org/0001/gsm-a5-files.htm. Acesso em: 23 de dezembro de
2013.
EKDAHL, P.; JOHANSSON, T. Another attack on A5/1. Transactions Information
Theory, p. 284–289, 2003.
Bibliografia
75
ERIKSSON, M. Security in Unlicensed Mobile Access. Dissertação (Mestrado) —
Linkopings Universitet, Sweden, 2005.
ETSI. GSM 03.03 (ETS 300 523): Digital cellular telecommunication system(Phase
2);Numbering, addressing and identification. [S.l.], 1996. Disponı́vel em: http://www.
etsi.org/deliver/etsi_i_ets/300500_300599/300523/01_60/ets_300523e01p.pdf.
Acesso em: 23 de dezembro de 2013.
. GSM 03.20 (ETS 300 534): Digital cellular telecommunications system(Phase 2);
Security related network functions. [S.l.], 1996. Disponı́vel em: http://www.etsi.org/
deliver/etsi_i_ets/300500_300599/300534/01_60/ets_300534e01p.pdf. Acesso
. GSM 04.08 (ETS 300 557): Digital cellular telecommunications system(Phase
2); Mobile radio interface layer 3 specification. [S.l.], 1996. Disponı́vel em: http://www.
etsi.org/deliver/etsi_i_ets/300500_300599/300557/07_60/ets_300557e07p.pdf.
. GSM 05.01 (ETS 300 573): Digital cellular telecommunication system(Phase
2); Physical layer on the radio path General description. [S.l.], 1996. Disponı́vel em:
http://www.etsi.org/deliver/etsi_i_ets/300500_300599/300573/03_60/ets_
300573e03p.pdf. Acesso em: 23 de dezembro de 2013.
. GSM 05.02 (ETS 300 574): Digital cellular telecommunication system (Phase
2); Multiplexing and multiple access on the radio path. [S.l.], 1996. Disponı́vel em:
http://www.etsi.org/deliver/etsi_i_ets/300500_300599/300574/05_60/ets_
300574e05p.pdf. Acesso em: 23 de dezembro de 2013.
. GSM 05.05:(ETS 300 577): Digital cellular telecommunication system(Phase 2);
Radio Transmission and Reception. [S.l.], 1996. Disponı́vel em: http://www.etsi.org/
. GSM 05.10 (ETS 300 579): Digital cellular telecommunication system(Phase 2);
Radio subsystem synchronisation. [S.l.], 1996. Disponı́vel em: http://www.etsi.org/
. 2013. Disponı́vel em: http://www.etsi.org/. Acesso em: 23 de dezembro de
2013.
ETTUS RESEARCH. Building UHD Software from Source. Disponı́vel em: http:
//ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki/UHD_Build.
. Power Supply. Disponı́vel em: https://www.ettus.com/product/details/
PowerSupply. Acesso em: 23 de dezembro de 2013.
Bibliografia
76
. UHD - USRP1 Application Notes. Disponı́vel em: http://files.ettus.com/
uhd_docs/manual/html/usrp1.html. Acesso em: 23 de dezembro de 2013.
. USRP Hardware Driver software (UHD). Disponı́vel em: http://code.ettus.
com/redmine/ettus/projects/uhd/wiki. Acesso em: 23 de dezembro de 2013.
GNU RADIO. Boost Dependency. Disponı́vel em: http://gnuradio.org/redmine/
projects/gnuradio/wiki/BuildGuide#Boost-Dependency. Acesso em: 23 de dezembro
de 2013.
. Building GNU Radio on Ubuntu Linux. Disponı́vel em: http://gnuradio.org/
redmine/projects/gnuradio/wiki/UbuntuInstall. Acesso em: 23 de dezembro de
2013.
. Installing GNU Radio. Disponı́vel em: http://gnuradio.org/redmine/
projects/gnuradio/wiki/InstallingGR. Acesso em: 23 de dezembro de 2013.
. OpenBTS: UHD Devices. Disponı́vel em: http://gnuradio.org/redmine/
projects/gnuradio/wiki/OpenBTSUHD. Acesso em: 23 de dezembro de 2013.
. Setup udev for the usrp. Disponı́vel em: http://gnuradio.org/redmine/
projects/gnuradio/wiki/UdevConfig. Acesso em: 23 de dezembro de 2013.
. A Short Guide to Using Libusrp(2) with GNU Radio 3.5.0 and up. Disponı́vel
em: http://gnuradio.org/redmine/projects/gnuradio/wiki/UsingLibusrpWith3_
5?version=3. Acesso em: 23 de dezembro de 2013.
. USRP Clocking Notes. Disponı́vel em: http://gnuradio.org/redmine/
projects/gnuradio/wiki/USRPClockingNotes. Acesso em: 23 de dezembro de 2013.
GOLDBERG, I.; WAGNER, D.; GREEN, L. The Real-Time cryptanalysis of A5/2.
Rump Session of Crypto 99, 1999. Disponı́vel em: www.cs.berkeley.edu/~daw/tmp/
a52-slides.ps. Acesso em: 23 de dezembro de 2013.
GOLIC, J. Cryptanalysis of alleged A5 stream cipher. Advances in Cryptology, v. 1233.
HACKING PROJECTS. Secrets of the SIM. Acesso em: 23 de dezembro de 2013 2013.
Site www.hackingprojects.net. Disponı́vel em: <http://www.hackingprojects.net/2013/04/secrets-of-sim.html>.
ISO/IEC. 7816-x: Identification cards - Integrated circuit cards. 2013.
KAHABKA, M. Pocket Guide for Fundamentals and GSM Testing. 2004. Disponı́vel
em: http://web.itu.edu.tr/~pazarci/WandelGoltermann_gsm.pdf. Acesso em: 23
LAPS-UFPA. Knowledge Base. Disponı́vel em: https://www.laps.ufpa.br/redmine/
projects/knowledgebase/wiki/LOCCUS. Acesso em: 23 de dezembro de 2013.
Bibliografia
77
. Laps-gnuradio. Disponı́vel em: https://www.laps.ufpa.br/redmine/projects/
knowledgebase/wiki/laps-gnuradio. Acesso em: 23 de dezembro de 2013.
. Laps-gnuradio. Disponı́vel em: https://www.laps.ufpa.br/redmine/projects/
knowledgebase/wiki/Instalando_Gnuradio_33. Acesso em: 23 de dezembro de 2013.
LLC. ppm Calculator. 2013. Disponı́vel em: http://www.jittertime.com/resources/
ppmcalc.shtml. Acesso em: 9 de abril de 2013.
LOULA, A. Open BTS Installation and Configuration Guide. 2009. Disponı́vel em:
gnuradio.org/redmine/attachments/139/OpenBTS_Guide_En_v0.1.pdf?. Acesso em:
23 de dezembro de 2013.
MADSEN, L.; MEGGELEN, J. V.; BRYANT, R. Asterisk: The Definitive Guide. n/a.
3rd Edition for Asterisk 1.8. Disponı́vel em: http://www.asteriskdocs.org/en/3rd_
Edition/asterisk-book-html-chunk/Installing_id292827.html. Acesso em: 23 de
dezembro de 2013.
MEGGELEN, J.; MADSEN, L.; SMITH, J. Asterisk, The Future of the Telephony. 2nd
edition. ed. [S.l.: s.n.].
MEYER, U.; WETZEL, S. On the impact of GSM encryption and man-in-the-middle
attacks on the security of interoperating GSM/UMTS networks. In: Proc. IEEE 15th
International Symposium on Personal, Indoor and Mobile Radio Communications
(PIMRC). Barcelona, Spain: [s.n.], 2004. p. 2876–2883.
NATALIZIO, E. et al. The practical experience of implementing a GSM BTS through
open software/hardware. In: 3rd Int. Symposium Applied Sciences in Biomedical and
Communication Technologies (ISABEL). Rome, Italy: [s.n.], 2010.
OLAWSKI, M. Security in the GSM network. 2011.
OPENBTS. About BTS Clocks. Disponı́vel em: http://wush.net/trac/rangepublic/
wiki/Clocks. Acesso em: 9 de abril de 2013.
. Adding Authentication and Encryption to the Public Release. Disponı́vel em:
http://wush.net/trac/rangepublic/wiki/A3A8A5. Acesso em: 23 de dezembro de
2013.
. Building, Installing and Running OpenBTS. Disponı́vel em: http://www.wush.
net/trac/rangepublic/wiki/BuildInstallRun. Acesso em: 23 de dezembro de 2013.
. Welcome to the OpenBTS Public Release. Disponı́vel em: http://wush.net/
trac/rangepublic/. Acesso em: 23 de dezembro de 2013.
. What is OpenBTS? Disponı́vel em: http://openbts.org/. Acesso em: 23 de
dezembro de 2013.
OSMOCOM. A5/x Crypto support. Disponı́vel em: http://openbsc.osmocom.org/
trac/wiki/OpenBSC_Crypto. Acesso em: 23 de dezembro de 2013.
Bibliografia
78
. Open source mobile communications. Disponı́vel em: http://osmocom.org/.
. A python tool to program magic SIMs. Disponı́vel em: http://cgit.osmocom.
org/pysim/tree/pySim/cards.py?id=2c0ff3a1677a232f2617b5aba1a1002f16e7c7d3.
PAGET, C. Gsm cell phone interception. In: RSA Security Conference. San Francisco,
USA: [s.n.], 2010.
. Practical Cellphone Spying. jul 2010. DEF CON 18, Las Vegas.
PERKOV, L.; KLISURA, A.; PAVKOVIé, N. Recent advances in GSM insecurities. In:
Proceedings of the 34th International Convention MIPRO. Opatija, Croatia: [s.n.], 2011.
PESONEN, L. GSM Interception. nov 1999. Helsinki University of Technology.
Disponı́vel em: http://www.tml.tkk.fi/Opinnot/Tik-110.501/1999/papers/
gsminterception/netsec.html. Acesso em: 23 de dezembro de 2013.
PRASAD, P. 3 Dimensional Security in Cloud Computing. 2011. IEEE Computer
Research and Development (ICCRD), 3rd International Conference.
SERVERFAULT. Customizing BackTrack for USRP. 2013.
Disponı́vel em: http://www.serverfault.sk/2013/07/
customizing-backtrack-for-usrp-old-unfinished-notes/. Acesso em: 23 de
dezembro de 2013.
SILVA, A. Tutorial 1: Instalação do GNU Radio Passo a Passo. 2013.
S.PETROVIC; FUSTER-SABATER, A. Cryptanalysis of the A5/2 algorithm. Cryptology
ePrint Archive, n. Report 200/052, 2000.
SPK. GSM850/E-GSM900/DCS1800/PCS1900 Helical Antenna. [S.l.], na.
STEPANOV, M. GSM Security Overview. na. Disponı́vel em: www.cs.huji.ac.il.
Acesso em: 7 de Outubro de 2013.
STROBEL, D. IMSI Catcher. [S.l.], 2007.
TSOU, T. OpenBTS USRP2 support. 2010. Disponı́vel em: http://ttsou.github.io/
openbts-uhd/usrp2_announce.html. Acesso em: 23 de dezembro de 2013.
TUDE, E. Certificação e Homologação de Produtos para Telecomunicações. Outubro
2003.
. Regulamentação para Uso de Frequências no Brasil. Novembro 2003. Site
www.teleco.com.br.
. Quando não é necessário autorização para uso de Frequências no Brasil. Janeiro
2004. Site www.teleco.com.br.
Bibliografia
79
UBUNTU. Ubuntu. 2013. Disponı́vel em: http://www.ubuntu.com/about. Acesso em:
23 de dezembro de 2013.
UNIVERSITY OF MORATUWA. GPRS. Acesso em: 23 de dezembro de 2013 a.
Disponı́vel em: <http://www.ent.mrt.ac.lk/˜040158/index files/Page435.htm>.
USHA COMMUNICATIONS TECHNOLOGY. GPRS General Packet Radio Service.
june 2000. White Paper.
VOIP-INFO. Decoding GSM. 2011. Disponı́vel em: http://www.diva-portal.org/
smash/get/diva2:355716/FULLTEXT01.pdf. Acesso em: 23 de dezembro de 2013.
. MixMonitor. 2011. Disponı́vel em: http://www.voip-info.org/wiki/view/
MixMonitor. Acesso em: 23 de dezembro de 2013.
WEINMANN, R.-P. The Baseband Apocalypse. Dezembro 2010. 27th Chaos
Communication Congress.
WEINMANN, R.-P. Baseband Attacks: Remote Exploitation of Memory Corruptions
in Cellular Protocol Stacks. Dissertação (Mestrado) — University of Luxembourg,
Luxembourg, 2010.
XENAKIS, C. et al. A qualitative risk analysis for the GPRS technology. In: IEEE/IFIP
Int. Conf. Embedded and Ubiquitous Computing, EUC ’08. Shanghai, China: [s.n.], 2008.
XENAKIS, C.; L.MERAKOS. On demand network-wide VPN deployment in GPRS.
IEEE Network, p. 28–37, Dec, 2002.
Bibliografia
80
Apêndice
A
Tutorial de Instalação e Configuração - GNU
Radio
A.1
Introdução
O presente artefato constitui o tutorial de instalação e configuração do GNU Radio,
ferramenta gratuita para desenvolvimento de projetos de sistemas de rádio que visa a
máxima transferência de complexidade do hardware para o software. Ao fazer com que
o software fique o mais próximo possı́vel da antena, o GNU Radio permite minimizar a
complexidade e os custos do hardware necessário para criação de um sistema de rádio.
Conforme apresentado em LAPS-UFPA, as versões mais recentes do GNU Radio passaram a utilizar o driver universal UHD, descontinuando o libusrp1 necessário para comunicar com a USRP1 na atual versão do OpenBTS, intitulada P2.8. Desta forma, visando
possibilitar a integração entre USRP1 e o OpenBTS de maneira irrestrita (ou seja, independente da versão de OpenBTS selecionada), torna-se importante a adoção de critérios
na seleção do GNU Radio a ser utilizado. Opções válidas iniciam-se a partir da versão
3.3.0 , contanto que sejam anteriores à liberação 3.5.0 (APVRILLE; FORTINET, 2013; GNU
RADIO, f). Neste tutorial encontram-se descritos todos os passos necessários para instalar
corretamente a versão 3.3.0 do GNU Radio, considerando um sistema operacional Ubuntu
12.04 recém-instalado.
OBS: Caso a intenção fosse apenas trabalhar com o GNU Radio sem integração com o
OpenBTS, poder-se-ia apenas entrar com a linha de comando (GNU RADIO, c) descrita no
quadro abaixo. Para tal, inicia-se uma seção do Terminal Ubuntu ao digitar ctrl + alt + T :
$ wget h t tp : / /www. s b r a c . o r g / f i l e s / b u i l d −g n u r a d i o && chmod a+x
. / b u i l d −g n u r a d i o && . / b u i l d −g n u r a d i o
Após este comando, todos os passos são executados automaticamente, desde as instalações das dependências até a última versão do GNU Radio. Por outro lado, conforme
descrito anteriormente, esta versão não opera em conjunto com o OpenBTS P2.8. Segundo
81
Apêndice A. Tutorial de Instalação e Configuração - GNU Radio
82
LAPS-UFPA,
uma possı́vel alternativa seria a adoção do OpenBTS-UHD, uma variante baseada na antiga versão 2.6 do OpenBTS. Em contrapartida (GNU RADIO, d), recomenda-se
a migração direta para a versão P2.8 uma vez que o OpenBTS-UHD e todos as variantes baseadas nas versão 2.6 foram descontinuadas e não são mais mantidas pelo projeto
OpenBTS.
Retomando a instalação do GNU Radio 3.3.0, segue abaixo a sequência proposta
por LOULA, com algumas adaptações e atualizações que se fazem necessárias.
A.2
Instalação das dependências
Considerando que o trabalho está sendo desenvolvido em UBUNTU 12.04 (Precise
Pangolin), inicia-se esta etapa descarregando as linhas de comando abaixo no Terminal (GNU RADIO, b):
$ sudo apt−g e t −y i n s t a l l g i t −c o r e a u t o c o n f automake l i b t o o l
g++ python−dev swig pkg−c o n f i g l i b b o o s t 1 .48 − a l l −dev
l i b f f t w 3 −dev l i b c p p u n i t −dev l i b g s l 0 −dev l i b u s b −dev s d c c
l i b s d l 1 .2− dev python−wxgtk2 . 8 python−numpy python−c h e e t a h
python−lxml doxygen python−qt4 python−qwt5−qt4 l i b x i −dev
l i b q t 4 −opengl−dev l i b q w t 5 −qt4−dev l i b f o n t c o n f i g 1 −dev
l i b x r e n d e r −dev
Após algumas tentativas frustradas de instalação de versões anteriores do GNU Radio, foram consideradas algumas dependências adicionais às recomendadas para o Ubuntu
12.04. Após considerá-las, a instalação foi efetivada com sucesso.
Primeiramente, adicionam-se as dependências (SILVA, 2013):
$ sudo apt−g e t −y i n s t a l l l i b p u l s e −dev f o r t 7 7 sdcc−l i b r a r i e s
g u i l e −1.8−dev l i b q t 4 −dev pyqt4−dev−t o o l s c c a c h e python−o p e n g l
qt4−dev−t o o l s l i b q w t p l o t 3 d −qt4−dev
Consideram-se também (LOULA, 2009):
$ sudo apt−g e t −y i n s t a l l automake1 . 9 l i b a s o u n d 2 −dev
subversion
Finalmente, complementa-se esta etapa de instalação com as dependências mencionadas abaixo (LAPS-UFPA, b):
$ sudo apt−g e t −y i n s t a l l o c t a v e g u i l e −2.0 l i b q w t p l o t 3 d −doc
l i b q w t p l o t 3 d −qt4 −0 python−m a t p l o t l i b
A.3
83
Instalação das bibliotecas boost
O GNU Radio requer no mı́nimo a versão 1.35 de boost para funcionar (LOULA, 2009;
GNU RADIO, a):
$ wget h t tp : / / kent . d l . s o u r c e f o r g e . n e t / s o u r c e f o r g e / b o o s t / b o o s t
1 3 7 0 . t a r . gz
$ t a r x v z f b o o s t 1 3 7 0 . t a r . gz
$ cd b o o s t 1 3 7 0
$ BOOST PREFIX=/opt / b o o s t 1 3 7 0
$ . / c o n f i g u r e −−p r e f i x=$BOOST PREFIX −−with−l i b r a r i e s=thread ,
date time , program options
$ make
$ sudo make i n s t a l l
A.4
Edição dos paths
Nesta etapa, recomenda-se (LAPS-UFPA, b; LAPS-UFPA, c) a configuração do PATH.
Segundo SILVA, o primeiro passo consiste em abrir o arquivo .bashrc que se encontra
oculto no diretório home/seu usuário (no presente caso, home/ufabc). Fazendo-se
uso da interface visual de navegação entre diretórios, basta entrar na pasta em questão e
executar o comando composto pelas teclas ”Ctrl + h”. Neste momento, todos os arquivos
ocultos serão visualizados, o que possibilita a edição do .bashrc.
Para tal, adiciona-se as seguintes linhas de comandos ao final do arquivo .bashrc:
# minhas a l t e r a ç õ e s GNUradio :
e x p o r t LD LIBRARY PATH=$LD LIBRARY PATH: / u s r / l o c a l / l i b
e x p o r t PYTHONPATH=$PYTHONPATH: / u s r / l o c a l / l i b / python2 . 7 / d i s t −
packages
e x p o r t PATH=$PATH: / u s r / l o c a l / b i n
e x p o r t PKG CONFIG PATH=$PKG CONFIG PATH: / u s r / l o c a l / l i b /
pkgconfig
A.5
Instalação do GNU Radio 3.3.0
Iniciar o download do GNU, desabilitando a usrp2 através do comando configure. Este
procedimento se faz necessário para eliminar os erros indicados pelo sistema após entrar
com o comando make:
84
$ cd
$ wget h t tp : / / g n u r a d i o . o r g / redmine / attachments / download /372/
gnuradio − 3 . 3 . 0 . t a r . gz
$ t a r x z f gnuradio − 3 . 3 . 0 . t a r . gz ; cd gnuradio − 3 . 3 . 0
$ . / c o n f i g u r e −−with−boost−i n c l u d e −d i r=$BOOST PREFIX/ i n c l u d e /
boost −1 37 −−d i s a b l e −usrp2
$ make
Mesmo após desabilitar a usrp2, o sistema ainda pode acusar outro erro, conforme
indicado abaixo:
/ u s r / b i n / l d : cannot f i n d −l a u d i o
c o l l e c t 2 : ld returned 1 exit status
make [ 5 ] : ∗∗∗ [ l i b g n u r a d i o −q t g u i . l a ] E r r o r 1
make [ 5 ] : Leaving d i r e c t o r y ‘ / home/ u f a b c / gnuradio − 3 . 4 . 2 /
gr−q t g u i / l i b ’
make [ 4 ] : ∗∗∗ [ a l l ] E r r o r 2
make [ 4 ] : Leaving d i r e c t o r y ‘ / home/ u f a b c / gnuradio − 3 . 4 . 2 /
gr−q t g u i / l i b ’
make [ 3 ] : ∗∗∗ [ a l l −r e c u r s i v e ] E r r o r 1
make [ 3 ] : Leaving d i r e c t o r y ‘ / home/ u f a b c / gnuradio − 3 . 4 . 2 / gr−q t g u i ’
make [ 2 ] : ∗∗∗ [ a l l ] E r r o r 2
make [ 2 ] : Leaving d i r e c t o r y ‘ / home/ u f a b c / gnuradio − 3 . 4 . 2 / gr−q t g u i ’
make [ 1 ] : ∗∗∗ [ a l l −r e c u r s i v e ] E r r o r 1
make [ 1 ] : Leaving d i r e c t o r y ‘ / home/ u f a b c / gnuradio − 3 . 4 . 2 ’
make : ∗∗∗ [ a l l ] E r r o r 2
Trata-se de um erro já conhecido (LAPS-UFPA, b). Para contorná-lo, primeiramente
executa-se a seguinte busca:
$ sudo f i n d / −name ’ l i b a u d i o ∗ ’
Em resposta, o sistema reporta os seguintes caminhos:
/ u s r / s h a r e / doc / l i b a u d i o 2
/ usr / share / libaudio2
/ u s r / l i b / i 3 8 6 −l i n u x −gnu/ l i b a u d i o . s o . 2
/ u s r / l i b / i 3 8 6 −l i n u x −gnu/ l i b a u d i o . s o . 2 . 4
/ u s r / l i b / rhythmbox / p l u g i n s / au d i oc d / l i b a u d i o c d . s o
/ u s r / l i b / rhythmbox / p l u g i n s / a u d i o s c r o b b l e r / l i b a u d i o s c r o b b l e r . so
/ var / l i b / dpkg / i n f o / l i b a u d i o 2 : i 3 8 6 . p o s t i n s t
/ var / l i b / dpkg / i n f o / l i b a u d i o 2 : i 3 8 6 . l i s t
/ var / l i b / dpkg / i n f o / l i b a u d i o 2 : i 3 8 6 . s h l i b s
85
A criação do seguinte link simbólico (LAPS-UFPA, b) resolve o problema:
$ sudo l n −s / u s r / l i b / i 3 8 6 −l i n u x −gnu/ l i b a u d i o . s o . 2 . 4 / u s r / l i b /
i 3 8 6 −l i n u x −gnu/ l i b a u d i o . s o
Ao repetir o comando make, nota-se que o erro não será novamente reportado, possibilitando desta forma a dar continuidade ao processo:
$ make
$ sudo l d c o n f i g
A.6
Adição de permissão de usuário
Conforme LOULA, adiciona-se a seguir a permissão de usuário para poder trabalhar
com a USRP1:
$ sudo addgroup us rp
$ sudo addgroup <YOUR USER> u srp
$ echo ’ACTION==”add ” , BUS==”usb ” , SYSFS{ idVendor}==”f f f e ” ,
SYSFS{ i d P r o d u c t }==”0002”, GROUP:=”us rp ” , MODE: = ”0 6 6 0 ” ’ >
tmpfile
$ sudo chown r o o t . r o o t t m p f i l e
$ sudo mv t m p f i l e / e t c / udev / r u l e s . d/10− u srp . r u l e s
Dando continuidade para a próxima etapa (teste da USRP), observou-se que a configuração acima não bastava para efetivar a comunicação com a USRP1. Apenas para
exemplificar o problema, consegue-se rodar o teste recomendado (LOULA, 2009) apenas
após a inclusão do comando sudo antes de usrp benchmark usb.py. Em termos práticos, outros exemplos não poderiam ser executados no ambiente GNU sem que o problema
de permissão fosse sanado primeiramente.
Neste caso, para o Ubuntu 12.04, complementa-se de forma eficaz a sequência de permissão ao considerar (BLUM, 2012; GNU RADIO, e):
$ sudo addgroup us rp
$ sudo usermod −G u srp −a <YOUR USERNAME>
$ echo ’ACTION==”add ” , SUBSYSTEM==”usb ” , ATTRS{ idVendor}==
” f f f e ” , ATTRS{ i d P r o d u c t }==”0002”, GROUP=”usrp ” ,
MODE=”0666”’ > t m p f i l e
$ sudo chown r o o t . r o o t t m p f i l e
$ sudo mv t m p f i l e / e t c / udev / r u l e s . d/10− u srp . r u l e s
A.7
86
Teste de interface com a USRP1
Conforme LOULA, recomenda-se nesta etapa a reinicialização do computador:
$ sudo r e b o o t
Retomada a seção, conecta-se a USRP1 à porta USB, descarregando em seguida as
seguintes linhas de comando no Terminal:
$ cd / u s r / l o c a l / s h a r e / g n u r a d i o / examples / u srp /
$ . / usrp benchmark usb . py
Neste momento, inicia-se a execução dos testes, culminando no valor máximo de
32MB/segundo de throughput entre USB e USRP, conforme segue:
87
T e s t i n g 2MB/ s e c . . . u s b t h r o u g h p u t = 2M
ntotal
= 1000000
nright
= 998393
r u n l e n g t h = 998393
delta
= 1607
OK
ntotal
= 2000000
nright
= 1998336
r u n l e n g t h = 1998336
delta
= 1664
OK
ntotal
= 4000000
nright
= 3999637
r u n l e n g t h = 3999637
delta
= 363
OK
ntotal
= 8000000
nright
= 7999101
r u n l e n g t h = 7999101
delta
= 899
OK
ntotal
= 16000000
nright
= 15999439
r u n l e n g t h = 15999439
delta
= 561
OK
Max USB/USRP throughput = 32MB/ s e c
Complementando os testes, também é possı́vel verificar a conformidade de transmissão
da USRP:
$ cd /home/ u f a b c / gnuradio − 3 . 3 . 0 / u srp / h o s t / apps
$ ./ test usrp standard tx
Como resposta, obtem-se do sistema:
88
which :
0
interp :
16
r f f r e q : −1
amp :
10000.000000
nsamples : 3 . 2 e+07
S u b d e v i c e name i s Flex 900 Tx MIMO B
S u b d e v i c e f r e q r an ge : ( 7 . 5 e +08 , 1 . 0 5 e +09)
mux : 0 x000098
baseband r a t e : 8 e+06
target freq :
900000000.000000
ok :
true
r . baseband freq : 904000000.000000
r . dxc freq :
−4000000.000000
r . r e s i d u a l f r e q : 0.000000
r . inverted :
0
tx underrun
tx underrun
tx underrun
tx underrun
tx underrun
tx underrun
tx underrun
tx underrun
tx underrun
x f e r e d 3 . 2 e+07 b y t e s i n 1 . 0 1 s e c o n d s . 3 . 1 5 8 e+07 b y t e s / s e c .
cpu time = 0 . 0 9 6
9 underruns
Da mesma forma, também é possı́vel verificar a conformidade de recepção da USRP:
$ ./ test usrp standard rx
Como resposta, obtem-se do sistema:
x f e r e d 1 . 3 4 e+08 b y t e s i n 4 . 1 9 s e c o n d s .
cpu time = 0 . 5 7 2
noverruns = 0
3 . 2 e+07 b y t e s / s e c .
Finalmente, uma vez (bem) sucedidas as etapas anteriores, consegue-se abrir o GNU
Radio 3.3.0 e executar os exemplos contidos na pasta /home/ufabc/gnuradio-3.3.0/gnuradioexamples/grc/usrp:
89
$ cd
$ gnuradio−companion
A.8
Upgrade para GNU 3.6.5.1
Esta etapa é opcional, porém funciona caso deseje-se trabalhar com a última versão
de GNU Radio sem perder o suporte à biblioteca libusrp:
$ cd
$ wget h t tp : / / g n u r a d i o . o r g / r e l e a s e s / g n u r a d i o / gnuradio − 3 . 6 . 5 . 1
. t a r . gz
$ t a r x z f gnuradio − 3 . 6 . 5 . 1 . t a r . gz ;
$ cd g n u r a d i o
$ mkdir g n u r a d i o / b u i l d
$ cd g n u r a d i o / b u i l d
$ cmake . . /
$ make
$ make t e s t
Ao abir gnuradio-companion, observa-se que a pasta USRP ainda está sendo considerada, mesmo tratando-se da última versão do GNU. Apesar de verificada durante a etapa
de compatibilização entre os softwares e hardware do presente trabalho, tal migração não
foi mantida na configuração final do experimento.
90
Apêndice
B
Tutorial de Instalação e Configuração USRP Hardware Driver (UHD)
B.1
Introdução
O presente artefato constitui o tutorial de instalação do software UHD para ambientes
computacionais baseados no sistema operacional Ubuntu 12.04 (ETTUS RESEARCH, d).
Primeiramente, inicia-se uma seção do Terminal Ubuntu. Para tal, basta digitar
ctrl + alt + T . Visando instalar o UHD e receber seus respectivos pacotes de atualização, utiliza-se:
$ sudo bash −c ’ echo ”deb h t t p : / / f i l e s . e t t u s . com/ b i n a r i e s /uhd
u n s t a b l e / r e p o /uhd/ ubuntu / ‘ l s b r e l e a s e −cs ‘ ‘ l s b r e l e a s e −cs ‘
main ” > / e t c / apt / s o u r c e s . l i s t . d/ e t t u s . l i s t ’
$ sudo apt−g e t update
$ sudo apt−g e t i n s t a l l −t ‘ l s b r e l e a s e −cs ‘ uhd
Se algum problema ocorrer por causa do libboost-all-dev (vide tutorial GNU Radio),
inserir diretamente:
$ sudo apt−g e t i n s t a l l l i b u s b −1.0−0−dev python−c h e e t a h
doxygen python−d o c u t i l s
Partindo do pressuposto de que o sistema Ubuntu foi recém instalado (desprovido de
maiores recursos), torna-se necessário instalar o cmake como pré-requisito ao passo seguinte. Para tal, basta inserir no Terminal a seguinte linha de comando:
$ sudo apt−g e t i n s t a l l cmake
A obtenção do código fonte pode ser realizada diretamente do repositório (ETTUS RESEARCH, a):
91
Apêndice B. Tutorial de Instalação e Configuração - USRP Hardware Driver (UHD) 92
$ g i t c l o n e g i t : / / g i t h u b . com/ E t t u s R e s e a r c h /uhd . g i t
Para a construção, seguir conforme passos abaixo:
$
$
$
$
$
$
$
cd uhd/ h o s t
mkdir b u i l d
cd b u i l d
cmake . . /
make
make t e s t
sudo make i n s t a l l
B.2
Library Path
O ajuste do library path precisa ser feito de forma a garantir que o libuhd.so esteja
no LD LIBRARY PATH. Conforme tutorial de instalação do GNU Radio, o caminho
havia sido definido como:
e x p o r t LD LIBRARY PATH=$LD LIBRARY PATH: / u s r / l o c a l / l i b
Logo, a biblioteca libuhd.so precisa estar em /usr/local/lib. Para confirmar, entra-se
primeiramente com os direitos de administrador da máquina:
$ sudo −i
Consulta-se a seguir o conteúdo do diretório:
$ cd / u s r / l o c a l / l i b
$ dir
Procedendo conforme os tutoriais, obter-se-á a seguinte resposta através do Terminal:
l i b g n u r a d i o −a t s c − 3 . 3 . 0 . so . 0
l i b g n u r a d i o −q t g u i − 3 . 3 . 0 . so . 0
l i b g n u r a d i o −a t s c − 3 . 3 . 0 . so . 0 . 0 . 0
l i b g n u r a d i o −q t g u i − 3 . 3 . 0 . so . 0 . 0 . 0
l i b g n u r a d i o −a t s c . l a
l i b g n u r a d i o −q t g u i . l a
l i b g n u r a d i o −a t s c . s o
l i b g n u r a d i o −q t g u i . s o
l i b g n u r a d i o −audio−a l s a − 3 . 3 . 0 . so . 0
l i b g n u r a d i o −t r e l l i s − 3 . 3 . 0 . so . 0
l i b g n u r a d i o −audio−a l s a − 3 . 3 . 0 . so . 0 . 0 . 0
l i b g n u r a d i o −t r e l l i s − 3 . 3 . 0 . so . 0 . 0 . 0
l i b g n u r a d i o −audio−a l s a . l a
libgnuradio−t r e l l i s . la
l i b g n u r a d i o −audio−a l s a . so
libgnuradio −t r e l l i s . so
l i b g n u r a d i o −audio−o s s − 3 . 3 . 0 . so . 0
l i b g n u r a d i o −usrp − 3 . 3 . 0 . so . 0
l i b g n u r a d i o −audio−o s s − 3 . 3 . 0 . so . 0 . 0 . 0
l i b g n u r a d i o −usrp − 3 . 3 . 0 . so . 0 . 0 . 0
l i b g n u r a d i o −audio−o s s . l a
l i b g n u r a d i o −u srp . l a
l i b g n u r a d i o −audio−o s s . s o
l i b g n u r a d i o −u srp . s o
l i b g n u r a d i o −c o r e − 3 . 3 . 0 . so . 0
l i b g n u r a d i o −video −s d l − 3 . 3 . 0 . so . 0
l i b g n u r a d i o −c o r e − 3 . 3 . 0 . so . 0 . 0 . 0
l i b g n u r a d i o −video −s d l − 3 . 3 . 0 . so . 0 . 0 . 0
l i b g n u r a d i o −c o r e . l a
l i b g n u r a d i o −video −s d l . l a
l i b g n u r a d i o −c o r e . s o
l i b g n u r a d i o −video −s d l . so
l i b g n u r a d i o −cvsd−vocoder − 3 . 3 . 0 . so . 0
l i b g r u e l − 3 . 3 . 0 . so . 0
l i b g n u r a d i o −cvsd−vocoder − 3 . 3 . 0 . so . 0 . 0 . 0
l i b g r u e l − 3 . 3 . 0 . so . 0 . 0 . 0
l i b g n u r a d i o −cvsd−v o c o d e r . l a
libgruel . la
l i b g n u r a d i o −cvsd−v o c o d e r . s o
l i b g r u e l . so
l i b g n u r a d i o −gsm−f r −vocoder − 3 . 3 . 0 . so . 0
libgsl .a
l i b g n u r a d i o −gsm−f r −vocoder − 3 . 3 . 0 . so . 0 . 0 . 0
libgslcblas .a
l i b g n u r a d i o −gsm−f r −v o c o d e r . l a
libgslcblas . la
l i b g n u r a d i o −gsm−f r −v o c o d e r . s o
l i b g s l c b l a s . so
l i b g n u r a d i o −msdd6000 − 3 . 3 . 0 . so . 0
l i b g s l c b l a s . so . 0
l i b g n u r a d i o −msdd6000 − 3 . 3 . 0 . so . 0 . 0 . 0
l i b g s l c b l a s . so . 0 . 0 . 0
l i b g n u r a d i o −msdd6000 . l a
l i b g s l . la
l i b g n u r a d i o −msdd6000 rs − 3 . 3 . 0 . so . 0
l i b g s l . so
l i b g n u r a d i o −msdd6000 rs − 3 . 3 . 0 . so . 0 . 0 . 0
l i b g s l . so . 0
l i b g n u r a d i o −msdd6000 rs . l a
l i b g s l . so . 0 . 1 6 . 0
l i b g n u r a d i o −msdd6000 rs . so
libuhd . so
l i b g n u r a d i o −msdd6000 . s o
libuhd . so .003
l i b g n u r a d i o −noaa − 3 . 3 . 0 . so . 0
libuhd . so . 0 0 3 . 0 0 5
l i b g n u r a d i o −noaa − 3 . 3 . 0 . so . 0 . 0 . 0
l i b u s r p − 3 . 3 . 0 . so . 0
l i b g n u r a d i o −noaa . l a
l i b u s r p − 3 . 3 . 0 . so . 0 . 0 . 0
l i b g n u r a d i o −noaa . s o
libusrp . la
l i b g n u r a d i o −pager − 3 . 3 . 0 . so . 0
l i b u s r p . so
l i b g n u r a d i o −pager − 3 . 3 . 0 . so . 0 . 0 . 0
pkgconfig
l i b g n u r a d i o −p a ge r . l a
python2 . 7
l i b g n u r a d i o −p a ge r . s o
uhd
Verifica-se, portanto, a presença do arquivo no local esperado. Para que usuários comuns possam ter acesso, cria-se finalmente a seguinte regra:
$ cd / u s r / l o c a l / l i b /uhd/ u t i l s
$ sudo cp uhd−u srp . r u l e s / e t c / udev / r u l e s . d/
$ sudo udevadm c o n t r o l −−r e l o a d −r u l e s
Apêndice
C
Tutorial de Utilização - pySim
C.1
Introdução
O presente artefato constitui o tutorial de utilização da ferramenta pySim (OSMOCOM,
a; OSMOCOM, c; SERVERFAULT, 2013), um software de código aberto capaz de realizar a
leitura e escrita de SIM cards.
Considera-se para este fim a obtenção prévia de um dispositivo USB e SIM cards programáveis da marca MagicSIM, SuperSIM (SIMMAX) ou afins.
C.2
Download da ferramenta
O pySim pode ser obtido descarregando-se a seguinte linha de comando no Terminal
Ubuntu:
$ g i t c l o n e g i t : / / g i t . osmocom . o r g / pysim . g i t / p e n t e s t / us rp / sim
C.3
Compreendendo o pySim
A melhor forma de visualizar toda a gama de opções disponibilizadas pelo pySim é
a abertura individual dos códigos que o acompanham (especialmente contidos nos arquivos pySim-prog.py, readme e pySim-read.py ), interpretando os conteúdos e rotinas
visando compreender eventuais falhas que ocorram durante o processo de leitura e/ou
escrita.
Durante o experimento, tal conduta possibilitou a identificação de problemas com o
hardware inicialmente adquirido, sendo necessário disparar a compra de novos dispositivos
USB (desta vez funcionais).
95
Apêndice C. Tutorial de Utilização - pySim
96
Capaz de interagir com cartões programáveis de diferentes marcas (configurável através
do parâmetro -t, assumindo uma das opções válidas: supersim, magicsim, fakemagicsim
ou grcardsim), observa-se grande flexibilidade na ferramenta ao permitir a escrita das diversas variáveis contidas nos SIM cards.
Apenas para exemplificar, encontram-se descritos abaixo alguns dos parâmetros disponibilizados:
•Parâmetro -n: Definição do Nome da Operadora
•Parâmetro -c: Definição do paı́s
•Parâmetro -x: Definição do MCC
•Parâmetro -y: Definição do MNC
•Parâmetro -i: Definição do IMSI
•Parâmetro -s: Definição do ICCID
No momento da escrita, os dados podem ser definidos manualmente contanto que sejam
respeitados os critérios de entrada para cada uma das variáveis (como a quantidade de
dı́gitos e a utilização de algarismos na base decimal/hexadecimal, por exemplo). Para os
demais parâmetros não definidos pelo usuário, números aleatórios são automaticamente
gerados pelo pySim (respeitando os critérios de escrita).
C.4
Exemplos de Escrita e Leitura
Primeiramente, deve-se realizar o acesso da pasta em que o conteúdo foi descarregado.
A mesma pode ser alterada conforme a vontade do usuário, logo para fins ilustrativos,
assume-se o acesso da seguinte estrutura:
$ sudo −i
$ ( senha de a d m i n i s t r a d o r )
$ cd /home/ u f a b c / pysim
Supondo a seguinte configuração de escrita partindo do usuário:
$ . / pySim−prog . py −n UFABC −c 55 −x 001 −y 1 −i 001012462443021
−s 8955231081151665704 −t s u p e r s i m −d / dev /ttyUSB0
Observa-se no sistema o seguinte comportamento:
97
I n s e r t c a rd now ( o r CTRL−C t o c a n c e l )
Generated c a r d p a r a m e t e r s :
> Name
: UFABC
> SMSP
: e1ffffffffffffffffffffffff058100555555ffffffffff
ff000000
> ICCID
: 8955231081151665704
> MCC/MNC : 1/1
> IMSI
: 001012462443021
> Ki
: 6 f86285f6b454898497b5f1766138464
> OPC
: 2191 c 0 2 2 4 d 4 e 2 8 9 0 f a e e 7 d 9 c 0 9 7 e 3 d 8 4
> ACC
: None
Programming . . .
Done !
Conclui-se desta forma o processo de escrita do SIM card, levando em conta algumas
variáveis definidas pelo usuário e outas automaticamente geradas pelo sistema.
Finalmente, emprega-se o comando de leitura do pySim para confirmar o processo de
escrita exemplificado anteriormente:
$ . / pySim−r e a d . py
Observa-se no sistema a seguinte resposta:
Reading . . .
ICCID : 8955231081151665704
IMSI : 001012462443021
SMSP: f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f
ffffffffffffffffffffffff
ACC: f f f f
MSISDN : Not a v a i l a b l e
Done !
O mesmo comando de leitura também pode ser utilizado para a verificação de SIM
cards comuns (não programáveis).
98
Apêndice
D
Tutorial de Instalação e Configuração OpenBTS
D.1
Introdução
O presente artefato constitui o tutorial de instalação e configuração da ferramenta
OpenBTS-UHD, uma variante já descontinuada do OpenBTS baseada na antiga versão
2.6. Devido às questões relacionadas ao clock de rede levantadas ao longo do presente
trabalho, inviabiliza-se a utilização da versão P2.8 atualmente mantida e recomendada
pelos desenvolvedores.
Antes de chegar a tal conclusão, diferentes versões de OpenBTS foram verificadas
durante a condução dos experimentos. Após exercitar as diversas combinações disponibilizadas por cada uma das versões avaliadas, observou-se no OpenBTS-UHD a opção mais
adequada visto a configuração de hardware disponı́vel.
Apesar de possuir foco na versão UHD, reserva-se o último tópico do presente tutorial para a apresentação resumida dos pontos relevantes de instalação e configuração das
demais versões de OpenBTS, de forma a facilitar a condução de trabalhos futuros com
diferentes configurações de USRP.
D.2
Instalação das Bibliotecas
Conforme LAPS-UFPA, a compilação das diversas partes do OpenBTS requer a presença dos seguintes pacotes:
$ sudo apt−g e t i n s t a l l a u t o c o n f l i b t o o l l i b o s i p 2 −dev
l i b o r t p −dev l i b u s b −1.0−0−dev g++ s q l i t e 3 l i b s q l i t e 3 −dev
e r l a n g l i b r e a d l i n e 6 −dev l i b b o o s t −a l l −dev
Segundo APVRILLE; FORTINET, recomendam-se também as seguintes instalações:
99
Apêndice D. Tutorial de Instalação e Configuração - OpenBTS
100
$ sudo apt−g e t i n s t a l l l i b o r t p 7 −∗ a s t e r i s k
$ sudo apt−g e t i n s t a l l s d c c l i b a u d i o −dev s q l i t e m a n a s t e r i s k
D.3
Construção e Instalação do OpenBTS-UHD
A instalação e configuração do software UHD encontra-se descrita no Anexo B. Porém,
apesar do nome atribuı́do a esta versão do OpenBTS, verifica-se no Capı́tulo IV que a
mesma dispensa a utilização do UHD para realizar a interface com a USRP1, obrigando
o experimento a adotar na verdade o libusrp1 conforme descrito no Anexo A. Ignorar
este passo fatalmente incorrerá em problemas de transmissão para o caso de clocks com
64MHz, conforme observado na etapa experimental do trabalho.
Tomando em consideração este importante detalhe, pode-se obter o OpenBTS-UHD
lançando as seguintes linhas de comando no Terminal do Ubuntu (TSOU, 2010):
$ g i t c l o n e h t t p s : / / g i t h u b . com/ t t s o u / openbts−uhd . g i t
Como opção também válida, pode-se utilizar:
$ g i t c l o n e g i t : / / g i t h u b . com/ t t s o u / openbts−uhd . g i t
Segundo comando acima, o conteúdo será descarregado na pasta /home/SeuUsuário. Os comandos abaixo resumem os passos necessários para construir e configurar o
OpenBTS-UHD visando trabalhar com uma USRP1 com clock de 64MHz:
$
$
$
$
$
$
cd openbts−uhd/ p u b l i c −trunk
./ bootstrap
. / c o n f i g u r e −−with−usrp1 −−with−resamp
make
make check
Sem a combinação de ambas as configurações with-usrp1 e with-resamp, observar-se-ão
problemas no estabelecimento da rede que impossibilitarão o experimento de ser executado nas presentes condições.
Por sua vez, cria-se uma cópia do arquivo OpenBTS.config visando preservar as
configurações de rede inicialmente estabelecidas pelo OpenBTS. Tal ação facilita a análise
de falhas provenientes de alterações indevidas nos parâmetros de rede:
101
$ cp OpenBTS . c o n f i g . example OpenBTS . c o n f i g
Dependendo da etapa de configuração do GNU Radio, torna-se necessário executar o
programa como administrador da máquina. Para tal:
$ cd
$ sudo −i
$ cd /home/ u f a b c / openbts−uhd/ p u b l i c −trunk / apps
$ . / OpenBTS
Neste momento, o programa deverá ser inicializado sem qualquer problema. A visualização da rede pode ser prejudicada dado as limitações de clock previamente discutidas,
porém encontram-se descritas no capı́tulo 4 todas as considerações levadas em conta no
contorno de tal limitação.
A partir deste momento, as opções disponibilizadas pelo comando help e os parâmetros de configuração presentes em OpenBTS.config constituem os principais aliados na
manutenção da rede.
D.4
Outras versões de OpenBTS
Conforme mencionado anteriormente, encontra-se no OpenBTS-UHD a melhor opção
dada a configuração de hardware disponı́vel para a execução do experimento. Longe de
configurar uma vantagem perante as versões mais recentes da ferramenta, trabalhar com
uma versão descontinuada incorre em dificuldades adicionais como a completa ausência
de suporte por parte dos desenvolvedores e entusiastas do OpenBTS.
Por este motivo, a etapa de integração dos elementos de rede foi iniciada considerando o OpenBTS P2.8 (GSM), seguido de tentativas fracassadas também com a
sua variante GPRS, OpenBTS-OSMO, OpenBTS-2.6.0 Mamou, OpenBTS-2.6 TTSOU
e OpenBTS-2.5.x Lacassine. Sem abordar os detalhes associados a cada uma destas operações, desenvolve-se abaixo um resumo com pontos relevantes de instalação e configuração
das demais versões de OpenBTS, de forma a facilitar a condução de trabalhos futuros com
diferentes configurações de USRP.
D.4.1
Versão P2.8
Segundo (OPENBTS, e), a melhor forma para se obter o OpenBTS é baixando o código diretamente do repositório fonte. Para tal, considerando que não exista interesse em
participar como membro desenvolvedor de códigos para o OpenBTS, basta introduzir a
102
seguinte linha de comando no Terminal:
$ svn co h t t p : / / wush . n e t / svn / ra n ge / s o f t w a r e / p u b l i c
O comando disponibiliza o download do OpenBTS para usuários anônimos com direitos de leitura. Ao final, o conteúdo baixado será armazenado na estrutura de pasta
/home/Seu Usuário/public/openbts. O OpenBTS P2.8 suporta uma variedade de
hardwares, porém não suporta o clock original da USRP1 (sem problemas caso o clock
tenha sido modificado). Supondo uma USRP1, seguir-se-ia com:
$
$
$
$
$
cd p u b l i c / openbts / trunk
a u t o r e c o n f −i
. / c o n f i g u r e −−with−usrp1
make
sudo touch / var / run /command
Uma vez encerrada a construção, torna-se necessário criar e associar o transceiver
apropriado para a USRP1. Maiores detalhes encontram-se disponı́veis no site mantido
pelos desenvolvedores (OPENBTS, c). Verificou-se ineficaz a tentativa de manter o clock
de 64MHz nesta etapa, e para todos os efeitos, conforme observa-se no relatório de falhas
abaixo, a rede nunca foi estabelecida:
1373736315.416532 3074062080:
S t a r t i n g t h e system . . .
R e c e i v e d shutdown s i g n a l
S h u t t i n g down t r a n s c e i v e r . . .
ALERT 3077442368 1 4 : 2 5 : 2 0 . 5 USRPDevice . cpp : 5 4 5 : setRxFreq : s e t
RX: 9 . 0 0 2 e+08 f a i l e d
baseband f r e q : 8 . 9 7 e+08
DDC f r e q :
−3.2 e+06
r e s i d u a l f r e q : 0.00298023
ALERT 3077442368 1 4 : 2 5 : 2 0 . 5 T r a n s c e i v e r . cpp : 5 6 3 : d r i v e C o n t r o l :
RX f a i l e d t o tune
ALERT 3074062080 1 4 : 2 5 : 2 0 . 5 TRXManager . cpp : 3 5 5 : tune : RXTUNE
f a i l e d with s t a t u s 1
ALERT 3074062080 1 4 : 2 5 : 2 0 . 5 TRXManager . cpp : 4 0 9 : powerOn :
POWERON f a i l e d with s t a t u s 1
ALERT 3074062080 1 4 : 2 5 : 2 0 . 5 TRXManager . cpp : 4 2 7 : setPower :
SETPOWER f a i l e d with s t a t u s 1
system ready
u se t h e OpenBTSCLI u t i l i t y t o a c c e s s CLI
ALERT 3063667520 1 4 : 2 6 : 2 6 . 7 TRXManager . cpp : 9 3 : c l o c k H a n d l e r :
TRX c l o c k i n t e r f a c e timed out , assuming TRX i s dead .
ufabc@ufabc−STI : ˜ / p u b l i c / openbts / trunk / apps$
103
D.4.2
104
Variante GPRS baseada no P2.8
Embora não tenha sido possı́vel testar esta variante do P2.8 pelos mesmos motivos
reportados em sua versão GSM original, promete-se nesta versão uma implementação de
rede GPRS. Recomenda-se a verificação como tema para desenvolvimento de trabalhos
futuros.
$ g i t c l o n e −b gprs−work g i t : / / g i t h u b . com/ c h e m e r i s /
openbts−p2 . 8 . g i t
D.4.3
OpenBTS-OSMO
Versão mantida pelo grupo OSMOCOM:
$
$
$
$
$
$
$
$
$
$
g i t c l o n e g i t : / / g i t . osmocom . o r g / openbts−osmo . g i t
cd openbts−osmo/ p u b l i c −trunk
./ bootstrap
. / c o n f i g u r e −−with−usrp1 −−with−resamp
make
make check
cd apps
cp OpenBTS . c o n f i g . example OpenBTS . c o n f i g
. / OpenBTS
Observou-se que o mesmo também descontinou o suporte ao clock de 64MHz.
D.4.4
OpenBTS 2.6
Versão descontinuada do OpenBTS, mantida no mesmo repositório onde se encontra
a variante UHD.
105
$ g i t c l o n e h t t p s : / / g i t h u b . com/ t t s o u / openbts − 2 . 6 . g i t
$ cd openbts −2.6
$ cd p u b l i c −trunk
$ e x p o r t LIBS=−l p t h r e a d
$ LIBS=−l p t h r e a d ; e x p o r t
$ LIBS=−l p t h r e a d
$ a u t o r e c o n f −i
$ ./ configure
$ make
$ make check
cd apps
cp OpenBTS . c o n f i g . example OpenBTS . c o n f i g
D.4.5
Versões anteriores
Versões anteriores do OpenBTS encontradas fora dos repositórios oficiais também foram verificadas, tais como o openbts-2.6.0Mamou e openbts-2.5.xLacassine. Não
existem pontos especı́ficos dignos de menção para estas versões.
106
Apêndice
E
Tutorial de Instalação - Asterisk
E.1
Introdução
O presente artefato constitui o tutorial de instalação do Asterisk, responsável por
desempenhar as funções tradicionalmente implementadas na BSC, HLR, VLR e MSC.
Conforme visto anteriormente, o Asterisk é um software de PBX que utiliza o VoIP através do Protocolo SIP.
E.2
Instalação - Asterisk v1.8.7.1
As linhas de comando abaixo resumem os passos necessários para instalar a versão
1.8.7.1 do Asterisk (através do Terminal do Ubuntu):
$ wget h t tp : / / downloads . a s t e r i s k . o r g /pub/ t e l e p h o n y / a s t e r i s k /
r e l e a s e s / a s t e r i s k − 1 . 8 . 7 . 1 . t a r . gz
$ t a r x v z f a s t e r i s k − 1 . 8 . 7 . 1 . t a r . gz
$ cd a s t e r i s k − 1 . 8 . 7 . 1
$ sudo apt−g e t −y i n s t a l l l i b x m l 2
$ sudo apt−g e t −y i n s t a l l l i b x m l 2 −dev
$ ./ configure
$ make
E.3
Possı́veis Erros
Com o Asterisk sendo instalado diretamente na estrutura (protegida) de arquivos do
sistema Ubuntu, pode-se deparar com os seguintes erros caso haja uma tentativa de retrabalho na instalação:
107
Apêndice E. Tutorial de Instalação - Asterisk
108
WARNING WARNING WARNING
Your A s t e r i s k modules d i r e c t o r y , l o c a t e d a t
/ u s r / l i b / a s t e r i s k / modules c o n t a i n s modules t h a t were not
i n s t a l l e d by t h i s v e r s i o n o f A s t e r i s k . P l e a s e e n s u r e t h a t
t h e s e modules a r e c o m p a t i b l e with t h i s v e r s i o n b e f o r e
a t t e m p t i n g t o run A s t e r i s k .
a p p f l a s h . so
app jack . so
app page . s o a p p s a y c o u n t p l . so
c d r a d a p t i v e o d b c . so
cdr odbc . so
c d r p g s q l . so
cd r t ds . so
cel odbc . so
c d r r a d i u s . so c d r s q l i t e . so
c e l p g s q l . so
c e l r a d i u s . so
c e l t d s . so
chan gtalk . so
c h a n j i n g l e . so
chan vpb . so
c o d e c i l b c . so
codec resample . so
codec speex . so
f o r m a t o g g v o r b i s . so
f u n c c u r l . so
func odbc . so
f u n c s p e e x . so
pbx lua . so
r e s a i s . so
r e s c a l e n d a r c a l d a v . so
r e s c a l e n d a r e w s . so
res ca lenda r exch ang e . so
r e s c a l e n d a r i c a l e n d a r . so
r e s c o n f i g c u r l . so
r e s c o n f i g l d a p . so
r e s c o n f i g o d b c . so
r e s c o n f i g p g s q l . so
r e s c o n f i g s q l i t e . so
r e s c u r l . so
res fax spandsp . so
r e s j a b b e r . so
res odbc . so
r e s h t t p p o s t . so
res snmp . so
WARNING WARNING WARNING
Este erro se deve ao fato de outras versões de Asterisk terem sido instaladas previamente durante as tentativas de integração entre os diversos elementos do experimento.
Dada a incompatibilidade com os módulos instalados no diretório /usr/lib/asterisk/modules/, precisa-se primeiramente remover o conteúdo antigo antes de iniciar uma nova
instalação (MADSEN; MEGGELEN; BRYANT, n/a).
Para tal, pode-se realizar o seguinte procedimento através do Terminal Ubuntu:
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
109
sudo −i
cd / u s r / l i b / a s t e r i s k / modules
rm a p p f l a s h . s o
rm a p p j a c k . s o
rm app page . s o
rm a p p s a y c o u n t p l . s o
rm c d r a d a p t i v e o d b c . so
rm c d r o d b c . s o
rm c d r p g s q l . s o
rm c d r r a d i u s . s o
rm c d r s q l i t e . s o
rm c d r t d s . s o
rm c e l o d b c . s o
rm c e l p g s q l . s o
rm c e l r a d i u s . s o
rm c e l t d s . so
rm c h a n g t a l k . s o
rm c h a n j i n g l e . s o
rm chan vpb . so
rm c o d e c i l b c . s o
rm c o d e c r e s a m p l e . s o
rm c o d e c s p e e x . s o
rm f o r m a t o g g v o r b i s . so
rm f u n c c u r l . s o
rm f u n c o d b c . s o
rm f u n c s p e e x . so
rm p b x l u a . s o
rm r e s a i s . s o
rm r e s c a l e n d a r c a l d a v . so
rm r e s c a l e n d a r e w s . s o
rm r e s c a l e n d a r e x c h a n g e . s o
rm r e s c a l e n d a r i c a l e n d a r . s o
rm r e s c o n f i g c u r l . s o
rm r e s c o n f i g l d a p . s o
rm r e s c o n f i g o d b c . s o
rm r e s c o n f i g p g s q l . s o
rm r e s c o n f i g s q l i t e . s o
rm r e s c u r l . s o
rm r e s f a x s p a n d s p . s o
rm r e s h t t p p o s t . so
rm r e s j a b b e r . so
rm r e s o d b c . s o
rm res snmp . so
Uma vez concluı́da esta etapa, pode-se abrir um novo Terminal (ctrl + alt + T ) e
executar as linhas de comando:
$
$
$
$
$
110
cd a s t e r i s k − 1 . 8 . 7 . 1
./ configure
make
sudo make samples
E.4
Configuração
Cada MS é visto pelo Asterisk como um usuário SIP, ou seja, cada IMSI será visto
pelo Asterisk como um cliente SIP, permitindo desta forma que chamadas e mensagens de
texto sejam trocadas entre dispositivos GSM e terminais VoIP. Deve-se levar esta premissa
em consideração na etapa posterior de configuração, onde o cadastro de cada usuário deve
ser realizado nos arquivos extensions.conf e sip.conf conforme indicado por (LOULA,
2009). Dicas importantes também são apresentadas por MEGGELEN; MADSEN; SMITH
e NATALIZIO et al..

- PGEE-HOME

Transcrição

Documentos relacionados

modem ademco cia

Empanada de Frango com Sultanas Ingredientes p/ a massa

Baixar Material Teórico

Superando o Turismo

Teorema de Ptolomeu

Configuraç˜ao de um cliente de Instant Messaging Jabber

Latinoamérica Latinoamérica

Frecuencia Latinoamérica

Sincronizaç ˜ao de Arquivos entre Nuvens de

Guia de Tipos - Tipos Góticos