1) O documento apresenta as credenciais e experiência profissional de Walter Silvestre Coan, especialista em IoT. 2) É descrita a agenda e as principais propriedades de segurança para dispositivos IoT que serão abordadas na conferência MVPConf LATAM 2020. 3) São listadas as entidades beneficiadas com doações realizadas durante o evento.

4. Prof. Walter Silvestre Coan, MSc.
IoT

5. Microsoft MVP, Desenvolvedor, Professor do Bacharelado em Sistemas de
Informação e do Bacharelado em Engenharia de Software da UNIVILLE,
Mestre em Ciência da Computação na área de Sistemas Distribuídos.
Certificações: Azure Solutions Architect, Azure IoT/Dev Cert, MCT, MCSD,
AWS Academy Accredited Educator, AWS Dev Cert, SCP Java.
Mini-Biografia
walter.coan@gmail.comtwitter.com/waltercoan
linkedin.com/in/waltercoan faltoupontoevirgula.com.br

6. PATROCINADORES_
Agradecemos a confiança e o investimento realizado pelos Patrocinadores
do MVPConf LATAM 2020.
Sem a participação deles o evento não aconteceria.
Nosso muito obrigado!!!

7. Lar de Idosos Nossa
Senhora da
Conceição
Aracaju - SE
Retiro dos Idosos
Universina Carrera
Machado
Santo Ângelo - RS
Associação
Comunitária Fênix
Jacareí - SP
Rede Feminina de
Combate ao Câncer
Três Lagoas - MS
Associação de Pais e
Amigos dos
Excepcionais – APAE
de Farroupilha
Farroupilha - RS
Lar da Criança Ninho
de Paz
São Paulo - SP
Abrigo Bom Pastor
Cornélio Procópio - PR
BENEFICIADAS
POR VOCÊ_
Estas foram as entidades beneficiadas com a doação que você realizou no
ato da sua inscrição no MVPConf LATAM 2020.
Sem a sua participação o evento não aconteceria e não poderíamos
impactar a vida de tantas pessoas.
Nosso muito obrigado!!!

8. AGENDA_
EM DESTAQUE_
• Sete propriedades de um dispositivo IoT seguro
• Azure Sphere
• As melhores práticas para implementação das sete
propriedades
• Demonstração
• OTA Update
• Dispositivo de sensoriamento de qualidade de ar
utilizando o Azure Sphere e o IoT Central

9. SETE
PROPRIEDADES_
EM DESTAQUE_
• Hardware Root of Trust (Hard)
• Seu dispositivo é identificável e a integridade do software
é confirmada por hardware?
• Defense in Depth (Hard+OS)
• Seu dispositivo se mantém seguro se um mecanismo de
segurança for destruído?
• Small Trusted Computing Base (Hard+OS)
• O seu dispositivo reforça a segurança contra bugs no
código das aplicações?
• Dynamic Compartments (Hard+OS)
• As proteções de segurança do seu dispositivo podem
melhorar após a implantação?

10. SETE
PROPRIEDADES_
EM DESTAQUE_
• Certificate-Based Authentication (Hard+OS+CLOUD)
• Seu dispositivo utiliza certificados digitais ao invés de
senhas para autenticação?
• Failure Reporting (Hard+OS+CLOUD)
• Seu dispositivo reporta falhas e anomalias?
• Renewable Security (Hard+OS+CLOUD)
• Seu dispositivo atualiza o software de forma automática?
https://www.microsoft.com/en-us/research/wp-
content/uploads/2017/03/SevenPropertiesofHighlySecureDevices.pdf

11. O Azure Sphere baseia-se em
décadas de experiência da
Microsoft em hardware,
software e nuvem para fornecer
uma solução completa e pronta
para o uso para dispositivos
IoT.
Disponibilidade geral desde 24/02/2020.

12. Secured MCUs
Uma nova categoria de MCU’s
chamado Azure Sphere, produzidos
por empresas parceiras, com
tecnologia de segurança da Microsoft,
que fornece conectividade, alto
desempenho e características de
segurança no hardware.
Cloud Security
Azure Sphere Security Service
protege cada dispositivo e os clientes,
detecta falhas de segurança e
responde de forma proativa.
Secured OS
Sistema operacional seguro Azure Sphere
OS que combina as melhores práticas da
Microsoft e da comunidade Open Source,
criando uma plataforma confiável para uma
nova experiência em IoT.

