Bootloader para Atualização Remota de Fi Rmware Via Tecnologia GSM

Centro de Tecnologia e Urbanismo
Departamento de Engenharia Eletrica
Danilo Perdigao
Bootloader para atualizacao remota de

firmware via tecnologia GSM
Monografia apresentada ao curso de

Engenharia Eletrica da Universidade
Estadual de Londrina, como parte dos
requisitos necessarios para a conclusao
do curso de Engenharia Eletrica.
Londrina, PR
2012
Danilo Perdigao

Monografia apresentada ao curso de Engenharia

Eletrica da Universidade Estadual de Londrina,
como parte dos requisitos necessarios para a
conclusao do curso de Engenharia Eletrica.
Area: Telecomunicacoes
Orientador:
Prof. MSc. Decio Luiz Gazzoni Filho
Londrina, PR
2012
Ficha Catalografica
Perdigao, Danilo
Bootloader para atualizacao remota de firmware via tecnologia
GSM. Londrina, PR, 2012. 53 p.
Monografia (Trabalho de Conclusao de Curso) Universidade

Estadual de Londrina, PR. Departamento de Engenharia Eletrica
.
1. Sistemas Embarcados 2. Transmissao de dados via rede

celular 3. Criptografia Departamento de Engenharia Eletrica
Danilo Perdigao

Monografia apresentada ao curso de Engenharia

Eletrica da Universidade Estadual de Londrina,
como parte dos requisitos necessarios para a
conclusao do curso de Engenharia Eletrica.
Area: Telecomunicacoes
Comissao Examinadora
Prof. MSc. Decio Luiz Gazzoni Filho

Depto. de Engenharia Eletrica
Orientador
Prof. MSc. Diogo Kaoru Takayama

Universidade Estadual de Londrina
Prof. MSc. Osmar Tormena Jr

Universidade Estadual de Londrina
Londrina, 05 de Novembro de 2012

Dedico este trabalho aos meus pais: Sueli e Sebastiao, pessoas a quem devo
tudo o que sou na vida.
Agradecimentos
Agradeco primeiramente a minha mae Sueli Barboza Perdigao e meu pai Se-
bastiao Perdigao por toda dedicacao, incentivo e compreensao ao longo de todos
esses anos da minha graduacao.
Agradeco a todos os meu amigos que passaram por todas as dificuldades do

curso ao meu lado e que me ajudaram muito ao longo desses anos, em especial
para: Kawana, Guilherme, Cesar, Regis, Cristiano, Heitor.
Agradeco tambem a todos meus parentes e amigos que de uma forma ou outra
me ajudaram durante os anos de minha graduacao.
Resumo
A utilizacao de equipamentos eletronicos embarcados esta aumentando muito nos

dias de hoje. Muitos desses equipamentos, como modulos de rastreamento veicu-
lar, modulos de telemetria e ate equipamentos de seguranca residencial utilizam
modulos celulares para se comunicarem com os servidores das empresas e trans-
mitirem as informacoes necessarias. Um dos problemas para as empresas que
prestam esse tipo de servico e a manutencao dos equipamentos. Muitos proble-
mas podem surgir dependendo da area onde o produto e utilizado ou tambem
dependendo da operadora que o cliente utiliza.
Pensando nessa area de atuacao, foi desenvolvido um sistema de atualizacao
remota de firmware utilizando o proprio modulo celular embarcado no produto.
Esse tipo de atualizacao remota e conhecido por FOTA(Firmware Over The Air).
A atualizacao e feita atraves de um Bootloader, que e um codigo inserido em
um espaco reservado do microcontrolador. O Bootloader e o responsavel por
receber os dados do modulo celular via protocolo FTP e alterar o firmware do
proprio microcontrolador, fazendo assim com que nao seja necessario retirar o
equipamento do local de funcionamento e conecta-lo a um computador, ou ate
mesmo envia-lo para a empresa fabricante.
Abstract
The design of electronic devices includes, with increasing frequency, the use of em-
bedded systems. Many of these devices, such as vehicle tracking modules, teleme-
try modules and residential safety equipment, use cellular modules to transmit
information to corporate servers. An issue faced by companies that provide this
type of service is that of maintenance. Many problems can arise depending on
the area where the product is used and also depending on the cellular carrier used
by the costumer.
This work seeks to provide a solution to this problem, by developing a remote
firmware update system using the cellular module embedded in the product.
This type of remote update is known as FOTA (Firmware Over The Air). The
update is done through a Bootloader, which is a section of code inserted into a
reserved space of a microcontroller. The Bootloader is responsible for receiving
data from the cell module using the FTP protocol and updating the firmware of
the microcontroller itself, thereby making it unnecessary to remove the equipment
from the operating site to connect it to a computer, or even transport it to the
manufacturer.
Sumario
Lista de Figuras
Lista de Tabelas
Lista de Abreviaturas
1 Introducao 1
2 Revisao de literatura 4
2.1 Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Sequencia de reset de um microcontrolador . . . . . . . . . 5
2.1.3 Memoria Flash . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Comunicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Comunicacao serial . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Comunicacao via rede celular . . . . . . . . . . . . . . . . 9
2.3 Seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Criptografia . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 Criptografia simetrica . . . . . . . . . . . . . . . . . . . . 14
2.3.3 Criptografia de chave publica e assinaturas digitais . . . . 18
2.3.4 Comparacao entre criptografia simetrica e de chave publica 20
2.3.5 Funcoes de Resumo Criptografico . . . . . . . . . . . . . . 22
2.3.6 Message Authentication Codes (MACs) . . . . . . . . . . . 24
3 Desenvolvimento 27
3.1 Programa para piscar um LED . . . . . . . . . . . . . . . . . . . 27

3.2 Programa com comunicacao serial simples . . . . . . . . . . . . . 28
3.3 Bootloader que faz uma escrita na memoria sem comunicacao externa 29
3.3.1 Sequencia de manipulacao da Flash . . . . . . . . . . . . . 30
3.4 Bootloader atraves de comunicacao serial com o computador . . . 32
3.4.1 S19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.2 Protecao da Memoria e Redirecionamento do Vetor de In-

terrupcoes . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.3 Conversao ASCII para Hexadecimal . . . . . . . . . . . . . 34
3.4.4 Programacao por linhas . . . . . . . . . . . . . . . . . . . 35
3.4.5 Software Reset . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5 Adicao de criptografia e sistemas de seguranca contra copia de

informacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.1 Verificacao de integridade e segmentacao da memoria do

microcontrolador . . . . . . . . . . . . . . . . . . . . . . . 40
3.5.2 Atualizacao com firmware particionado e cifrado . . . . . . 41
3.6 Bootloader com comunicacao via internet . . . . . . . . . . . . . . 42
4 Resultado 47
4.1 Tamanho do bootloader . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Tempo de execucao . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5 Conclusao 50
Referencias 52
Lista de Figuras
2.1 Esquema de comunicacao entre duas partes usando Criptografia . 12
2.2 a) Imagem Original; b) Imagem cifrada utilizando o modo ECB;

c) Imagem cifrada utilizando outros modos . . . . . . . . . . . . . 15
2.3 Counter Mode (CTR) . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Esquema de comunicacao entre duas partes usando Criptografia de

Chave Publica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Ataque em uma comunicacao de chave publica entre duas partes. 21
2.6 Blocos de uma operacao do SHA-1. . . . . . . . . . . . . . . . . . 25
3.1 Fluxograma de escrita e apagamento da memoria Flash dos micro-

controladores da famlia HCS08 . . . . . . . . . . . . . . . . . . . 31
3.2 S19 com os setores destacados . . . . . . . . . . . . . . . . . . . . 33
3.3 Fluxograma da rotina de verificacao . . . . . . . . . . . . . . . . . 37
3.4 Arquivo de controle com os setores destacados . . . . . . . . . . . 39
3.5 Fluxograma da comunicacao com o modulo celular. . . . . . . . . 46
4.1 Tamanho do codigo do bootloader . . . . . . . . . . . . . . . . . . 47

Lista de Tabelas
3.1 Segmentacao da memoria Flash . . . . . . . . . . . . . . . . . . . 41

Lista de Abreviaturas
RAM Random Access Memory
FOTA Firmware Over The Air
GSM Global System for Mobile Communications
GPRS General Packet Radio Service
FTP File Transfer Protocol
TCP Transmission Control Protocol
UDP User Datagram Protocol
IP Internet Protocol
AES Advanced Encryption Standard
HMAC Hash-based Message Authentication Code
MAC Message Authentication Code
SHA1 Secure Hash Algorithm 1
ROM Read-Only Memory
PROM Programmable Read-Only Memory
EPROM Erasable Programmable Read-Only Memory
EEPROM Electrically-Erasable Programmable Read-Only Memory
SIM Subscriber Identity Module
ECB Electronic Codebook
CBC Cipher Block Chaining
CFB Cipher Feedback
OFB Output Feedback

CTR Counter
SIMD Single Instruction, Multiple Data
MDC Modification Detection Codes
MIC Message Integrity Code
OWHF One-way Hash Functions
CRHF Collision Resistant Hash Functions
NIST National Institute for Standards and Technology
DES Data Encryption Standard
LED Light-Emitting Diode
ASCII American Standard Code for Information Interchange

1
1 Introducao
Em sistemas microcontrolados, um bootloader e um programa usado para

atualizar o firmware de um microcontrolador sem a necessidade de um hardware
especfico para a programacao e sem a necessidade de retirar o microcontrolador
da placa. Construir um bootloader e uma opcao barata e que nao exige muito
esforco de hardware para atualizacao de firmware. Ele consiste em um codigo
que e inserido no proprio microcontrolador que se deseja fazer atualizacoes de
firmware. Esse codigo e a primeira funcao a ser executada apos a inicializacao do
microcontrolador. Ele deve conter uma rotina de verificacao para identificar se
deve continuar com a rotina de atualizacao de firmware ou se deve pular para
o codigo do usuario.
O microcontrolador utilizado e o MC9S08JM32(FREESCALE SEMICONDUC-

TOR, INC, 2009) da famlia HCS08 da Freescale .
R E um microcontrolador bas-
tante simples e barato, o que faz dele uma otima opcao para o desenvolvimento
de muitos projetos. Ele possui 32kB de memoria flash para o firmware com siste-
mas de protecao de blocos e varias opcoes de seguranca. Existe ainda na mesma
famlia a opcao com 60kB de flash. Possui tambem 4kB de memoria RAM.
Nos microcontroladores mais antigos era necessario a utilizacao de placas

programadoras, que fazem um aumento no nvel de tensao para garantir que os
processos de apagamento e escrita pudessem ser realizados. Este microcontrolador
nao exige um nvel de tensao diferenciado para programacao da memoria flash,
pois possui um circuito interno que realiza um aumento de tensao, e com isso
o uso de in-application programming, que e a tecnica onde a programacao do
microcontrolador e feita no proprio circuito que esta inserido, a exemplo de um
bootloader, se torna viavel.
Atraves do modulo GSM, no caso o modulo LEON-G100(U-BLOX AG, 2011)

da u-Blox ,
R foi possvel fazer a atualizacao do firmware do microcontrolador.
A imagem do firmware e recebida pela placa via internet, utilizando uma co-
nexao com um servidor FTP, usando o modulo celular embarcado no produto
para prover conexao atraves da tecnologia GSM, conectado ao microcontrolador
1 Introducao 2
atraves de uma conexao serial tipo RS-232. O modulo utilizado e quadriband, ou

seja, trabalha em todas as 4 frequencias de operacao do GSM/GPRS no Brasil,
850MHz, 900MHz, 1800MHz e 1900MHz.
Os modems e modulos celulares sao controlados por comandos chamados de

comandos AT(U-BLOX AG, 2012). Atraves desses comandos e possvel acessar as
funcionalidades dos protocolos TCP/IP e UDP/IP atraves da conexao GPRS.
O modulo LEON-G100 ja possui pilha IP internamente, nao sendo necessario
o desenvolvimento de uma pilha IP. Uma das funcionalidades utilizadas e o su-
porte aos protocolos FTP, eliminando a preocupacao com detalhes de baixo nvel
de protocolos de comunicacao via internet, e eliminando a necessidade de im-
plementar um servidor especfico para servir as atualizacoes de firmware para o
bootloader, ja que e possvel usar servidores FTP amplamente disponveis.
Apesar de ser uma solucao barata, o desenvolvimento de um bootloader apre-

sentou um conjunto de desafios. O bootloader deve ser robusto e confiavel, pois
caso algum problema aconteca durante a atualizacao do firmware de um deter-
minado equipamento, esse equipamento pode vir a parar de funcionar, causando
ainda mais problemas ao inves de resolver. Para conseguir desenvolver um bo-
otloader com robustez e confiabilidade, foi desenvolvido um programa de facil
analise, e evitando o uso de tecnicas avancadas de programacao. Evitou-se, por
exemplo, o uso de interrupcoes, que causam a execucao assncrona de codigo e
complicam a analise.
A seguranca tambem e considerada um topico muito importante do desenvol-

vimento. O esforco do desenvolvimento de firmware e o mais caro no desenvolvi-
mento de um produto e por isso deve ser adicionada alguma forma de seguranca
para impedir que os dados sejam copiados, e que a placa seja reprogramada com
uma versao nao autorizada do codigo. Para garantir estas propriedades, foram
utilizadas tecnicas de criptografia. As propriedades de privacidade dos dados
foram atingidas pelo uso de criptografia simetrica com algoritmo AES256, e au-
tenticidade e integridade dos dados por meio de um codigo de autenticacao de
mensagens(MAC) HMAC-SHA1.
A memoria flash e, sem duvida, um dos pontos cruciais do desenvolvimento.

Esse tipo de memoria nao pode ser reescrita sem que antes se apague a memoria.
A memoria flash e dividida em paginas, ou blocos, de 512 bytes no MC9S08JM32.
Existem diferentes tecnicas para efetuar a gravacao na memoria flash(CAPISTRAN-
GARZA, 2009). A gravacao pode ser feita byte a byte ou em sequencia de bytes. A
tecnica de gravar uma sequencia de bytes e chamada de burst program e diminui
1 Introducao 3
o tempo de gravacao em relacao a gravacao byte a byte, pois a alta tensao que
e aplicada a flash nao precisa ser desabilitada apos a gravacao de cada byte.
Ja o apagamento da memoria nao pode ser feito byte a byte. Sempre que um
comando de apagamento e utilizado, este apaga a pagina inteira em que esta
situado o endereco que se deseja apagar.
Foi utilizada uma tecnica chamada in-application programming. Essa tecnica

permite gravar dados na flash do microcontrolador utilizando as proprias rotinas
do microcontrolador. Essa tecnica e um pouco trabalhosa, pois a memoria nao
consegue realizar leitura e escrita ao mesmo tempo. E necessario colocar as
rotinas de leitura, verificacao e escrita da flash na memoria RAM, mesmo que
temporariamente, para que seja possvel realizar a escrita da memoria flash.
O microcontrolador possui um sistema de protecao de blocos que previne que

algum bloco de memoria seja apagado ou reprogramado por engano. E definido
um endereco da memoria onde a partir dele, a memoria nao podera ser alte-
rada. Isso e muito importante para que o bootloader fique protegido e nao seja
danificado ou alterado de alguma forma.
4
2 Revisao de literatura
2.1 Bootloader
No mundo da informatica, Boot e o termo utilizado para o processo de ini-

cializacao de um computador. Nesse caso, um pequeno programa, chamado de
Bootloader, e executado primeiramente com a funcao de carregar o sistema ope-
racional do disco rgido para a memoria RAM, fazendo assim com que o sistema
operacional consiga comecar a trabalhar.
Em sistemas microcontrolados, um Bootloader nao e muito diferente. Ele

tambem e o primeiro trecho de codigo a ser executado, porem a sua funcao nao
e carregar um sistema operacional, mas verificar se o firmware que se encontra
programado na memoria do microcontrolador deve ser atualizado ou nao. Caso
nao haja a necessidade de atualizacao do firmware, ele simplesmente entrega o
controle para o programa principal. Porem se for detectado que existe a neces-
sidade, ou talvez a possibilidade, de atualizar o firmware do microcontrolador, o
Bootloader ira se encarregar de fazer isso de forma autonoma.
Existem diversos tipos de Bootloader, cada um com suas caractersticas par-

ticulares. Todo Bootloader, para funcionar, precisa de um canal de comunicacao
com algum equipamento que ira fornecer a imagem do firmware a ser inserido no
microcontrolador. Na grande maioria dos microcontroladores equipados com Bo-
otloader, esse equipamento que fornece a imagem do firmware e um computador.
A partir de um computador existem duas maneiras mais comuns de se obter uma
comunicacao com o microcontrolador, atraves da comunicacao USB ou atraves da
porta serial do computador. Alguns modelos de Bootloaders possuem ate um soft-
ware que e instalado no computador para fazer o gerenciamento da comunicacao
com o microcontrolador, facilitando a manipulacao para o usuario. Outros mo-
delos emulam um dispositivo armazenamento em massa, que e reconhecido pelo
computador da mesma maneira de um PenDrive, dessa forma o usuario precisa
apenas copiar a imagem do firmware para dentro do dispositivo e o firmware sera
gravado pelo bootloader.
2.1 Bootloader 5
Neste trabalho, o equipamento de comunicacao que ira fornecer a imagem

de firmware para o microcontrolador sera um modulo celular. Dessa maneira, e
possvel desenvolver um Bootloader onde a principal caracterstica e a autonomia
do sistema em que estiver inserido. Como o modulo celular pode ser embarcado
dentro do produto e com ele e possvel receber e transmitir dados atraves da
internet, nao e necessario a intervencao fsica do usuario, nao exigindo a utilizacao
de cabos. Dessa forma, a utilizacao desse tipo de Bootloader se torna muito
interessante para equipamentos que possuam um modulo celular embarcado, como
por exemplo os rastreadores veiculares.
2.1.1 Firmware
Firmware e uma sequencia de comandos ou instrucoes operacionais programa-

das no hardware de um determinado equipamento eletronico. O firmware e como
um software de computador, porem o firmware e o programa especfico de micro-
controladores. No desenvolvimento de equipamentos eletronicos microcontrola-
dos, o desenvolvimento do firmware e tao importante quanto o desenvolvimento
de hardware, onde na maioria dos equipamentos o desenvolvimento do firmware
acaba sendo a etapa mais demorada e mais dispendiosa do desenvolvimento do
produto.
Sao muitas as vantagens de se ter equipamentos microcontrolados. Com

apenas um componente, economizando em muito o tamanho do equipamento, e
possvel realizar inumeras operacoes. Para isso e necessario apenas uma alteracao
no firmware do microcontrolador, fazendo com que ele trabalhe da maneira que
o desenvolvedor escolher. A vantagem de se ter um bootloader inserido no mi-
crocontrolador e a facilidade que ele proporciona para a atualizacao do firmware.
Como um bootloader o proprio usuario e capaz de fazer a atualizacao do micro-
controlador sem a necessidade de um circuito programador. Com um bootloa-
der que possua comunicacao atraves da rede GSM essa vantagem e ainda muito
maior, pois o proprio desenvolvedor pode fazer essa atualizacao remotamente sem
necessidade da intervencao do usuario.
2.1.2 Sequencia de reset de um microcontrolador
Toda vez que um microcontrolador e alimentado, ou energizado, ele comeca a

executar o firmware que esta inserido nele. Para que haja uma ordem na execucao
desse firmware, cada microcontrolador possui um endereco de memoria que e uti-
lizado para verificar onde e o incio do firmware que esta gravado. Esse endereco
2.1 Bootloader 6
e localizado geralmente no incio ou no final da memoria do microcontrolador.

Alem desse endereco que indica o incio do firmware, existem outros enderecos
proximos ao Vetor de Reset. Todos esses enderecos juntos sao chamados de Veto-
res de Interrupcoes. As interrupcoes sao muito utilizadas nos microcontroladores,
pois como eles utilizam uma logica sequencial, e possvel tratar uma acao ou
um acontecimento com prioridade em relacao a sequencia normal do programa
utilizando as interrupcoes.
O endereco que indica o incio do firmware e chamado de Vetor de Reset.

Quando um Reset e provocado, e no vetor de reset que o microcontrolador procura
para saber onde e o incio do firmware. Existem varias maneiras de se provocar
o reset de um microcontrolador, como por exemplo a aplicacao de 0V no pino de
RESET. Algumas vezes se faz necessario a utilizacao do reset via software, sem
intervencao fsica. Por exemplo, apos o usuario salvar alguma nova configuracao
do equipamento, pode ser necessario reiniciar o programa para que a configuracao
faca o efeito desejado. Existem algumas maneiras de provocar o reset via software,
o Watch Dog Timer e uma das maneiras de se provocar um reset quando o
microcontrolador se encontrar travado em algum ponto do codigo por um tempo
definido pelo programador. Outra maneira, utilizadas em microcontroladores da
famlia HCS08, e a utilizacao de um Opcode Ilegal, ou seja, uma funcao que nao
pertence ao conjunto de funcoes do microcontrolador.
Quando um reset e provocado em um microcontrolador, a execucao do pro-

grama e suspensa e se da incio a uma serie de acontecimentos. Primeiramente o
Stack Pointer e zerado, ou carregado com o valor inicial nominal do microcontro-
lador. O Stack Pointer e o responsavel por informar a CPU onde se encontra o
ultimo elemento do Stack do microcontrolador. O Stack, ou Pilha em portugues,
e o responsavel por guardar alguns dados importantes, como os enderecos de
retorno das funcoes. Quando uma funcao e chamada, o Stack Pointer e incre-
mentado e o valor do endereco atual do Contador de Programa e colocado na
Pilha, de acordo com o que o Stack Pointer estiver apontando. Apos a funcao
ser executada, o microcontrolador le o valor apontado pelo Stack Pointer, que e
decrementado apos isso, e coloca de volta no Contador de Programa, para que o
programa continue a execucao de onde havia parado.
As Flags do microcontrolador tambem sao, em sua maioria, reiniciadas para o

valor nominal. As Flags sao usadas internamente pelo processador para informar
a algumas instrucoes o estado em que se encontra o microcontrolador.
O Contador de Programa tambem sofre uma alteracao, ele e atualizado com

2.1 Bootloader 7
o valor que se encontra no vetor de reset, para comecar a execucao do firmware

do incio. Em alguns microcontroladores, a memoria RAM e apagada quando um
reset e gerado, em outros a memoria RAM nao e alterada, gerando assim pros e
contras. Tomando cuidado com a inicializacao das variaveis no codigo, manter o
valor na memoria RAM pode ser utilizado de varias maneiras.
2.1.3 Memoria Flash
O firmware fica armazenado na memoria do microcontrolador. Existem dois

tipos de memorias dentro de um microcontrolador, a memoria volatil e a memoria
nao volatil. A memoria volatil e chamada de memoria RAM, ou Random Access
Memory, e tem uma velocidade de escrita e leitura muito maior do que uma
memoria nao volatil. A desvantagem da memoria volatil e que ela so e capaz
de armazenar dados enquanto estiver energizada, ou seja, quando a alimentacao
e desligada os dados sao perdidos. A memoria RAM e muito importante para
o funcionamento do microcontrolador, mas nao pode ser utilizada para gravar o
firmware do microcontrolador.
O firmware deve ser gravado em uma memoria que seja capaz de reter as
informacoes mesmo quando a alimentacao seja desligada. E essa a funcao da
memoria nao volatil do microcontrolador. Existem varios tipos de memoria
nao volatil, como as memorias ROM, PROM, EPROM, EEPROM e Flash. As
memorias EEPROM e Flash sao as mais utilizadas hoje em dia nos microcontro-
ladores. Cada uma tem suas caractersticas e vantagens, sendo que a memoria
Flash e uma variacao da EEPROM e vem ganhando um espaco muito grande e
sendo utilizada em quase todos os equipamentos atuais.
A memoria Flash pode ser lida um numero infinito de vezes, porem possui
um numero finito de apagamento e gravacao. Isso se deve ao desgaste que ocorre
no processo de apagamento e gravacao da memoria Flash. Para realizar o apa-
gamento ou a gravacao da memoria Flash, ela exige um nvel de tensao maior
do que o necessario para a leitura e varia entre 10V e 13V. A Flash e dividida
em blocos e para ser feito o apagamento de algum byte da memoria e preciso
que seja apagado todo o bloco em que aquele byte esta inserido. Ja o processo
de escrita pode ser feito byte a byte ou por bloco, desde que este ja tenha sido
apagado. Escrever um byte na memoria Flash sem que este tenha sido apagado
pode corromper o valor que sera gravado.
O fato da memoria Flash precisar de um nvel de tensao mais alto para execu-
tar o apagamento/gravacao em relacao ao nvel de tensao para a leitura, dificulta
2.2 Comunicacao 8
o uso de in-application programming, que e a tecnica de fazer o microcontrolador

realizar o apagamento e gravacao da propria memoria Flash. Para que isso seja
possvel, e necessario tomar algumas precaucoes. Como a funcao programada pra
realizar o apagamento/gravacao da memoria se encontra na propria memoria, nao
e possvel ler o programa da memoria enquanto esteja sendo feito um processo de
apagamento/gravacao, para isso e preciso fazer com que as funcoes de escrita e
apagamento da flash sejam executas de outro lugar, ou seja, devem ser executadas
da memoria RAM. Deve existir uma funcao que faca essa copia das funcoes da
Flash para a memoria RAM, assim e possvel seguir com a execucao do codigo
ao mesmo tempo em que a memoria Flash e gravada/apagada.
2.2 Comunicacao
Comunicacao pode ser definido como o processo pelo qual uma informacao
gerada em um ponto no espaco e no tempo chamado fonte e transferida a outro
ponto no espaco e no tempo chamado destino. Com outras palavras podemos
dizer que Comunicacao e a troca de informacao entre sujeitos ou objetos.
Telecomunicacao e a designacao dada a transmissao, emissao ou recepcao,

por fio, meios opticos ou qualquer outro processo eletromagnetico, de smbolos,
caracteres, sinais, escritos, imagens, sons ou informacoes de qualquer natureza.
2.2.1 Comunicacao serial
Comunicacao Serial e o nome que se da ao tipo de comunicacao onde os dados

sao transmitidos um de cada vez. Esse tipo de comunicacao e muito utilizada pois
e uma das mais baratas que existe, principalmente quando a distancia e muito
grande. Isso acontece pois o meio fsico utilizado para esse tipo de comunicacao
pode ser apenas 1 fio, onde em outro meios de comunicacao sao utilizados um
maior numero de fios, o que faz o preco aumentar. Para que seja possvel es-
tabelecer uma transmissao com apenas 1 fio, e necessario que o dados a serem
transmitidos sejam quebrados em pedacos de 1 bit. E dessa maneira que a mai-
oria dos microcontroladores se comunicam, utilizando a comunicacao serial com
apenas dois pinos, TX e RX, um para receber os dados e outro para enviar dados.
2.2 Comunicacao 9
2.2.1.1 Taxa de Transferencia (Baud Rate)
Como os dados a serem enviados de forma serial sao quebrados em bits, e

preciso definir uma frequencia, ou taxa, em que os dados serao enviados. Essa
taxa e chamada de Baud Rate e a maioria dos equipamentos e programas de
computador tem alguns valores pre-definidos de Baud Rate.
2.2.1.2 Transmissao Assncrona x Transmissao Sncrona
Alem de definir o Baud Rate, e preciso escolher qual sera o modo de sincro-
nismo que sera utilizado. E preciso definir alguma maneira de fazer com que o
equipamento que vai receber a informacao consiga ler os bits nos momentos em
que eles estao sendo enviados. Existem dois modos de se fazer a transmissao, a
Transmissao Assncrona e a Transmissao Sncrona(CANZIAN, 2011).
A Transmissao Sncrona utiliza um outro fio onde e inserido um sinal de

clock pelo equipamento que esta transmitindo a informacao. Atraves desse sinal
de clock, o receptor e capaz de fazer a leitura dos bits no momento exato em que
o bit esta sendo transmitido, sendo que ele espera uma transicao do clock para
fazer essa leitura. O equipamento transmissor deve garantir uma transicao do
clock no momento em que estiver mandando um novo bit.
A Transmissao Assncrona exige uma previa configuracao tanto do transmis-