13. Hardware MCU_
Microsoft Pluton Security Subsystem – Root of Trust
ARM Cortex-A provê isolamento de processos através do
gerenciamento de unidades de memória. Azure Sphere OS
cria containers para as aplicações que utilizam espaços de
memória reservados.
Cada chip possui sua própria área memória flash e SRAM.
2x ARM Cortex-M é o MCU, que executa o processamento em
real time.

14. Azure Sphere utiliza a tecnologia ARM’s TrustZone que permite
a criação de ambientes independentes de execução dentro de
um único chip.
• Secure World – alto nível de privilégios
• Normal World – baixo nível de privilégios
Cada ambiente pode executar seu próprio sistema operacional
e aplicações
Azure Sphere Trusted Computing Base (TCB) é composto por
componentes eletrônicos e software que roda no Secure World.
Parte do TCB está no Pluton Security System e parte se
estende ao Security Monitor que é executado no Cortex-A7.
Hardware MCU_

15. Microsoft Pluton Security Subsystem é composto por três
componentes:
• Pluton Fabric – recursos de segurança implementados no
hardware
• ECDSA - Algoritmo de Assinatura Digital de Curvas
Elípticas
• Acesso as chaves PKI (Infraestrutura de chaves
públicas x.509) – gravada em e-Fuse no momento
da construção do MCU.
• Pluton Runtime – inicializa o funcionamento com o Pluton
Fabric
• Checagem da inicialização do sistema
• Único componente capaz de acessar o Pluton Fabric
• Não possui acessos privilegiados e sua única
permissão é executar funções e coletar os resultados
do Pluton Fabric
• Real-time core dedicado ao Pluton
• Executado no ARM Trustzone Secure World
Hardware MCU_

16. Cortex-A7
• Security Monitor
• É executado no Security World
• Verifica e permite políticas de acesso a recursos
• Atualização do software
• Auditoria do ambiente
• Único componente com permissão de acesso a
memória flash
Hardware MCU_

17. Cortex-M4 – Real Time Core
• Totalmente dedicados e isolados para a aplicação cliente;
• Execução bare metal
• Execução RTOS
• Normal World
• Periféricos podem ser mapeados para estes núcleos
garantindo características de aplicações em tempo real
Hardware MCU_

18. Experiência do Desenvolvedor
Camadas da Arquitetura
Visual Studio/Code
Windows/Ubuntu
Azure Sphere SDK
Azure Sphere Device
Communication Service
Customer
Applications
OS Services
Custom Linux
Kernel
Azure Sphere
Security Monitor &
Firmware
Placa/Módulo
Azure Sphere Certificado SoC
Cortex-A core Solução de Conectividade
Firmware Fornecedor
Security
Monitor
Pluton Security
Subsystem
Cortex-M core
Cortex-M core(s)
Customer
Applications
RTOS/Runtime
Library for I/O
(ex. inter-core comms)
Customer Applications
Custom Linux
Kernel
User Mode
OSService
Networking management
Application management
OTA update client
Device Auth client
Application Container
PosixAppRuntime
Runtime for POSIX Apps
(ex. Base C API; Azure IoT; HTTP
client; UART; GPIO APIs, etc.)
Peripherals(ex.UART,GPIO,etc.)

19. • ARM Cortex A7 NEON FPU
• 64kB L1 instruction cache
• 32kB L1 data cache
• 256kB L2 cache,
• 4MB system memory for the Azure Sphere operating
system and user applications
• 2x ARM Cortex M4 cores
• 192kB TCM (Tightly-Coupled Memory)
• 64kB SRAM
• FPU Floating Point Unit
Hardware MCU_

20. • Pluton Security Subsystem
• ARM Cortex-M4F security processor
• 128kB secured TCM
• 64kB secured mask ROM bootloader
• Wi-Fi
• Processador dedicado N9 32-bit RISC core
• IEEE 802.11 a/b/g/n
• Bandas de 2.4GHz e 5GHz
Hardware MCU_

21. Dev Boards_

22. Dev Boards_

23. https://www.microsoft.com/security/blog/2020/05/20/cybersec
urity-practices-implement-secured-devices/?WT.mc_id=AZ-
MVP-5003638
As melhores práticas para
implementar as sete propriedades_