sor quanto do receptor em relacao ao Baud Rate. Isso e necessario porque nao
existe um sinal de clock utilizado para instruir o receptor. Definindo o Baud Rate
dos dois lados da comunicacao, o receptor consegue realizar a leitura de todos os
bits na mesma taxa em que sao enviados. Nesse tipo de comunicacao existem dois
bits que sao utilizados para garantir o sincronsmo. Primeiro e transmitido um bit
chamado de Start Bit, esse bit possui nvel logico 0 e e utilizado para informar
o circuito receptor que um dado esta comecando a ser transmitido. Ao final do
dado que esta sendo transmitido e enviado um bit chamado de Stop Bit, que
possui nvel logico 1 e tem a funcao de informar o receptor que o dado terminou
de ser enviado.
2.2.2 Comunicacao via rede celular
A rede de telefonia celular e uma rede de telecomunicacao que foi criada

para fornecer o servico de telefonia movel, ou seja, fornecer a possibilidade de
comunicacao entre dois equipamentos sem utilizacao de fios. A rede de telefonia
celular no mundo vem evoluindo ao longo dos anos e conforme novas tecnologias
2.2 Comunicacao 10
vao surgindo, elas vao sendo classificadas em geracoes.
2.2.2.1 Padrao GSM
A tecnologia mais difundida no Brasil como padrao para telefonia celular

e a tecnologia GSM (Global System for Mobile Communications). Dentro das
redes de telefonia GSM, foi posteriormente desenvolvido o servico GPRS (General
Packet Radio Service), que permite uma taxa de transmissao teorica de ate 171
kbits/s, e o servico EDGE (Enhanced Data rates for Global Evolution) com uma
taxa maxima teorica de 473,6 kbits/s. Mais recentemente, foi lancado tambem o
servico chamado 3G (utilizando as tecnologias UMTS, HSDPA e outras). O 3G
torna-se interessante quando se deseja trafegar grandes volumes de dados. Para
pequenos volumes o GPRS e o EDGE tornam-se mais acessveis, sendo utilizados
em ampla gama de aplicacoes.
O GSM e considerado uma tecnologia de segunda geracao pois os sinais e

canais de voz sao digitais, diferentemente das tecnologias anteriores que eram
analogicas. Ela tambem se diferencia das outras tecnologias pelo uso de SIM
Cards nos aparelhos, que permitem o armazenamento de dados do assinante e
possibilitam para o assinante a troca de aparelhos sem dificuldades.
No Brasil todas as operadoras operam no GSM nas frequencias de 850MHz,

900MHz, 1800MHz e 1900MHz.
2.2.2.2 Modulo Celular
Dentro de cada celular existe um modulo GSM. Esse modulo tem a funcao de
codificar as informacoes e transmit-las para a operadora em que esta registrado.
O avanco da tecnologia vem fazendo com que esses modulos fiquem cada
vez mais robustos, incluindo opcoes de seguranca como o anti-jamming e algu-
mas outras caractersticas que facilitam a utilizacao, podendo ser incorporados a
qualquer equipamento eletronico.
A comunicacao entre o modulo celular e os microcontroladores ou computa-

dores sao feitas, em sua maioria por comunicacao serial. Os modulos celulares
possuem uma lista extensa de comandos para estabelecer uma comunicacao com
um microcontroladores ou com um computador. Esses comandos sao chamados
de Comandos AT, e sao largamente utilizados em diversos tipos de modems.
2.3 Seguranca 11
2.3 Seguranca
O desenvolvimento de firmware e uma das etapas mais dispendiosas no de-

senvolvimento de qualquer produto eletronico microcontrolado. A facilidade de
se copiar o hardware de um equipamento e muito grande, pois existem poucas
maneiras de proteger o equipamento desse tipo de copia. Os microcontroladores
possuem muitas opcoes de seguranca para proteger o firmware que esta dentro
dele. Portanto e muito difcil com que o firmware seja extrado de dentro do
microcontrolador. Porem e necessario tomar algumas atitudes para proteger o
firmware enquanto ele nao esta no microcontrolador.
Em um bootloader que realiza comunicacao atraves da rede GSM/GPRS,

o firmware devera ser colocado em um servidor e ser transmitido ate o modulo
celular, portanto e necessario garantir uma seguranca grande durante esse pro-
cesso. Para obter a seguranca necessaria durante esse processo existe uma tecnica
chamada de Criptografia.
2.3.1 Criptografia
De acordo com (MENEZES; OORSCHOT; VANSTONE, 1996), Criptografia e o es-

tudo de tecnicas matematicas relacionadas a aspectos de seguranca da informacao,
tais como a confidencialidade, integridade de dados, autenticacao de entidade e
autenticacao da origem dos dados. Os objetivos da criptografia podem ser resu-
midos em quatro itens, confidencialidade, integridade dos dados, autenticacao e
irretratabilidade.
1. Confidencialidade e um servico usado para manter o conteudo da informacao

restrito a apenas aqueles autorizados a te-la. Ha varias abordagens para
fornecer confidencialidade, que vao desde a protecao fsica a algoritmos ma-
tematicos que tornam os dados ininteligveis.
2. Integridade dos Dados e um servico que trata da alteracao nao autorizada de

dados. Para garantir a integridade dos dados, e preciso ter a capacidade de
detectar a manipulacao de dados por pessoas nao autorizadas. Manipulacao
de dados inclui tarefas como a insercao, eliminacao e substituicao.
3. Autenticacao e um servico relacionado a identificacao. Esta funcao se aplica

a ambas as entidades e informacoes em si. Duas partes que entram em
uma comunicacao devem identificar um ao outro. A informacao entregue
2.3 Seguranca 12
atraves de um canal deve ser autenticada quanto a origem, a data de ori-

gem, conteudo de dados, hora de envio, etc. Por estas razoes este aspecto
da criptografia e normalmente subdividido em duas classes principais: au-
tenticacao de entidade e autenticacao da origem dos dados.
4. Irretratabilidade e um servico que evita uma entidade de negar compromis-

sos anteriores ou acoes. Quando surgem disputas devido a uma entidade
negar que certas acoes foram tomadas, um meio de resolver a situacao e
necessario. Por exemplo, uma entidade pode autorizar a aquisicao de pro-
priedade por outra entidade e, posteriormente, negar que a autorizacao foi
concedida. Um procedimento que envolve uma terceira parte confiavel e
necessario para resolver a disputa.
2.3.1.1 Modelo de comunicacao e seus componentes
A figura 2.1(MENEZES; OORSCHOT; VANSTONE, 1996) mostra um modelo sim-

ples de comunicacao entre duas partes usando criptografia.
Figura 2.1: Esquema de comunicacao entre duas partes usando Criptografia
Uma entidade ou parte e algo ou alguem que envia, recebe, ou manipula

2.3 Seguranca 13
informacoes. Alice e Beto sao entidades na Figura 2.1. Uma entidade pode
ser uma pessoa, um terminal de computador, etc.
Um remetente e uma entidade em uma comunicacao entre duas partes que

e o transmissor legtimo da informacao. Na Figura 2.1, o remetente e Alice.
Um receptor e uma entidade em uma comunicacao entre duas partes que e

o destinatario das informacoes. Na Figura 2.1, o receptor e Beto.
Um adversario e uma entidade em uma comunicacao entre duas partes que

nao e nem o remetente nem o destinatario, e que tenta burlar o servico de
seguranca da informacao a ser fornecida entre o emissor e o receptor. Varios
outros nomes sao sinonimo de adversario, como inimigo, invasor, oponente,
bisbilhoteiro e intruso. Um adversario, muitas vezes, tenta desempenhar o
papel de qualquer remetente legtimo ou o receptor legtimo.
2.3.1.2 Autenticacao
A autenticacao e um termo usado em um sentido muito amplo(MENEZES;

OORSCHOT; VANSTONE, 1996). Tem o objetivo de garantir que as entidades sao
realmente quem dizem que sao, ou que as informacoes nao tenham sido mani-
puladas por terceiros. A autenticacao e especfica para cada tipo de seguranca
se esta tentando alcancar. Exemplos de objetivos especficos incluem controle de
acesso, autenticacao entidade, autenticacao de mensagem, integridade de dados,
irretratabilidade e autenticacao de chave.
A autenticacao e um dos mais importantes de todos os objetivos de segu-

ranca da informacao. Ate meados da decada de 1970 acreditava-se que o sigilo e
autenticacao estavam intrinsecamente ligados. Com a descoberta das funcoes de
resumo criptografico e assinaturas digitais, percebeu-se que o sigilo e autenticacao
eram objetivos distintos e independentes de seguranca da informacao. Pode nao
parecer importante separar os dois, mas ha situacoes em que nao e apenas util,
mas indispensavel. Por exemplo, se uma comunicacao de duas partes entre Alice
e Beto esta acontecendo e Alice esta em um pas e Beto em outro, os pases podem
nao permitir o sigilo do canal; um ou ambos os pases pode querer monitorar a
comunicacao. Alice e Beto, no entanto, gostariam de ter a certeza da identidade
de cada um, e da integridade e da origem da informacao que enviar e receber.
O cenario anterior ilustra varios aspectos independentes de autenticacao. Se

Alice e Beto desejam a garantia da identidade do outro, ha duas possibilidades a
ser considerada.
2.3 Seguranca 14
1. Alice e Beto podem se comunicar sem delay. Ou seja, ambos sao ativos na
comunicacao em tempo real.
2. Alice ou Beto podem estar trocando mensagens com algum atraso. Ou seja,
as mensagens podem ser encaminhadas atraves de varias redes, armazena-
das e transmitidas em algum momento posterior.
Na primeira possibilidade, Alice e Beto gostaria de verificar as identidades em

tempo real. Isso pode ser feito com a Alice enviando para Beto algum desafio, para
o qual Beto e a unica entidade que pode responder corretamente. Beto poderia
realizar uma acao semelhante para identificar Alice. Este tipo de autenticacao e
comumente referida como autenticacao de entidade ou, de forma mais simples,
identificacao.
Para a segunda possibilidade, que nao e conveniente desafiar e aguardar uma

resposta, e alem disso, o caminho de comunicacao pode ser apenas em uma
direcao. Diferentes tecnicas sao necessarias para autenticar a origem da men-
sagem. Esta forma de autenticacao e chamada de autenticacao da origem de
dados.
2.3.2 Criptografia simetrica
Existem dois tipos de algoritmos baseados em chaves: simetricos e de chave

publica(SCHNEIER, 1996). Algoritmos simetricos, por vezes chamados algoritmos
convencionais, sao algoritmos onde a chave de cifragem pode ser calculada a partir
da chave de decifragem e vice-versa. Na maior parte dos algoritmos simetricos, a
chave de cifragem e a chave de decifragem e a mesma. Esses algoritmos, tambem
chamados de algoritmos de chave secreta ou algoritmos de chave unica, exigem
que o remetente e o destinatario possuam a mesma chave antes de poderem se
comunicar de forma segura. A seguranca de um algoritmo simetrico esta toda
na chave; divulgar a chave significa que qualquer pessoa pode cifrar e decifrar
mensagens. Enquanto a comunicacao precisar permanecer secreta, a chave deve
permanecer secreta.
Cifragem e decifragem com um algoritmo simetrico sao indicados por:
Ee (M ) = C
Dd (C) = M
Onde E e a funcao que cifra a mensagem M utilizando uma chave de cifragem

e para gerar uma mensagem cifrada C. E D e a funcao que decifra a mensagem
2.3 Seguranca 15
cifrada C utilizando uma chave de decifragem d para gerar a mensagem M .
Algoritmos simetricos podem ser divididos em duas categorias(SCHNEIER,

1996). Alguns operam um unico bit(ou as vezes um byte) da mensagem de
cada vez; estes sao chamados algoritmos de fluxo ou cifras de fluxo. Outros
operam sobre a mensagem em grupos de bits. Os grupos de bits sao chamados
de blocos, e os algoritmos sao chamados algoritmos de bloco ou cifras de bloco.
Para algoritmos de computadores modernos, um bloco de tamanho normal e de
64 bits - grande o suficiente para impedir a analise e pequeno o suficiente para
ser viavel.
Na maioria da vezes a mensagem que deve ser cifrada possui o tamanho

maior do que um bloco. A ideia inicial para solucionar o problema seria fatiar a
mensagem em partes do tamanho do bloco. O modo electronic codebook (ECB) faz
exatamente isso, porem tem desvantagens na maioria das aplicacoes, entre elas
o fato de blocos contendo os mesmos dados apresentarem texto cifrado identico.
Este problema e ilustrado pela figura 2.2, onde e possvel reconhecer diversas
caractersticas da imagem quando cifrada em modo ECB. Esse problema motiva
outros metodos de aplicacao de cifras de bloco (modos de operacao) em mensagens
maiores. Alguns modos mais conhecidos sao ECB, CBC, CFB e OFB (RIBEIRO;
ROIHA, 2010).
Figura 2.2: a) Imagem Original; b) Imagem cifrada utilizando o modo ECB;

c) Imagem cifrada utilizando outros modos
O Counter Mode ou CTR e uma simplificacao do modo OFB, onde o bloco

de entrada e um contador, tal que I(j + 1) = Ij + 1(RIBEIRO; ROIHA, 2010). O
modo CTR tem vantagens de eficiencia significantes sobre os modos de operacao
de confidencialidade padronizados, sem reduzir a seguranca. O CTR permite um
acesso aleatorio real. O bloco de texto cifrado i nao necessita ser decifrado antes
do bloco i+1.
2.3 Seguranca 16
Figura 2.3: Counter Mode (CTR)
O Counter Mode emprega uma cifra de bloco como um gerador de chave de

stream. Uma grande vantagem do modo de operacao e a eficiencia em software.
Os processadores modernos suportam configuracoes que envolvem multiplas ins-
trucoes por ciclo de clock, um grande numero de registros e instrucoes SIMD.
Eliminando a dependencia computacional entre Ci e Cj, o modo de operacao
CTR permite efetiva utilizacao nessas caractersticas. E o modo mais eficaz,
quando utilizado em conjunto com o algoritmo de cifra de bloco AES.
2.3.2.1 AES
De acordo com (SOUZA; OLIVEIRA; CUNHA, 2007):
Durante 20 anos, o DES (Data Encryption Standard) foi o algoritmo

padrao usado pelo governo americano para proteger informacoes con-
fidenciais. O surgimento do AES (Advanced Encryption Standard)
decorreu da grande necessidade de se substituir o DES, que se tor-
nou ultrapassado em virtude do pequeno tamanho da chave (56 bits)
utilizada. Para isso, o NIST (National Institute of Standards and
Technology) lancou em 1997 um concurso para adotar o novo algo-
ritmo simetrico, que passaria a se chamar AES (Advanced Encryption
Standard).
O algoritmo deveria atender a alguns requisitos, tais como: direi-

tos autorais livres; divulgacao publica; maior rapidez em relacao ao
3DES; cifrar em blocos de 128 bits com chaves de 128, 192 e 256 bits;
2.3 Seguranca 17
possibilidade de implementacao em software e hardware. Na Primeira

Conferencia dos Candidatos AES, em 98, apresentaram-se 15 candida-
tos e, em 1999, a Segunda Conferencia indicou 5 destes para continuar
na disputa: MARS, RC6, Rijndael, Serpent e Twofish. Em 2000, apos
analises rigorosas de especialistas na area de criptografia, e conhecido
o vencedor: Rijndael. O algoritmo foi criado por Vincent Rijmen e
Joan Daemen, dois belgas. Como tanto na primeira quanto na se-
gunda etapa do concurso, todos os algoritmos descritos atendiam as
exigencias do concurso, a decisao foi tomada com base em outras qua-
lidades como seguranca, flexibilidade, bom desempenho em software
e hardware etc.
Para descrever a estrutura do AES e fundamental termos em mente a definicao

de estado, no contexto do algoritmo. Estado e a matriz de bytes que iremos mani-
pular entre as diversas rodadas, ou rounds, e que portanto sera modificada a cada
etapa(SOUZA; OLIVEIRA; CUNHA, 2007). A cada rodada do algoritmo de cifra-
gem, realizamos 4 etapas: AddRoundKey, SubBytes, ShiftRows e MixColumns.
Na ultima rodada, porem, a operacao MixColumns e suprimida.
SubBytes e a unica transformacaoo da cifra que nao e linear. Cada byte

do estado e substitudo por outro em uma S-box (caixa de substituicao). A
substituicao e feita da seguinte maneira: os quatro primeiros e os quatro ultimos
bits do byte a ser substitudo representam em hexadecimal, respectivamente, a
linha e a coluna onde se encontra o novo byte. Por exemplo, o valor hexadecimal
C2 devera ser substitudo pelo byte que se encontra na linha C e na coluna 2 da
S-box.
Shift Rows e uma etapa simples do algoritmo e consiste em rotacionar a

esquerda as linhas do estado, trocando assim a posicao dos bytes. O numero de
posicoes a serem rotacionadas depende da posicao da linha. Na primeira linha
nao ha rotacionamento; na segunda, os bytes sao rotacionados uma posicao; na
terceira, 2 posicoes e na ultima, 3 posicoes.
Mix Columms - Nesta etapa, cada coluna e operada de forma independente.

Isso quer dizer que o resultado da operacao em uma determinada coluna nao in-
fluencia o resultado nas demais. Entretanto, cada byte de uma coluna influencia
todos os outros bytes da mesma. Nessa etapa, as colunas do estado sao tratadas
como polinomios sobre o corpo finito GF (28 ). Podemos representar essa trans-
0
formacao por uma multiplicacao de matrizes. O novo estado S sera o resultado
da multiplicacao de uma matriz fixa C pela matriz S que representa o estado.
2.3 Seguranca 18
AddRoundKey e uma operacao de XOR entre o estado e a chave da rodada,

que possuem o mesmo numero de bytes. Assim, essa transformacao opera cada
byte individualmente. O XOR e feito byte a byte, ou seja, se sx,y e um byte do
0
estado e kx,y um byte da chave, temos que o byte sx,y do novo estado e igual a
sx,y kx,y .
2.3.3 Criptografia de chave publica e assinaturas digitais
Algoritmos de chave publica (tambem chamados de algoritmos assimetricos)

sao projetados de modo que a chave utilizada para a cifragem e diferente da chave
usada para a decifragem(SCHNEIER, 1996). Alem disso, a chave de decifragem
nao pode(pelo menos, em um perodo de tempo razoavel) ser calculada a partir
da chave de cifragem. Os algoritmos sao chamados de chave publica, porque
a chave de criptografia pode ser divulgada: uma pessoa qualquer pode usar a
chave de cifragem para cifrar uma mensagem, mas apenas uma pessoa especfica
com a chave de decifragem correspondente pode decifrar a mensagem. Nestes
sistemas, a chave de cifragem e muitas vezes chamada de chave publica e a chave
de decifragem e chamada de chave privada. A chave privada e tambem chamada
de chave secreta, mas para evitar confusao com algoritmos simetricos, esse nome
e pouco utilizado.
Criptografia utilizando uma chave publica e e denotada por:
Ee (M ) = C
Dd (C) = M
Onde e e uma chave publica e d a chava privada.
O principal objetivo da criptografia de chave publica e proporcionar priva-

cidade ou confidencialidade. Como a cifragem de A e de conhecimento publico,
apenas a criptografia de chave publica nao e suficiente para fornecer a auten-
ticacao da origem dos dados ou a integridade dos dados. Tais garantias devem
ser fornecidas atraves do uso de tecnicas adicionais, incluindo codigos de auten-
ticacao de mensagem e assinaturas digitais.
A Figura 2.4 mostra um esquema de comunicacao utilizando chave publica.
E possvel ver que a figura 2.4(MENEZES; OORSCHOT; VANSTONE, 1996) e di-

ferente da figura 2.1, que mostra uma comunicacao usando criptografia simetrica.
Na figura 2.4 a chave e transmitida para Alice por um canal nao seguro.
Como a chave nesse caso nao e secreta, qualquer um pode pegar a chave e enviar
2.3 Seguranca 19
Figura 2.4: Esquema de comunicacao entre duas partes usando Criptografia

de Chave Publica
2.3 Seguranca 20
uma mensagem cifrada para Beto, mas so Beto tem a chave privada para decifrar
a mensagem recebida.
Ao que parece, criptografia de chave publica e um sistema ideal, nao necessi-

tando de um canal seguro para passar a chave de criptografia. Isto implicaria que
duas entidades podem se comunicar atraves de um canal inseguro, sem nunca ter
se encontrado para fazer uma troca de chaves. Infelizmente, esse nao e o caso. A
figura 2.5 ilustra como um adversario ativo pode burlar o sistema (isto e, decifrar
mensagens que tem como destino uma outra entidade), sem quebrar o sistema de
criptografia. Isso e um tipo de simulacao e e um exemplo de falha de protocolo.
Neste cenario, o adversario personifica e entidade B, enviando uma chave publica
0
e para a entidade A, que assume(incorretamente) ser a chave publica de B. O
adversario intercepta a mensagem cifrada de A para B, decifra com a sua chave
0
privada d , re-cifra a mensagem usando a chave publica de B, e envia para B. Isso
destaca a necessidade de autenticar chaves publicas para obter a autenticacao da
origem de dados das chaves publicas. A entidade A deve ter certeza de que ela
esta usando a chave publica legtima de B.
2.3.3.1 Assinaturas digitais a partir de criptografia reversvel
Existem algoritmos de chave publica que podem ser utilizados para as assi-
naturas digitais(SCHNEIER, 1996). Em alguns algoritmos a chave publica ou a
chave privada podem ser usadas para a cifragem. Cifrar um documento com sua
chave privada garante uma assinatura digital segura. Em outros casos existe um
algoritmo diferente para assinaturas digitais que nao podem ser utilizados para
cifragem.
O protocolo e simples:
1. Alice cifra o documento com sua chave privada, assinando do documento.
2. Alice envia o documento assinado para Beto.
3. Beto decifra o documento com a chave publica de Alice, verificando a assi-

natura.
2.3.4 Comparacao entre criptografia simetrica e de chave

publica
Criptografia simetrica e criptografia de chave publica possuem uma serie de

vantagens e desvantagens(MENEZES; OORSCHOT; VANSTONE, 1996).
2.3 Seguranca 21
Figura 2.5: Ataque em uma comunicacao de chave publica entre duas partes.
2.3 Seguranca 22
Uma das desvantagens da criptografia de chave publica e o tempo de calculo

da criptografia, que e muito maior do que o tempo necessario na criptografia
simetrica. Outra desvantagem e no tamanho das chaves, que sao muito maiores
e precisam ser autenticadas.
A criptografia simetrica tambem possui suas desvantagens, como por exemplo

a seguranca da chave. Na criptografia de chave simetrica e necessario garantir
que ambos os lados garantam a seguranca da chave. Em sistemas muito grandes,
existem muitos pares de chaves para serem gerenciados e isso torna o sistema
menos efetivo.
As desvantagens que a criptografia simetrica possui sao relativamente peque-

nas para a aplicacao do bootloader. A seguranca das chaves e facil de ser mantida,
ja que uma delas esta dentro do microcontrolador protegida por sistemas de se-
guranca de hardware. A outra chave fica em posse da empresa desenvolvedora do
firmware e nao precisa ser enviada por nenhum canal de comunicacao. O geren-
ciamento de pares tambem nao afeta o sistema do bootloader pois a comunicacao
e feita apenas entre as duas partes, bootloader e empresa, e somente um par de
chaves e necessario.
2.3.5 Funcoes de Resumo Criptografico
Funcao de resumo criptografico pode ser dividida em duas classes: funcoes de

resumo criptografico sem chave, cuja especificacao dita um unico parametro de en-
trada(mensagem), e funcoes de resumo criptografico com chave, cuja especificacao
dita duas entradas distintas, uma mensagem e uma chave secreta(MENEZES;
OORSCHOT; VANSTONE, 1996). Para facilitar a discussao, a funcao de resumo
criptografico e informalmente definida como se segue.
Uma funcao de resumo criptografico e uma funcao h que tem, no mnimo, as

seguintes duas propriedades:
1. Compressao - A funcao h mapeia uma entrada x de um numero finito de

bits, para uma sada de h(x) com um numero fixo de bits.
2. Facilidade de calculo - dado h e uma entrada x, h(x) e facil de calcular.
Existe tambem mais tres caractersticas desejadas:
1. Resistencia a pre-imagem - Para qualquer sada dada, e computacional-

mente inviavel encontrar uma entrada que forneca essa sada.
2.3 Seguranca 23
2. Resistencia a segunda pre-imagem - Dado uma entrada, e computaciona-

mente inviavel encontrar outra entrada que forneca a mesma sada.
3. Resistencia a colisao - E computacionamente inviavel encontrar duas en-

tradas distintas que fornecam a mesma sada.
Existe um grande numero de categorias de funcoes de resumo criptografico,

onde duas delas sao as mais comuns:
Modification Detection Codes(MDCs): Tambem conhecidos como codigos de

deteccao de manipulacao, e menos comumente como codigos de integridade de
mensagens(MICs, em ingles), a proposta de um MDC e (informalmente) fornecer
uma imagem representativa ou resumo criptografico de uma mensagem, satisfa-
zendo propriedades adicionais como mostrado abaixo. O objetivo final e facilitar,
em conjunto com mecanismos adicionais, garantias de integridade de dados como
exigido por aplicacoes especficas. MDCs e uma subclasse de funcoes de resumo
criptografico sem chave, e ela mesmo pode ainda ser classificada;
1. One-way hash functions(OWHFs): para estes, e difcil encontrar uma en-

trada que coincida com um valor de resumo criptografico pre-especificado;
2. Collision resistant hash functions (CRHFs): para estes, e difcil encontrar

quaisquer duas entradas com o mesmo valor de resumo criptografico.
Message Authentication Codes(MACs): A finalidade de um MAC e (informal-

mente) para facilitar, sem a utilizacao de qualquer mecanismo adicional, garantias
relativas tanto a origem de uma mensagem quanto a sua integridade. MACs pos-
suem dois parametros distintos, uma mensagem de entrada e uma chave secreta,
pois eles sao uma subclasse das funcoes de resumo criptografico com chave.
2.3.5.1 SHA-1
Secure Hash Algorithm(SHA-1), foi proposto pelo National Institute for Stan-
dards and Technology (NIST) dos Estados Unidos para certas aplicacoes do go-
verno federal(MENEZES; OORSCHOT; VANSTONE, 1996). As principais diferencas
de SHA-1 a partir de MD4 sao os seguintes:
1. O valor de resumo criptografico e de 160 bits, e cinco variaveis de 32bits

sao usadas.
2.3 Seguranca 24
2. A funcao de compressao tem quatro rodadas, utilizando as funcoes f, g, e h

como se segue: f na primeira rodada, g na terceira, e h na segunda e quarta
rodadas. Cada rodada tem 20 etapas.
3. Dentro da funcao de compressao, cada bloco de mensagem de 16 palavras

e expandido para um bloco de 80 palavras, por um processo em que cada
uma das 64 ultimas palavras, das 80 palavras existentes, e o XOR das 4
palavras anteriores do bloco expandido.
4. O passo principal e modificado da seguinte forma: A unica rotacao usada e

uma rotacao constante de 5 bits; a quinta variavel e adicionada ao resultado
de cada passo; palavras da mensagem do bloco de mensagem expandida sao
acessadas sequencialmente, e C e atualizado conforme B e rotacionado 30
bits para a esquerda.
5. SHA-1 usa quatro constantes diferentes de zero.
A ordenacao de bytes usado para converter um fluxo de bytes em words de

32 bits na especificacao oficial do SHA-1 e big-endian.
2.3.6 Message Authentication Codes (MACs)
Um codigo de autenticacao de mensagem, ou MAC, e uma funcao de resumo