24. As melhores práticas para implementar as sete propriedades_
• Secure Boot
• Processo de verificação da assinatura de todos os softwares que são executados a partir
do boot são legítimos
• Todo software que é executado é assinado por uma chave privada da Microsoft e
verificada por uma chave pública no Azure Sphere
• Measured Boot (Boot controlado)
• Faz parte do processo de verificação remota de que o boot seguro foi executado.
• O serviço remoto verifica qual software foi utilizado para realizar o boot da aplicação
• Se o software utilizado é de uma fonte desconhecida, o acesso do dispositivo a
recursos pode ser negado.
• Se o dispositivo estiver rodando software que não esta atualizado ou que não seja
mais confiável pela Microsoft (zero-day exploit), o dispositivo é obrigado a se
atualizar para ter acesso a qualquer recurso.

25. As melhores práticas para implementar as sete propriedades_
Tratar a boot ROM como um software não atualizável e minimizar seu tamanho
• A boot ROM é gravada no momento da manufatura do microprocessador
• É considerado o código mais seguro pois não pode ser modificado
• Tentativas de ataques comuns aplicados
• Realizar ações que forcem o MCU a pular parte do código da ROM que por exemplo
faz verificação de assinaturas dos softwares, para dai inserir um código não
autorizado para ser executado
• Solução
• Implementar no hardware dispositivos para impedir a possibilidade do código da
ROM não ser totalmente executado
• Reduzir o tamanho da ROM para diminuir sua área de ataque

26. As melhores práticas para implementar as sete propriedades_
Nunca expor chaves privadas do dispositivo ao software
• Azure Sphere utiliza o método de criptografia de chaves públicas e privadas elliptic-curve
cryptography (ECC) para implementar o Boot Seguro e o Boot controlado.
• As chaves são gravadas em dispositivos chamados one-time programmable fuse (OTP) (e-fuse),
não podem ser modificados e são acessíveis apenas pelo Pluton Fabric
• O Boot controlado utiliza um conjunto de chaves publicas e privadas geradas no momento da
produção do MCU
• A parte privada da chave é gravada nos e-fuses
• A parte pública da chave é coletada pela Microsoft
• Tentativas de ataques comuns
• Hardware Secure Module (HSM) dispositivos utilizados para gerar e armazenar pares de
chaves que precisam ser transferidos para o MCU
• Possibilitando um ataque de man-in-the-middle
• Solução
• Nenhuma parte do software tem acesso as chaves

27. As melhores práticas para implementar as sete propriedades_
Utilize o chaves ECC (Elliptic-curve cryptography) do que RSA (Rivest-Shamir-Adleman)
• ECC tem resistência a ataque de força bruta equivalente ao RSA
• ECC necessitam de menos RAM e geram chaves menores portanto precisam de menos espaço
de e-Fuses para serem armazenadas, reduzindo o custo de produção do MCU
• ECC necessitam de uma única fonte de dados aleatórios para ser gerada
• Azure Sphere possui um hardware específico e auto verificado para geração de números
randômicos
• RSA necessita da geração de dois números primos randômicos, processo que tem um alto custo
computacional

28. As melhores práticas para implementar as sete propriedades_
Utilize o Boot Seguro em todo lugar e sempre
• Verificação das assinaturas contra as chaves ECC utilizando o algoritmo
ECDSA (Elliptic Curve Digital Signature Algorithm)
• A chave privada é mantida pela Microsoft
• A chave pública precisa ser distribuída aos dispositivos de forma segura,
garantindo sua integridade
• Bootstrap key mais um conjunto de chaves, onde a parte pública é
gravada nos e-fuses, e utilizada pela ROM para verificar o
bootloader. Utilizada também para verificar a assinatura de um
arquivo binário contendo as chaves públicas utilizadas para verificar
os demais componentes de software.
ROM verifica
assinatura
bootloader
• Uma vez verificado
inicia a execução
Bootloader verifica
a assinatura do
software do Pluton
Runtime
• Uma vez verificado
inicializa a execução
Pluton inicia a
verificação da
assinatura da
próxima camada de
software
Até chegar na
Aplicação de
Negócio

29. As melhores práticas para implementar as sete propriedades_
Utilize o Boot Controlado para comprovar Boot Seguro
• O Boot controlado utiliza uma lista de assinaturas dos softwares para comprovar que o Boot
Seguro foi executado para o serviço remoto de certificação do Azure
• Durante o Boot seguro um valor hash de cada software verificado é acumulado
• Esse acumulador não pode ser apagado, a não ser que o MCU seja resetado
• O Azure Sphere conecta por TLS com o Azure Sphere Security Server, e solicita um
valor que comprove sua integridade além de outros dados coletados durante o processo
de boot seguro.
• O Azure Sphere combina os valores do hash, e assina o valor com a chave privada única
do dispositivo, essa hash é utilizada apenas para certificação de integridade remota.
• O Azure Sphere Security Server possui a chave pública do dispositivo, que permite
verificar a integridade dos dados passados pelo dispositivo.