criptografico de mao unica que depende de um chave. So alguem com a mesma
chave pode verificar o resumo criptografico. Sao muito uteis para proporcionar
autenticidade sem sigilo.
MACs podem ser usados para autenticar os arquivos entre usuarios. Eles
tambem podem ser usados por uma unica pessoa para determinar se os proprios
arquivos foram alterados, talvez por um vrus. Um usuario pode calcular o MAC
de seus arquivos e armazenar esse valor em uma tabela. Se o usuario tivesse
usado um funcao de resumo criptografico de mao unica, o vrus poderia calcular
o novo valor de hash apos a infeccao e substituir a entrada da tabela. Um vrus
nao poderia fazer isso com um MAC, porque o vrus nao conhece a chave.
Uma maneira facil de transformar uma funcao de resumo criptografico de mao

unica em um MAC, e cifrar o valor de resumo criptografico com um algoritmo
simetrico. Qualquer MAC pode ser transformado em uma funcao de resumo
criptografico de mao unica, apenas divulgando a chave.
2.3 Seguranca 25
Figura 2.6: Blocos de uma operacao do SHA-1.

2.3 Seguranca 26
2.3.6.1 HMAC-SHA1
HMAC-SHA1 e um algoritmo de resumo criptografico com chave que e cons-

trudo a partir da funcao de resumo criptografico SHA1 e usado como um HMAC,
ou codigo de autenticacao de mensagem baseado em resumo criptografico(MICROSOFT
DEVELOPER NETWORK, 2012). O processo HMAC combina uma chave secreta
com uma mensagem, resume o resultado com a funcao de resumo criptografico,
mistura o resultado com uma chave secreta novamente e, em seguida, aplica a
funcao funcao de resumo criptografico uma segunda vez. O resumo criptografico
de sada e de 160 bits de comprimento.
Um HMAC pode ser usado para determinar se uma mensagem enviada por um
canal inseguro foi violada. O remetente calcula o resumo criptografico dos dados
originais e envia os dados originais e de valor hash como uma unica mensagem.
O receptor recalcula o resumo criptografico na mensagem recebida e verifica se o
HMAC calculad coincide com o HMAC transmitido.
Qualquer alteracao nos dados ou no resumo criptografico ira resultar em uma

diferenca, porque e necessario ter o conhecimento da chave secreta para alterar
a mensagem e reproduzir o resumo criptografico correto. Portanto, se o resumo
criptografico recebido e o calculado forem iguais, a mensagem e autentica.
HMAC-SHA1 aceita chaves de qualquer tamanho, e produz uma sequencia

de resumo criptografico de comprimento 160 bits.
27
3 Desenvolvimento
O desenvolvimento do projeto foi realizado em etapas. Utilizando o metodo

de desenvolvimento agil de software, foi feita uma divisao do projeto em etapas,
que podem ser chamadas de iteracoes, com o intuito de adicionar funcionalidades
ao programa ao final de cada etapa do projeto. Esse metodo de desenvolvimento
e considerado um dos mais eficazes, pois garante o funcionamento de cada uma
das funcoes do programa de forma autonoma, garantindo uma maior facilidade
para encontrar possveis problemas. Outra vantagem e a adicao de novos requi-
sitos, que e muito comum no desenvolvimento de software, pois como o projeto
e dividido em etapas, e preciso apenas adicionar mais uma etapa sem influenciar
nas outras etapas.
3.1 Programa para piscar um LED
A primeira etapa do desenvolvimento do bootloader se baseou no desenvol-

vimento de um programa simples, como um programa que faz piscar um LED.
Como uma primeira etapa, nao era necessario e nem aconselhavel desenvolver uma
funcionalidade do projeto. Primeiro era necessario tomar algumas precaucoes e
garantir o funcionamento de todas as ferramentas que seriam utilizadas durante
o desenvolvimento.
Um programa simples como um pisca LED, nao parece de imediato ser um

muito complicado e nem muito util. Porem o desenvolvimento desse programa
foi essencial para o bom andamento do projeto. Com o programa de pisca LED
tinha-se o objetivo de garantir o funcionamento dos seguintes itens:
Code Warrior
Interface de Debug
Programador(P&E MICROCOMPUTER SYSTEMS, 2009)
Microcontrolador
3.2 Programa com comunicacao serial simples 28
Code Warrior e o nome do ambiente integrado de desenvolvimento fornecido

pela Freescale .
R Alem do funcionamento do itens acima, era necessario fazer
um estudo inicial para se familiarizar com o ambiente e com o microcontrolador.
Funcionalidades do Code Warrior como o Processor Expert, que e uma interface
grafica que facilita a escolha de parametros iniciais do microcontrolador, como
o clock do barramento interno, funcoes de interrupcoes previamente declaradas,
baud rate da porta serial, clock da memoria Flash, area protegida da Flash,
redirecionamento do vetor de interrupcoes entre outras funcionalidades.
Isso tudo foi estudado e testado, porem nao utilizou-se o Processor Expert
por este limitar o desenvolvedor em alguns pontos. Um dos pontos principais era
a geracao de codigos de inicializacao do microcontrolador que nao podiam ser
alterados com a utilizacao do Processor Expert.
3.2 Programa com comunicacao serial simples
Com a finalizacao da primeira etapa, foi possvel comecar a desenvolver uma

das funcionalidades do bootloader sem problemas, ja que a primeira etapa havia
garantido o funcionamento de todas as ferramentas e garantido uma familia-
rizacao com o ambiente.
O desenvolvimento de um programa que realizasse uma comunicacao serial

era de extrema importancia para o projeto todo, pois a comunicacao entre mi-
crocontrolador e modulo e feita atraves de comunicacao serial.
Inicialmente foi desenvolvido um programa de comunicacao serial utilizando

as interrupcoes, o que facilita bastante o trabalho, ja que o microcontrolador pode
continuar rodando um codigo e so pula para a rotina de comunicacao quando
existe realmente algum dado sendo recebido ou enviado. Porem notou-se que a
utilizacao de interrupcoes iriam causar um problema muito grande.
O microcontrolador possui no final da sua memoria um espaco reservado, que

eh chamado de Vetor de Interrupcoes. Quando uma interrupcao e acionada, e
nesse Vetor de Interrupcoes que o microcontrolador vem procurar pelo endereco
que ele deve pular. O problema nesse caso e que no microcontrolador nao haveria
apenas um programa. Haveria o bootloader e o programa do usuario, que pode
ou nao usar interrupcao em seu programa.
O Bootloader nao pode restringir e nem limitar o programa do usuario, por-

tanto, o vetor de interrupcoes nao poderia redirecionar para uma rotina dentro
do bootloader, sendo assim, fez-se necessario o desenvolvimento de uma funcao
para comunicacao serial sem a utilizacao da interrupcao. A nao utilizacao da

interrupcao para a comunicacao serial implica no uso de uma tecnica conhecida
como Pooling. O Pooling nada mais e do que fazer com que o programa fique
percorrendo varias funcoes e verificando se deve entrar na funcao para realizar
alguma tarefa. No caso da comunicacao serial, quando o programa chega ate
a funcao de comunicacao ele verifica se tem algum dado no buffer de entrada e
recebe esse dado, caso nao haja dado nenhum dado ele simplesmente ignora a
funcao e continua a execucao normal do codigo.
3.3 Bootloader que faz uma escrita na memoria

sem comunicacao externa
Uma das funcionalidades do bootloader e a de ser capaz de gravar um dado

na memoria Flash do microcontrolador. A manipulacao da memoria Flash exige
bastante cuidado e trabalho. O microcontrolador trabalha normalmente entre
3,3V e 5V. A memoria Flash tambem trabalha nessa tensao para fins de leitura,
ou seja, e possvel ler uma informacao da memoria Flash com esse nvel de tensao.
Porem esse nvel de tensao nao e suficiente para realizar procedimentos de apaga-
mento e escrita na memoria Flash. O microcontrolador possui internamente um
circuito de pull-up, que faz a tensao de alimentacao da memoria Flash subir ate
12V, que o nvel de tensao necessario para realizar os processos de apagamento e
escrita na Flash. Isso torna possvel a utilizacao de in-application programming,
que e a tecnica de utilizar rotinas do proprio microcontrolador para realizar as
operacoes de escrita na Flash do proprio microcontrolador.
Uma das dificuldades de utilizar o in-application programming e o fato de a

memoria Flash nao ser capaz de realizar leituras com o nvel de tensao utilizado
para realizar a escrita da memoria. A rotina que realiza a escrita da Flash deve
ser executada ao mesmo tempo em que a Flash esta sendo programada e isso e
impossvel de se fazer devido ao nvel de tensao.
Para que seja possvel utilizar o in-application programming e preciso fazer

com que o microcontrolador execute a rotina de escrita da Flash de outro lugar,
ou seja, de outra memoria interna do microcontrolador. O JM32 possui alem da
memoria Flash apenas a memoria RAM e e atraves dela que a rotina de escrita
deve ser executada.
Para fazer com que uma rotina seja executada direto da memoria RAM, e
necessario fazer uma copia dessa rotina, que fica originalmente na Flash, para a
RAM antes de executa-la. Para isso e necessario desenvolver uma rotina que faca
essa copia para a RAM.
Alguns microcontroladores possuem memoria ROM que vem de fabrica pro-

gramada ja com as rotinas de manipulacao da memoria Flash. Assim nao e
preciso a utilizacao de uma outra rotina para fazer a copia da rotina de escrita da
Flash para a RAM, pois a rotina pode ser executada atraves da memoria ROM
sem problemas.
3.3.1 Sequencia de manipulacao da Flash
Uma sequencia de comandos deve ser utilizada para realizar o apagamento

ou escrita na memoria Flash.
A figura 3.1 mostra um fluxograma com a sequencia de comandos que deve

ser utilizada para realizar o apagamento e a escrita na memoria Flash dos micro-
controladores da famlia HCS08 da Fresscale .
R
A sequencia de comando pode ser simplificada em 3 etapas. Sao elas:
1. Escrever um dado em um endereco na Flash. O endereco e o dado dessa

escrita serao gravados no buffer de comando e essa escrita e o primeiro passo
para qualquer sequencia e comando. Para comandos de apagar ou blank
check, o valor do dado nao e importante. Para comandos de apagamento
de pagina, o endereco deve ser qualquer um dentro dos 512 bytes da pagina
da Flash a ser apagada. Para comandos de apagar toda a memoria ou
blank check, o endereco pode ser qualquer um dentro da memoria Flash.
2. Escrever o codigo do comando desejado no FCMD. Os 5 comandos validos

sao blank check ($05), byte program($20), burst program($25), page erase($40)
e mass erase($41). O codigo de comando fica gravado no buffer de comando.
3. Escrever 1 na flag FCBEF do registrador FSTAT para apagar o FCBEF e

registrar o comando.
Existem duas flags no registrador FSTAT que indicam erros durante o pro-
cesso de escrita da Flash. A flag FPVIOL indica um erro de violacao a uma
area protegida. Qualquer outra violacao da sequencia exigida ou outro erro de
condicoes vai setar a flag FACCERR.
A Freescale disponibiliza rotinas otimizadas com a sequencia correta de co-

mandos para todos os microcontroladores. O aplication note (KRENEK, 2009)
Figura 3.1: Fluxograma de escrita e apagamento da memoria Flash dos

microcontroladores da famlia HCS08
3.4 Bootloader atraves de comunicacao serial com o computador 32
fornece todas as rotinas em assembly e e funcao em C para chamar essas rotinas

em assembly. Fornece tambem uma rotina para realizar a copia das funcoes em
assembly para a memoria RAM a fim de possibilitar a utilizacao da mesma.
3.4 Bootloader atraves de comunicacao serial com

o computador
Com a comunicacao serial funcionando perfeitamente e as rotinas de mani-

pulacao da memoria Flash funcionando tambem, passou-se entao para a proxima
etapa do projeto que era o desenvolvimento de um bootloader que fizesse a atua-
lizacao do firmware do microcontrolador de maneira integral e funcional atraves
da comunicacao serial com o computador.
Para que o firmware fosse gravado no microcontrolador era necessario garantir

que o codigo fosse gravado nas posicoes certas. Para saber onde cada byte do
firmware deveria ser gravado foi necessario estudar como o Code Warrior gerava
a imagem do firmware para a posterior programacao do microcontrolador.
3.4.1 S19
O S19, tambem conhecido como SREC, e um formato de arquivo criado pela

Motorola para utilizacao em programacao de processadores. Esse formato de
arquivo codifica dados binarios em forma de texto utilizando a linguagem ASCII.
Esse formato de arquivo possui o nome de S19 pois o arquivo e dividido em blocos,
ou linhas, que sao iniciados pelas marcacoes S1, S2, S3, ..., S9. Cada uma dessas
marcacoes serve para indicar o que aquele bloco representa dentro do arquivo.
A marcacao S0 indica que o bloco contem informacoes sobre versao do arquivo,

nome do arquivo entre outras informacoes.
As marcacoes S1, S2, S3 indicam que o bloco contem os dados do programa.

Cada uma das marcacoes e utilizada dependendo do tamanho do endereco do
sistema em questao. A marcacao S1 e utilizada para sistemas com enderecos de
16bits, S2 e utilizada para enderecos com 24bits e S3 e utilizada para sistemas
com 32bits de endereco.
A marcacao S5 indica a quantidade de marcacoes S1, S2 e S3 que foram utili-

zadas anteriormente. Nao ha nenhum tipo de dado associado com essa marcacao.
As marcacoes S7, S8, S9 podem conter informacoes do endereco inicial do

programa.
Apos cada uma dessas marcacoes, o bloco apresenta outros dgitos em hexa-
decimal, chamados de Byte Count. O Byte Count indica a quantidade de bytes,
par de dgitos em hexa, que vem a seguir no bloco, includo o endereco, dados e
checksum.
Logo apos o Byte Count vem o Endereco. O Endereco pode consistir de 4,

6 ou 8 dgitos em hexadecimal, dependendo do sistema em que o programa sera
implementado.
Apos o Endereco vem os Dados do programa.
Por fim, os dois ultimos dgitos em hexadecimal compoe o Checksum. O

Checksum e composto do complemento de 1 do byte menos significativo da soma
dos valores do Byte Count, Endereco e Dados.
A figura 3.2 mostra um arquivo destacando cada setor dos blocos do arquivo.
Figura 3.2: S19 com os setores destacados
Assim e possvel desenvolver um programa que recebe esse arquivo de forma

serial, tratando as informacoes que nao sao relevantes e garantindo a programacao
dos bytes nos enderecos corretos.
3.4.2 Protecao da Memoria e Redirecionamento do Vetor

de Interrupcoes
O bootloader deve ficar em algum lugar reservado da memoria, preferenci-

almente em um lugar onde esteja protegido contra escrita e/ou apagamento. O
microcontrolador utilizado oferece opcoes de seguranca contra violacoes dos da-
dos da memoria Flash, porem esta seguranca so pode ser adicionada no final da
memoria Flash. O desenvolvedor pode escolher uma quantidade X de paginas da
memoria Flash que pretende proteger. As paginas que serao protegidas serao as
ultimas X paginas da memoria. Assim o melhor lugar para colocar o codigo do
bootloader e no final da memoria, garantindo assim a integridade do bootloader.
A ultima pagina da memoria Flash porem, possui alguns enderecos que sao
utilizados pelo microcontrolador. O Vetor de Interupcoes e um deles e com o
sistema de protecao habilitado, por menor que seja a quantidade de memoria pro-
tegida certamente esses enderecos estarao protegidos tambem. Como o usuario
precisara utilizar o vetor de interrupcoes no programa em que estiver desenvol-
vendo, e preciso liberar o vetor de interrupcoes para que o usuario possa altera-
lo da maneira que quiser. Para isso o microcontrolador possui uma funcao de
redirecionamento do vetor de interrupcoes. Esse redirecionamento so pode ser
utilizado quando alguma parte da memoria Flash esta protegida. Dessa maneira,
o microcontrolador redireciona o vetor de interrupcoes para as ultimas posicoes
da memoria que nao estejam protegidas.
3.4.3 Conversao ASCII para Hexadecimal
O arquivo S19 utiliza a codificacao ASCII para ser mais legvel para o usuario
na identificacao dos dados. Para gravar os dados do arquivo S19 no microcontro-
lador e necessario fazer a conversao de ASCII para Hexadecimal. Um endereco
do microcontrolador que precise ser gravado com o byte A6, sera visualizado
no arquivo S19 como A6 utilizando um editor de texto comum. Porem os edi-
tores de texto comuns utilizam tambem a codificacao ASCII para visualizacao
dos arquivos. Se for utilizado um editor que mostre bit a bit como esta dividido
o arquivo, e possvel ver que na verdade o que era visto como A6 sao dois
bytes na verdade, 01000001 e 00110110. O que realmente deve ser gravado
na memoria do microcontrolador e apenas o byte 10100110.
Assim e necessario fazer uma conversao dos dados no momento em que esse
e transmitido para o microcontrolador e antes de ser gravado na memoria. Para
isso foi desenvolvida uma funcao que identifica o dado que esta chegando na
codificacao ASCII e converte-lo para Hexadecimal.
Os valores Hexadecimais vao de 0 a 9 e depois de A a F. Os valores numericos

de 0 a 9 na tabela ASCII correspondem aos valores 0x30 a 0x39 em Hexadecimal.
Para transformar um valor numerico de ASCII para Hexa entao e necessario
apenas subtrair o valor 0x30. As letras de A a F na tabela ASCII correspondem
aos valores 0x41 a 0x46 em Hexa. E necessario entao subtrair o valor 0x37.
Mas so isso nao e suficiente para que a conversao funcione. Ainda e necessario
concatenar os valores de dois bytes em apenas 1 byte. Por exemplo, o byte
A6 em ASCII que e na verdade 01000001 e 00110110 em Hexadecimal.
Aplicando as regras citadas acima, continuaria ainda sendo formado por dois byte
00001010 e 00000110, que representam em Hexa os valores 0A e 06. E
preciso entao deslocar o primeiro byte em 4 casas binarias para a esquerda e soma-
lo ao segundo apos realizadas as operacoes de conversao. Assim o byte 0A que
em binario e 00001010, quando deslocado de 4 casas para a esquerda ficaria
A0 em Hexa e 10100000 em binario. Assim somando o byte 10100000
com o byte 00000110 e obtido o valor correto que e 10100110 ou A6 em
Hexadecimal.
3.4.4 Programacao por linhas
Com a conversao funcionando perfeitamente faltava apenas garantir a correta

leitura dos enderecos e a correta gravacao do dado no respectivo endereco.
Primeiramente era necessario que a memoria fosse completamente apagada

antes de comecar qualquer tipo de programacao do firmware. Isso era feito du-
rante o recebimento da primeira linha do arquivo S19, pois esta linha alem de nao
possuir nenhum dado para ser gravado na memoria, ela tem um tamanho maior
do que as outras, o que ajuda pois o apagamento da memoria demora um tempo
consideravel e deve ser completado antes da transmissao da primeira linha.
Nesse momento surgiu um pequeno problema, pois com uma comunicacao

na velocidade de 115200bps nao havia tempo suficiente para realizar o apaga-
mento da memoria durante a transmissao da primeira linha. Foi necessario entao
diminuir a velocidade de comunicacao para 19200bps. Uma solucao melhor foi
pensada nesse momento porem so foi colocada em pratica em outra etapa do
desenvolvimento.
Com a memoria totalmente apagada era necessario realizar a escrita dos dados
do firmware na memoria. A rotina que foi criada para fazer essa funcao utilizava-
se das rotinas de comunicacao serial e tambem da rotina de conversao de dados.
Apos isso a rotina aguardava ate o momento em que recebece o marcador S1,
o que indica que a linha possui dados de programa que devem ser gravados na
memoria. Logo apos receber o S1, a rotina guardava o valor do Byte Count em
uma variavel para utilizar no momento da escrita. Apos isso era detectado o
endereco onde deveriam ser guardados os bytes que viriam a seguir. Assim era
possvel realizar a escrita na memoria a partir do endereco recebido e a quantidade
de bytes que deveriam ser gravados. Apos isso a rotina voltava a esperar pelo
marcador S1. A rotina era finalizada no momento em que recebia um marcador
S9, que indicava que todos os dados de programa ja haviam sido transmitidos e
gravados na memoria.
3.4.5 Software Reset
Apos ter finalizado a programacao do firmware no microcontrolador era ne-

cessario executar o programa que foi gravado na memoria do microcontrolador.
Isso pode ser feito pulando para o incio do programa que foi gravado. Para fazer
isso e necessario olhar para o vetor de interrupcoes do programa do usuario, mais
precisamente para o Vetor de Reset, que indica qual e o endereco do incio do
programa do usuario.
Antes de pular para o codigo do usuario, varias precaucoes devem ser toma-
das. Como por exemplo a pilha, que pode estar cheia por ter sido utilizada pelo
bootloader, ou entao as flags de status do microcontrolador devem ser zeradas
entre outras pequenas coisas. A melhor maneira de se prevenir qualquer problema
e executando um reset no microcontrolador e criando uma rotina de verificacao
logo no inicio do codigo do bootloader, antes mesmo de fazer qualquer chamada
de funcao ou outra operacao. Esse rotina de verificacao deve ser capaz de iden-
tificar se ha firmware programado no microcontrolador, ou seja, se o codigo do
usuario ja foi inserido. Caso haja codigo do usuario essa rotina deve pular para
o incio do codigo do usuario, caso contrario deve entrar no bootloader. A figura
3.3 mostra um fluxograma da rotina de verificacao.
Para realizar um reset via software, e necessario executar um OpCode Ile-

gal. Logo apos a atualizacao ser completada, e utilizado o comando asm DCB
0x8D;. O DCB e uma diretiva em assembly utilizada para escrever um byte na
memoria. O byte 0x8D nao pertence a lista de instrucoes do microcontrolador e
e considerado um OpCode Ilegal, causa assim um reset no microcontrolador toda
3.5 Adicao de criptografia e sistemas de seguranca contra copia de informacoes 37
Figura 3.3: Fluxograma da rotina de verificacao
vez que e executado.
3.5 Adicao de criptografia e sistemas de segu-

ranca contra copia de informacoes
Com o bootloader que realiza a comunicacao atraves do computador funcio-

nando de maneira satisfatoria, foi dado incio a uma nova etapa do projeto. Nessa
nova etapa do projeto, existiam alguns objetivos a serem cumpridos. A maior
parte dos objetivos sao relacionados a seguranca, tanto na protecao contra copia
do codigo que sera transmitido para o microcontrolador, quanto na garantia da
autenticidade e integridade do codigo que ele ira receber. A utilizacao de tecnicas
criptograficas sao escenciais para atingir os objetivos pretendidos.
Para garantir a protecao necessaria do firmware que sera gravado pelo bootlo-
ader foi utilizado o algoritmo de criptografia simetrica AES(Advanced Encryption
Standard). Para garantir a autenticidade e integridade do codigo que o bootloa-
der ira receber, foi utilizado um codigo de autenticacao de mensagem baseado na
funcao de resumo criptografico SHA1, chamado de HMAC-SHA1.
Para as duas tecnicas e necessario realizar varias operacoes matematicas,

que exigem entao um espaco de memoria para armazenar o codigo durante as
operacoes e devidas verificacoes. O microcontrolador pode receber firmwares
de ate 32KB, que e o tamanho da memoria Flash, porem so possui 4KB de
memoria RAM, que e a memoria que armazenaria o codigo durante as operacoes
de criptografia e as verificacoes de integridade e autenticidade. Como nao e

possvel armazenar o codigo todo na memoria RAM, utilizou-se de tecnicas de
particionamento do codigo a ser enviado para o microcontrolador.
Partindo dessa ideia, foi desenvolvido um programa para computador que

utilizava a imagem do firmware e particionava esse arquivo em blocos de ate 1KB
de dados. Durante o processo de particionamento do firmware em blocos, foram
eliminadas todas as caractersticas do formato de arquivo S19. Todo o tratamento
que era feito dentro do bootloader foi transferido para o software. A conversao
ASCII-HEX foi feita fora do bootloader e as informacoes de endereco dos dados
foram colocadas no incio do arquivo criado. Essa atitude diminuiu bastante o
tamanho do bootloader, aumentou a velocidade de execucao e diminuiu a quan-
tidade de dados transmitidos, ja que a cada 2 bytes em ASCII era transmitido
apenas 1 byte em Hexadecimal.
Alem dos arquivos de dados, foi criado tambem um arquivo de controle, com
o objetivo de informar o bootloader caractersticas do firmware que sera envi-
ado. Essas caractersticas sao: Cabecalho, Tamanho do Arquivo, ID do Produto,
Versao do Firmware, Menor Endereco dos Dados, Maior Endereco dos Dados,
Quantidade de Blocos em que o firmware foi dividido.
Cabecalho e utilizado para dar incio a transmissao/recepcao e prevenir a

utilizacao de arquivos irregulares. O Cabecalho ocupa 3 bytes.
Tamanho do Arquivo e utilizado pelo bootloader para garantir que o ar-

quivo de controle tenha o tamanho pre-estabelecido, que e fixo independente
do firmware. O Tamanho do Arquivo ocupa 2 bytes.
ID do Produto e informado no arquivo de controle para que o bootloader

possa verificar se o firmware que esta sendo fornecido e do produto em que ele
esta inserido, prevenindo assim uma possvel programacao de firmware de um
outro produto. ID do Produto ocupa 4 bytes.
Versao do Firmware e utilizada para garantir que ao se fazer uma atualizacao

de firmware, nao seja utilizado uma versao mais antiga do firmware que ja esta
programado no microcontrolador. Versao do Firmware ocupa 2 bytes.
Menor e o Maior Endereco dos Dados sao utilizados pelo bootloader para
garantir que esses enderecos estejam na area livre da memoria Flash. Como
o bootloader fica no final da memoria e a memoria Flash tem como o primeiro
endereco o 0x8000, e necessario que o firmware que sera programado esteja a patir
do endereco 0x8000 e nao ultrapasse o endereco de onde e o incio do bootloader.
Menor e Maior endereco utilizam 2 bytes cada um.
Quantidade de Blocos e utilizado pelo bootloader para que ele tenha conheci-
mento de quantos blocos ele vai atualizar e, portanto, quando terminar o processo
de atualizacao. Quantidade de Blocos ocupa 1 byte.
Alem disso, o arquivo de controle conta com dois vetores de 20 bytes cor-
respondentes ao HMAC-SHA1. O primeiro vetor corresponde ao HMAC-SHA1
do firmware por inteiro, que sera utilizado para verificacao da integridade do
firmware que esta gravado no microcontrolador durante o processo de iniciacao
do programa. O segundo vetor e o HMAC-SHA1 do arquivo de controle e e cal-
culado a partir das seguintes informacoes: ID do Produto, Versao do Firmware,
Menor Endereco dos Dados, Maior Endereco dos Dados, Quantidade de Blocos e
HMAC-SHA1 geral do firmware.
Figura 3.4: Arquivo de controle com os setores destacados
Os blocos de dados do firmware tambem possuem a mesma estrutura inicial

do arquivo de controle, porem com algumas diferencas. Menor e Maior Endereco
de Dados sao chamados de Endereco Inicial e Endereco Final e indicam os en-
derecos inicial e final dos dados contidos naquele bloco. Outra diferenca e a
informacao Quantidade de Blocos, que e chamada de Numero do Bloco e, como
o proprio nome ja deixa claro, indica qual e o numero do bloco, facilitando assim
o gerenciamento do bootloader.
Alem dessas informacoes os blocos de dados possuem tambem uma quantidade

de dados que pode chegar ate a 1KB. Esses dados sao cifrados pelo programa no
computador utilizando o AES e uma chave secreta, que e a mesma que esta
programada no bootloader. No final do arquivo de bloco de dados esta o HMAC-
SHA1 do arquivo, que e calculado a partir das seguintes informacoes: ID do
Produto, Versao do Firmware, Endereco Inicial, Endereco Final, Numero do Bloco
e os dados cifrados.
3.5.1 Verificacao de integridade e segmentacao da memoria

do microcontrolador
Com posse das rotinas que geram o HMAC-SHA1, teve-se a ideia de utiliza-las
para fazer a verificacao da integridade do firmware no momento da inicializacao
do microcontrolador, mais exatamente no momento em que verifica se deve ou
nao entrar no modo bootloader.
Dessa maneira era necessario colocar o HMAC-SHA1 geral do firmware, cal-