30. As melhores práticas para implementar as sete propriedades_
Utilize o Boot Controlado para comprovar Boot Seguro
• O Boot controlado utiliza uma lista de assinaturas dos softwares para comprovar que o Boot
Seguro foi executado para o serviço remoto de certificação do Azure
• Se a certificação remota ocorrer com sucesso
• O dispositivo recebe dois certificados x.509: o primeiro é um certificado para
atualização do dispositivo através de uma conexão segura com o serviço na nuvem,
e o segundo certificado habilita que o dispositivo possa se conectar com serviços do
Azure IoT como o Azure IoT Hub.
• Estes certificados tem validade de 24 horas
• É possível que a certificação remota ocorreu com sucesso, mas o software não é mais
confiável
• Neste caso o dispositivo recebe apenas o certificado de atualização, os binários no
device são marcados como não confiáveis, e o dispositivo é obrigado a atualizar.

31. As melhores práticas para implementar as sete propriedades_
Atualização de certificados
• Azure Sphere possui um blob com um pequeno conjunto de certificados binários
• Verificados durante o processo de boot seguro
• Computadores comuns podem receber atualizações com novos certificados
• Dispositivos IoT podem ficar meses parados antes de serem utilizados
• Solução
• O Azure Sphere conecta em um endpoint http para baixar a versão do blob de
certificados mais atualizado.
• O dispositivo tem consciência de que esse arquivo é considerado inseguro.
• Esse blob é assinado com a chave privada bootstrap key e verificada com a parte
pública que foi gravada no e-fuse do MCU.
• Como um passo extra, algumas mensagens são trocadas para verificar se os
certificados foram atualizados.

32. As melhores práticas para implementar as sete propriedades_
Conectividade é opcional
• O que acontece se o dispositivo não possuir conectividade e se os certificados expirarem?
• O dispositivo continua funcionando normalmente
• O Boot Seguro não depende de certificados
• Os aplicativos que já estão instalados no dispositivo, passarão pelo processo de
verificação do Boot Seguro e serão colocados em funcionamento.

33. As melhores práticas para implementar as sete propriedades_
Tornar difícil construir botnets a partir de vulnerabilidades de dia zero
• O Azure Sphere lida com essa questão utilizando o componente de firewall
• Todo aplicativo possui um arquivo descritor (manifest) que descreve as políticas de
acesso a recurso, periféricos e endereços de internet.
• Não há possibilidade de uma aplicação reprogramar esse firewall.
• E caso a aplicação precise conectar com um endereço onde ele não conheça o DNS
• Suporte ao protocolo mDNS e DNS-SD

34. As melhores práticas para implementar as sete propriedades_
Utilizar a política de negado por padrão, reforçado pelo hardware
• ARM TrustZone divide os 4mb de SRAM ligado ao Cortex-A7 em seguimentos para o Secure
World e Normal World
• A memória do Normal World é dividida entre o Cortex-A7 e os núcleos Cortex-M4
• Azure Sphere utiliza a política de negado por padrão
• SRAM
• Durante o boot a SRAM é acessível apenas pelo Secure World
• Software rodando no Secure World que da acesso ao Cortex-A7 para acessar parte
da memória no Normal World (Linux kernel)
• Todos os periférico possui um “sticky bit” que mantém o periférico ligado ao core que
solicitou seu uso pelo arquivo descritor (manifest).

35. As melhores práticas para implementar as sete propriedades_
Eliminar o conceito de usuários nos dispositivos IoT
• Dispositivos não devem conter dados de usuários, muito menos acesso a suas contas.
• O gerenciamento de credenciais de usuários deve ficar com serviços em nuvem
• Dispositivos não devem possuir o conceito de super usuários
• No Azure Sphere as identidades do sistema operacional Linux (users and groups) são atribuídas
de forma única as aplicações. Cada aplicação possui as configurações de permissões que deve
possuir.
• Todas as aplicações são contidas em containers, e possuem seu sistema de arquivos próprio por
aplicação. As permissões dão acesso a aplicação para utilizar os arquivos, mas não permitem
que outra aplicação tenha acesso aos arquivos.
• Não existe a possibilidade de um usuário assumir um papel de super usuário.