culado pelo programa no computador, em alguma posicao da memoria para com-
paracao. Foi criado entao um setor de 20 bytes no incio da memoria do microcon-
trolador, indo de 0x8000 a 0x8013. Como esses 20 bytes sao o resultado gerado
pela funcao do HMAC, ele nao pode ser incluido no momento da verificacao.
A versao do firmware tambem deve ficar em algum lugar da memoria onde o

bootloader tenha capacidade de altera-la. Foi criado entao um setor de 44 bytes
apos o setor do HMAC-SHA1 geral para utilizacao de dados de verificacao e de
seguranca quaisquer, indo de 0x8014 a 0x803F. Um outro dado de seguranca que
e colocado nessa area e o menor endereco do programa do usuario.
Esse valos do menor endereco e necessario pois sentiu-se a necessidade de

garantir ao usuario que ele tenha autonomia para criar um setor de dados onde
ele possa alterar sem se preocupar com o HMAC-SHA1 geral do firmware. Por
isso foi criado um Setor de Dados, que nao e utilizado na geracao do HMAC-
SHA1, que o usuario pode definir o tamanho e alterar os dados da maneira que
pretender. Portanto o Setor de Dados vai do endereco 0x8040 a um endereco X.
Apos esse setor vem o firmware do usuario, que vai de X+1 ate 0xCFFF que
e o ultimo byte antes do incio do bootloader.
Segmentacao da memoria Flash

Setor Endereco Endereco Objetivo
Inicial Final
HMAC-SHA1 Geral 0x8000 0x8013 Verificar integridade do firmware no
momento da iniciacao do microcon-
trolador
Dados de Segu- 0x8014 0x803F Permitir verificacao de versao, auto-
ranca/Verificacao nomia para o usuario criar setor de
dados, entre outras possveis imple-
mentacoes futuras
Setor de Dados 0x8040 X Permitir o usuario a utilizar a
memoria Flash com dados de inte-
resse particular
Firmware X+1 D3FF Firmware do programa do usuario
Bootloader D400 0xFFFF Espaco de memoria protegido con-
tendo o Bootloader
Tabela 3.1: Segmentacao da memoria Flash
3.5.2 Atualizacao com firmware particionado e cifrado
Utilizou-se uma tecnica conhecida como Maquina de Estados, onde a execucao

do programa e executada passo a passo, ou estado a estado. Apos executar uma
etapa do programa, ele passa para o proximo passo ou estado.
Quando o programa entra no modo bootloader, a primeira informacao requisi-

tada pelo bootloader e o Arquivo de Controle. Para receber o arquivo de controle
corretamente, e necessario que os 3 primeiros bytes, que compoem o cabecalho
estejam corretos, isso e, possuam os valores de 0x13, 0x37 e 0x01. Caso isso nao
ocorra, o bootloader ignora o arquivo e interrompe o processo de atualizacao,
antes mesmo de apagar o firmware antigo.
Quando o bootloader recebe o arquivo de controle, primeiramente, ele coloca o

arquivo recebido em um buffer da memoria RAM e depois calcula o HMAC-SHA1
das informacoes recebidas e compara com os ultimos 20 bytes do arquivo. Caso
algum dado tenha sido corrompido durante a transmissao, seja o corrompimento
acidental ou intencional, o valor do HMAC-SHA1 nao sera o mesmo, portanto o
arquivo sera descartado e o processo de atualizacao sera interrompido.
Caso a comparacao entre os vetores seja aprovada, isso garante a autentici-

dade e a integridade do arquivo e o bootloader passa para a proxima etapa, que e
a verificacao do ID do Produto. A informacao de ID do Produto fica gravada no
espaco de memoria reservado para o bootloader, impossibilitando assim que seja
alterado apos sair da fabrica. Caso a comparacao seja positiva, ou seja, caso os
dois valores sejam iguais, o bootloader continua com o processo de atualizacao.
3.6 Bootloader com comunicacao via internet 42
A proxima etapa e a verificacao da Versao do Firmware. A informacao da

versao de firmware fica gravada no setor de Dados de Seguranca/Verificacao,
podendo assim ser alterada pelo bootloader apos cada atualizacao. Para que o
bootloader continue com a atualizacao do firmware, e necessario que a Versao do
Firmware do arquivo de controle seja maior do que a que esta no microcontrolador.
Apos isso, e feita a verificacao da faixa de enderecos, para garantir que e

possvel colocar o firmware dentro do microcontrolador.
Somente se todas essas verificacoes forem atendidas, o bootloader ira real-

mente apagar o firmware existente no microcontrolador. Apos apagar o firmware
existentente, o bootloader ira gravar o HMAC-SHA1 geral do firmware que veio
no arquivo do controle. Esse HMAC-SHA1 e gravado nos primeiros 20 bytes da
memoria Flash para posterior verificacao.
Apos isso o bootloader ira requisitar o arquivo com o primeiro bloco de dados
do firmware. Da mesma maneira que faz com o arquivo de controle, o bootloader
faz todas as verificacoes tambem nos blocos de dados. Apos todas as verificacoes
serem feitas, o bootloader vai gravar os dados do bloco na memoria do microcon-
trolador. Antes de gravar os dados, o bootloader executa a funcao para decifrar
os dados.
Apos finalizar a escrita dos dados, o bootloader verifica se aquele bloco era o
ultimo bloco do firmware. Caso nao seja ela requisita o proximo bloco. Quando
termina de atualizar o ultimo bloco, o bootloader executa um Opcode Ilegal para
gerar um reset forcado no microcontrolador, fazendo assim com que ele comece a
executar o codigo desde o incio, passando pela rotina de verificacao de integridade
do firmware.
3.6 Bootloader com comunicacao via internet
A comunicacao serial feita entre o microcontrolador e o computador e bastante

simples, pois o microcontrolador envia uma frase pelo canal serial e entra em uma
rotina onde aguarda a recepcao do arquivo, que e enviada de forma manual pelo
usuario. Apesar do meio de comunicacao entre o microcontrolador e o modulo
celular ser a comunicacao serial, existe um protocolo que deve ser seguido e uma
lista enorme de comandos AT que devem ser utilizados para estabelecer uma
comunicacao.
O bootloader nesse ponto ja estava robusto e funcionando perfeitamente, era

necessario entao adicionar apenas os passos de registro do modulo GSM na rede,
conexao com o servidor FTP e substituir a maneira que o bootloader fazia a

requisicao do arquivo.
Para se comunicar com o modulo celular o microcontrolador alem de enviar

comandos, tem que estar preparado para receber diversas respostas do modulo
celular. Foi desenvolvida uma rotina de recepcao de dados onde ja era feita toda
a verificacao da resposta e retornava para o programa o que a resposta significava
e o programa tomaria as devidas acoes.
O modulo celular utilizado possui ajuste automatico de baud rate, ou seja, nao
e preciso configura-lo com um baud rate especfico. Uma pratica interessante e
enviar alguns comandos basicos no incio da comunicacao para que o modulo tenha
um tempo mnimo para detectar qual e o baud rate que esta sendo utilizado pelo
outro lado e se auto ajustar. Para garantir o auto ajuste, no incio da comunicacao
entre microcontrolador e modulo celular, sao enviados pelo microcontrolador 3
comandos AT simples. O comando AT so faz com que o modulo responda OK e
tem como objetivo, na maioria das vezes, verificar se o modulo esta respondendo
corretamente.
O modulo celular vem de fabrica configurado com ECO. Quando o ECO esta
habilitado no modulo celular, ele envia de volta para o microcontrolador o co-
mando que recebeu quase que instantaneamente e so depois envia a resposta. A
vantagem de se usar o ECO e ter a certeza que o modulo celular recebeu o co-
mando que foi enviado, pois como algumas respostas podem demorar para serem
dadas, pode-se reenviar o comando em um tempo bem menor se for verificado
que o modulo nao recebeu o comando. Como a rotina que foi desenvolvida nao
leva em consideracao o ECO, desabilitou-se o ECO com o comando ATE0.
Outra configuracao de fabrica do modulo celular e o registro automatico da

rede GSM. Esse registro demora menos de 1 minuto e se o modulo celular ja esti-
vesse ligado antes do incio do bootloader comecar a rodar, existe a possibilidade
de ele ja estar registrado. Dessa forma, um comando AT e utilizado para saber se
o modulo ja esta registrado ou nao, caso ainda nao esteja registrado, aguarda-se
um tempo o comando e enviado novamente ate receber uma resposta afirmativa.
O comando utilizado para fazer essa verificacao e o AT+CREG?.
Apos o modulo estar registrado na rede GSM, e necessario conecta-lo na rede

GPRS da operadora. E atraves do GPRS que o modulo se conecta a internet
e ao servidor de FTP que hospedara os arquivos do firmware. Antes de ativar
o GPRS e feita uma verificacao com o comando AT+CGATT?. Caso o GPRS
ainda nao esteja ativo, e utilizado o comando AT+CGATT=1.
Apos ativar o GPRS e preciso conecta-lo na operadora. Para conecta-lo e

necessario programar o APN da operadora do chip que esta sendo utilizado.
Para programar o APN das operadoras da Brasil, sao necessarias tres informacoes,
Endereco APN, Usuario e Senha. Os comando usados para a operadora TIM, por
exemplo, sao AT+UPSD=0,1,tim.br para o endereco, AT+UPSD=0,2,tim
para o usuario e AT+UPSD=0,3,tim para a senha. Com o APN programado,
foi utilizado o comando AT+UPSDA=0,3 para ativar a conexao GPRS.
Com o GPRS ativo e conectado, e possvel acessar um servidor de FTP utili-

zando o modulo celular. Para acessar um servidor FTP e preciso primeiro progra-
mar o endereco do servidor FTP, Usuario e Senha. Os comandos utilizados sao
AT+UFTP=1,servidorftp.com.br para o endereco, AT+UFTP=2,user para
o usuario e AT+UFTP=3,pass para a senha. Com o servidor programado no
modulo celular, foi entao utilizado o comando AT+UFTPC=1 para realizar a
conexao com o servidor.
No servidor FTP, foi criada uma pasta onde os arquivos do firmware seriam
colocados. Apos o modulo celular se conectar no servidor FTP, ele deveria acessar
a pasta onde os arquivos estavam. Para acessar uma pasta dentro do servidor de
FTP existe o comando AT+UFTPC=8,NomeDaPasta. Apos acessar a pasta
era possvel fazer o download de qualquer arquivo que estivesse dentro da pasta.
Ate esse momento, nao havia sido feita nenhuma alteracao no codigo do
bootloader desenvolvido na etapa anterior, apenas os comandos iniciais de co-
municacao com o modulo GSM tinham sido adicionados. Porem a partir desse
momento, a maneira como o bootloader requisita os arquivos deveria ser alte-
rada. O modulo celular fornece todo o apoio necessario para a comunicacao com
um servidor FTP. Fornece tambem comandos para fazer o download de arqui-
vos do servidor. Os arquivos baixados do servidor FTP sao armazenados em uma
memoria nao volatil do modulo celular. Um outro comando deve ser utilizado para
fazer com que o modulo celular envie o arquivo para o microcontrolador. Existe
tambem um comando utilizado para deletar o arquivo de dentro da memoria do
modulo celular.
Dessa forma, foram feitas as alteracoes necessarias para fazer com que o boo-
tloader requisitasse o arquivo atraves do modulo celular. Onde o bootloader sim-
plesmente enviava uma frase na porta seria requisitando o arquivo, foram adicio-
nados alguns passos. Primeiramente utilizou-se o comando AT+UDELFILE=arquivo
para deletar um arquivo da memoria do modulo celular. Esse foi o primeiro passo
utilizado pois nao e possvel baixar um arquivo do servidor se ja existir algum ar-
quivo com o mesmo nome dentro do modulo celular. Depois utilizou-se o comando
AT+UFTPC=4,arquivo para realizar o download do arquivo e armazena-lo na
memoria interna do modulo celular. Apos o download ser finalizado, utilizou-se o
comando AT+URDFILE=arquivo para receber o arquivo que esta no modulo
celular. Feito isso, o restante da rotina permaneceu a mesma da etapa anterior,
onde todas as verificacoes necessarias eram feitas e as devidas acoes eram toma-
das. Um outro comando para deletar o arquivo foi adicionado, apos o termino
das verificacoes e devidas acoes, para liberar o espaco na memoria do modulo
celular.
47
4 Resultado
4.1 Tamanho do bootloader
O tamanho do codigo do bootloader pode ser considerado um dos resultados

de maior interesse do projeto. Como o bootloader e executado somente quando
uma atualizacao se faz necessaria, pretende-se que ele seja o menor possvel para
que deixe a maior quantidade possvel de memoria livre para o firmware principal.
O codigo no total utilizou 11188 bytes. Como o sistema de protecao da

memoria do microcontrolador so permite proteger paginas inteiras de 512 bytes
da memoria Flash, pode-se considerar que o bootloader utilizou no total uma
quantidade de 11264 bytes ou 11kB.
Figura 4.1: Tamanho do codigo do bootloader
A adicao de seguranca ao bootloader e sem duvida o principal responsavel

pelo aumento significativo do tamanho do codigo. As rotinas utilizadas para
fins de seguranca ocupam 5495 bytes sendo que 1767 bytes sao ocupados pelo
algoritmo AES e 3728 bytes sao ocupados pelo algoritmo HMAC-SHA1.
Como o tamanho do codigo ficou relativamente grande em relacao a quan-

tidade de memoria do microcontrolador, foram pensadas formas de diminuir o
tamanho do codigo para futuras aplicacoes. A primeira opcao para diminuir o
espaco ocupado pelo bootloader e ativar as otmizacoes do compilador, optando
por uma compilacao que forneca o menor codigo possvel. Uma segunda opcao
seria uma revisao completa do codigo procurando pontos que podem ser otimi-
4.2 Tempo de execucao 48
zados. Um exemplo e a utilizacao de Strings que ocupam espaco na memoria

e se houver uma repeticao dessa string ela tambem sera gravada na memoria
utilizando assim o dobro de memoria necessaria. Para que isso nao ocorra, e
necessario usar a diretiva #define, e definir assim somente uma vez a string que
sera usa mais de uma vez no codigo. Isso foi feito durante o desenvolvimento
mas e possvel ainda diminuir a quantidade de bytes usados pelos comandos ATs,
definindo a parte AT+ somente uma vez.
Uma terceira opcao, essa bem mais trabalhosa, e a reescrita do codigo em

assembly. A escrita do codigo em assembly diminui bastante o codigo do pro-
grama pois elimina possveis excessos do compilador. E por fim, a substituicao
do microcontrolador e da arquitetura utilizada. O microcontrolador de 8 bits nao
possui quase nenhuma instrucao para manipulacao de valores maiores que 8 bits.
Um exemplo e uma simples multiplicacao por um numero maior que 256, que
gera uma sequencia de instrucoes para que o microcontrolador consiga realizar
tal operacao. Os algortimos criptograficos utilizados trabalham com numeros
enormes, o que faz com que o codigo fique muito grande na arquitetura de 8 bits.
O calculo do HMAC-SHA1 utiliza deslocamento de alguns bits em variaveis de 32
bits e como o processador nao possui instrucao preparada para isso, uma sequencia
muito grande de codigo e gerada para realizar os deslocamentos. Por exemplo
o deslocamento de 5 bits em uma variavel de 32 bits utilizaria primeiramente 4
instrucoes de deslocamento de 1 bit em cada um dos 4 bytes da variavel, utilizaria
almus instrucoes intermediarias para deslocar os bits para os bytes adjacentes.
Isso seria repetido 5 vezes para realizar a operacao, entao enquanto um microcon-
trolador com uma arquitetura de 32 bits ou com um conjunto de instrucoes mais
completo faria isso em uma ou algumas instrucoes, o microcontrolador utilizado
precisa de mais de 20 instrucoes para realizar tal operacao.
4.2 Tempo de execucao
O tempo da atualizacao do firmware pode variar bastante dependendo do

tamanho do firmware e do estado do modulo celular no momento do incio da
execucao do bootloader. Varias atualizacoes foram simuladas com um firmware de
aproximadamente 2kB. O tempo em media, sem levar em consideracao o tempo
de download dos arquivos e de aproximadamente 40 segundos. O firmware de
testes utilizado para fazer as atualizacoes levava em media, somando todas as
partes, 10 segundos para ser baixado.
O problema da arquitetura discutido na secao acima tambem influencia muito

4.2 Tempo de execucao 49
no tempo de execucao do codigo. A rotina de verificacao inicial do bootloader

exige muito processamento do microcontrolador pois verifica praticamente 20kB
de memoria. O tempo que foi medido para a execucao dessa verificacao e de 6,5
segundos. Esse tempo e muito grande para uma rotina que sera executada toda
vez em que o equipamento for ligado.
Inicialmente o tempo de verificacao estava em torno de 50 segundos. Duas

acoes foram tomadas para tentar minimizar ao maximo esse tempo de verificacao.
Primeiramente foi alterado a velocidade do clock do barramento do microcontro-
lador, para que a velocidade fosse a maxima suportada pelo microcontrolador. A
segunda atitude foi a reescrita de partes do algoritmo que calcula o HMAC-SHA1,
mais especificamente as funcoes que faziam o deslocamento de 1, 5 e 30 bits em
variaveis de 32 bits.
50
5 Conclusao
O desenvolvimento do projeto apresentado neste trabalho acrescentou muito

conhecimento tecnico, tanto teorico como pratico. O projeto foi desenvolvido
baseando-se em um unico microcontrolador e suas caractersticas especficas.
Porem a cada etapa do projeto, a cada rotina desenvolvida, cada problema so-
lucionado, foi adquirido conhecimento suficiente para ser utilizado em qualquer
outro modelo de bootloader, ou ate mesmo em qualquer outro projeto de desen-
volvimento de eletronica que utilize os conceitos aqui abordados.
A tecnologia cresce em uma velocidade surpreendente no mundo inteiro. O

projeto foi desenvolvido baseando-se em um microcontrolador que nao esta entre
os mais poderosos do mercado e isso e, de certo modo, uma otima maneira para
adquirir uma bagagem solida sobre microcontroladores, que vao evoluindo ano
apos ano mas nunca mudando completamente o funcionamento.
O bootloader desenvolvido pode ser migrado para, provavelmente, qualquer

outro modelo de microcontrolador que possuam as mesmas caractersticas ou su-
periores ao utilizado nesse projeto. Dependendo da arquitetura do microcontro-
lador, fabricante, capacidade de armazenamento e capacidade de processamento,
a dificuldade da transacao entre plataformas diferentes pode variar bastante.
Para microcontroladores da mesma famlia(HCS08) a utilizacao do bootloa-

der e bastante simples, bastando apenas pequenas alteracoes na segmentacao da
memoria Flash. Ja para utilizacao de microcontroladores de outras famlias, mas
mantendo o mesmo fabricante, a dificuldade aumenta um pouco, onde a sequen-
cia de manipulacao da flash pode ser diferente alem da segmentacao da memoria.
Mantendo o mesmo fabricante nao e necessario alterar de maneira significativa
o software desenvolvido, pois o fabricante utiliza o formato de arquivo S19 para
todos os microcontroladores.
A utilizacao de microcontroladores de outros fabricantes pode ser bastante

complicada, pois alem da alteracao do software, sera necessario a alteracao da
rotina de manipulacao da Flash, a rotina de comunicacao serial, possvelmente
5 Conclusao 51
as rotinas de criptografia, alem da segmentacao da memoria. A utilizacao de

microcontroladores com uma tecnologia mais avancada pode tambem facilitar
alguns pontos do desenvolvimento.
A utilizacao de outro modulo celular pode ser um dos pontos mais complica-
dos de se adequar, pois caso o modulo celular nao possua suporte aos protocolos
FTP e TCP/IP, seria necessario o desenvolvimento desses protocolos no micro-
controlador, criando assim um novo requisito, que nao foi implementado nesse
projeto.
O bootloader desenvolvido para o MC9S08JM32 alcancou os objetivos de

ser seguro, robusto e confiavel. As tecnicas criptograficas aplicadas garantem de
maneira satisfatoria contra quase todos os tipo de problemas acidentais ou propo-
sitais. As verificacoes feitas garantem a robustez, fazendo com que o bootloader
consiga resolver todos os problemas que estao ao alcance. O objetivo de ser um
codigo compacto foi de certa maneira o que foi atingido de maneira menos satis-
fatoria. O fato de ocupar 11kB pode ser um problema quando utilizado em um
microcontrolador que possui 32kB de memoria, pois 34% da memoria do micro-
controlador estara sendo utilizada pelo bootoloader. Para programas pequenos
isso nao e um problema, mas para programas que necessitem de mais memoria,
talvez seja conveniente trocar o microcontrolador pelo MC9S08JM60 que possui
60kB de memoria Flash, ou ainda, alterando o codigo do bootloader e retirando
algumas opcoes como a seguranca que a criptografia oferece.
52
Referencias
CANZIAN, E. Comunicacao Serial - RS232. 2011. Internet. Disponvel em:

<http://www.capriconsultorios.com/Aula4-Comun_serial.pdf>.
CAPISTRAN-GARZA, M. On-Chip FLASH Programming API for CodeWarrior

Software. Janeiro 2009. Internet. Disponvel em: <http://cache.freescale.
com/files/microcontrollers/doc/appnote/AN2504.pdf>.
FREESCALE SEMICONDUCTOR, INC. MC9S08JM32 Data Sheet. Janeiro

2009. Internet. Disponvel em: <http://www.freescale.com/files/
microcontrollers/doc/data_sheet/MC9S08JM60.pdf>.
KRENEK, P. Flash Programming Routines for the HCS08 and the ColdFire
(V1) Devices. Dezembro 2009. Internet. Disponvel em: <http://cache.
freescale.com/files/microcontrollers/doc/app_note/AN3942.pdf>.
MENEZES, A.; OORSCHOT, P. van; VANSTONE, S. Handbook of Applied

Cryptography. Boca Raton, Florida: CRC Press, 1996.
MICROSOFT DEVELOPER NETWORK. HMACSHA1 Class. 2012. Internet.

Disponvel em: <http://msdn.microsoft.com/pt-br/library/system.
security.cryptography.hmacsha1%28v=vs.80%29.aspx>.
P&E MICROCOMPUTER SYSTEMS. USB BDM Multilink. Janeiro

2009. Internet. Disponvel em: <http://www.pemicro.com/products/
product_viewDetails.cfm?product_id=24&CFID=9218068&CFTOKEN=
d520f8cdf02c2711-7D490967-BC91-30EB-5DBB61C87C4B5EEE>.
RIBEIRO, C. H. C.; ROIHA, L. H. Estudo comparativo dos mo-

dos de operacao de confidencialidade: um overview para inician-
tes. Revista Ciencia e Tecnologia, v. 8, n. 13, 2010. ISSN 2236-
6733. Disponvel em: <http://revistavirtual.unisal.br:81/seer/ojs-
2.2.3/index.php/123/article/view/70/83>.
SCHNEIER, B. Applied Cryptograph: Protocols, Algorthms, and Source Code in

C. Segunda edicao. New York: John Wiley & Sons, Inc., 1996.
SOUZA, R. de A. de; OLIVEIRA, F. B. de; CUNHA, G. N. da. O

algoritmo AES: Apresentacao e Descricao da Estrutura. 2007. Internet.
Disponvel em: <http://www.lncc.br/~borges/doc/O%20algoritmo%20AES%
20Apresentacao%20e%20Descricao%20da%20Estrura.pdf>.
U-BLOX AG. LEON-G100/G200 - quad-band GSM/GPRS Data

and Voice Modules - Data Sheet. Janeiro 2011. Internet. Disponvel
em: <http://www.u-blox.com/images/downloads/ProductDocs/
LEON-G100G200DataSheet(GSM.G1-HW-10004).pdf>.
Referencias 53
U-BLOX AG. u-blox Wireless Modules - Data and Voice Modules - AT

Commands Manual. Fevereiro 2012. Internet. Disponvel em: <http:
//www.u-blox.com/images/downloads/Product_Docs/u-blox_AT_Commands_
Manual_%28WLS-SW-11000%29.pdf>.

Bootloader para Atualização Remota de Fi Rmware Via Tecnologia GSM

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Bootloader para Atualização Remota de Fi Rmware Via Tecnologia GSM

Diunggah oleh

Hak Cipta:

Format Tersedia

Centro de Tecnologia e Urbanismo

Departamento de Engenharia Eletrica

Bootloader para atualizacao remota de

Monografia apresentada ao curso de

Bootloader para atualizacao remota de

Monografia apresentada ao curso de Engenharia

Monografia (Trabalho de Conclusao de Curso) Universidade

1. Sistemas Embarcados 2. Transmissao de dados via rede

Bootloader para atualizacao remota de

Monografia apresentada ao curso de Engenharia

Prof. MSc. Decio Luiz Gazzoni Filho

Prof. MSc. Diogo Kaoru Takayama

Prof. MSc. Osmar Tormena Jr

Londrina, 05 de Novembro de 2012

Agradeco a todos os meu amigos que passaram por todas as dificuldades do

A utilizacao de equipamentos eletronicos embarcados esta aumentando muito nos

2.1.2 Sequencia de reset de um microcontrolador . . . . . . . . . 5

2.1.3 Memoria Flash . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Comunicacao serial . . . . . . . . . . . . . . . . . . . . . . 8

2.2.2 Comunicacao via rede celular . . . . . . . . . . . . . . . . 9

2.3.2 Criptografia simetrica . . . . . . . . . . . . . . . . . . . . 14

2.3.3 Criptografia de chave publica e assinaturas digitais . . . . 18

2.3.4 Comparacao entre criptografia simetrica e de chave publica 20

2.3.5 Funcoes de Resumo Criptografico . . . . . . . . . . . . . . 22

2.3.6 Message Authentication Codes (MACs) . . . . . . . . . . . 24

3.1 Programa para piscar um LED . . . . . . . . . . . . . . . . . . . 27

3.3.1 Sequencia de manipulacao da Flash . . . . . . . . . . . . . 30

3.4 Bootloader atraves de comunicacao serial com o computador . . . 32

3.4.2 Protecao da Memoria e Redirecionamento do Vetor de In-

3.4.3 Conversao ASCII para Hexadecimal . . . . . . . . . . . . . 34

3.4.4 Programacao por linhas . . . . . . . . . . . . . . . . . . . 35

3.4.5 Software Reset . . . . . . . . . . . . . . . . . . . . . . . . 36

3.5 Adicao de criptografia e sistemas de seguranca contra copia de

3.5.1 Verificacao de integridade e segmentacao da memoria do

3.5.2 Atualizacao com firmware particionado e cifrado . . . . . . 41

3.6 Bootloader com comunicacao via internet . . . . . . . . . . . . . . 42

4.1 Tamanho do bootloader . . . . . . . . . . . . . . . . . . . . . . . 47

4.2 Tempo de execucao . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.1 Esquema de comunicacao entre duas partes usando Criptografia . 12

2.2 a) Imagem Original; b) Imagem cifrada utilizando o modo ECB;

2.3 Counter Mode (CTR) . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 Esquema de comunicacao entre duas partes usando Criptografia de

2.5 Ataque em uma comunicacao de chave publica entre duas partes. 21

2.6 Blocos de uma operacao do SHA-1. . . . . . . . . . . . . . . . . . 25

3.1 Fluxograma de escrita e apagamento da memoria Flash dos micro-

3.2 S19 com os setores destacados . . . . . . . . . . . . . . . . . . . . 33

3.3 Fluxograma da rotina de verificacao . . . . . . . . . . . . . . . . . 37

3.4 Arquivo de controle com os setores destacados . . . . . . . . . . . 39

3.5 Fluxograma da comunicacao com o modulo celular. . . . . . . . . 46

4.1 Tamanho do codigo do bootloader . . . . . . . . . . . . . . . . . . 47

3.1 Segmentacao da memoria Flash . . . . . . . . . . . . . . . . . . . 41

RAM Random Access Memory

FOTA Firmware Over The Air

GSM Global System for Mobile Communications

GPRS General Packet Radio Service

FTP File Transfer Protocol

TCP Transmission Control Protocol

UDP User Datagram Protocol

AES Advanced Encryption Standard

HMAC Hash-based Message Authentication Code

MAC Message Authentication Code

SHA1 Secure Hash Algorithm 1