36. As melhores práticas para implementar as sete propriedades_
Separação física entre o código em execução e a comunicação com a Internet
• O Cortex-A7 divide seu tempo de execução entre o Azure Sphere OS e as aplicações dos
clientes
• Os núcleos Cortex-M4 são dedicados para software das aplicações clientes
• A comunicação entre esses núcleos não interfere no desempenho dos núcleos em tempo real

37. As melhores práticas para implementar as sete propriedades_
Dividir o código entre user-mode code e kernel code
• Todo o código necessário para manter a segurança da aplicação é executado dentro do Secure
World do ARM Trustzone
• As aplicações são executadas no modo de Normal World, garantindo que mesmo que o usuário
ganhe acesso a aplicação, ele não será capaz de tomar o controle total do dispositivo.

38. As melhores práticas para implementar as sete propriedades_
Garanta que todo o software possa ser atualizado
• Todo o software deve permitir atualização até o bootloader
• Software que não pode ser facilmente atualizado é um excelente alvo para ataque

39. As melhores práticas para implementar as sete propriedades_
Faça a atualização de software ser tolerante a falhas
• Toda atualização é gerenciada pela Microsoft
• Antes de iniciar a atualização o sistema garante que possui uma copia, compactada de todo o
software que esta no dispositivo.
• Caso a atualização falhe por qualquer motivo, o sistema recupera a última versão estável do
software, e informa a falha de atualização para o serviço de segurança do Azure Sphere.
• Uma vez que a atualização aconteça, o dispositivo é reiniciado e uma nova versão do Pluton
Runtime e do Security Monitor são iniciadas, e iniciam a verificação para então atualizar o Azure
Sphere OS. Uma vez atualizada a versão, são gravadas informações que não permitem retornar
a versão anterior.

40. As melhores práticas para implementar as sete propriedades_
Isolar a aplicação para tornar a atualização simples
• Todas as dependências da aplicação de negócio são empacotadas em um único binário,
simplificando o processo de atualização.
• Uma aplicação pode ser atualizada e reiniciada sem necessitar reiniciar o dispositivo inteiro.

41. As melhores práticas para implementar as sete propriedades_
Não permita que o sistema dinamicamente modifique o comportamento do software
• A mudança de comportamento do software de forma dinâmica introduz uma grande superfície de
ataque. JIT just-in-time compilers geram código binário durante o tempo de execução. Azure
Sphere elimina esse comportamento para reduzir a superfície de ataque.
• Azure Sphere tem por padrão não permitir que novas funcionalidades sejam “linkadas” ao kernel
do sistema operacional. Portanto todos os módulos do kernel deve ser compilados de forma
estática e distribuídas junto ao pacote assinado de atualização.

42. As melhores práticas para implementar as sete propriedades_
Defesa contra reversão de atualizações
• O downgrade attack consiste em forçar o dispositivo a reverter as atualizações e retornar a uma
versão onde uma brecha de segurança foi descoberta.
• Caso fosse possível realizar essa operação com o Azure Sphere, o Pluton Runtime detectaria
que a versão antiga não é mais confiável, e impediria o processo de boot, levando o dispositivo
para a última versão estável conhecida, que seria a mais atual.
• Existem um conjunto limitado de e-fuses que controlam o versionamento do dispositivo, e
apenas em casos onde há uma vulnerabilidade relevante, esse controle é acionado.

43. As melhores práticas para implementar as sete propriedades_
Use ferramentas e processos para tornar o dispositivo mais seguro
• Verificação constante das Common Vulnerability Exposure dataset
• Utilização de Software fuzz testing
• Utilizar análise estática de código
• Azure Sphere Red Team

44. Demo OTA Update_
https://docs.microsoft.com/pt-br/azure-sphere/deployment/create-a-
deployment?WT.mc_id=AZ-MVP-5003638
https://channel9.msdn.com/Shows/Internet-of-Things-Show/Deep-Dive-Developing-for-
Azure-Sphere-Over-the-Air-Updates?WT.mc_id=AZ-MVP-5003638

45. Demo qualidade de
ar_
Hackster Impact
Prize
https://www.hackster.io/waltercoan/azure-sphere-and-
mikroe-air-quality-sending-to-iot-central-99b156