Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Segurança e Cifras nas Aplicações

1,078 views

Published on

Apresentação de alguns aspetos relacionados com a segurança e a aplicação de criptografia no desenvolvimento, distribuição e execução de aplicações, incluindo num ambiente de Internet das Coisas.

Published in: Software
  • Login to see the comments

Segurança e Cifras nas Aplicações

  1. 1. >< SEGURANÇA E CIFRAS NAS APLICAÇÕES JOÃO PAULO BARRACA <JPBARRACA@UA.PT> 1 Imagem: Flickr, John Colby
  2. 2. >< • Tem de considerar todo o life-cycle da aplicação • Planeamento e designs cuidados • Considerando a segurança desde cedo • Métodos de desenvolvimentos apropriados • code review, pair programming, track changes • Métodos de disponibilização e execução seguros • TPM, chaves, tokens JOÃO PAULO BARRACA, JPBARRACA@UA.PT Segurança Aplicacional 2
  3. 3. >< 3 Organização TecnologiaPessoas Processos JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  4. 4. >< • Implica conhecer as ameaças • Diretas: decompilação, alteração, distribuição, injecção, negação, … • Indiretas: bibliotecas, hardware, side-channel • necessário conhecer a tecnologia, canais, hardware… • contratar colaboradores experientes • ou obter conhecimento externo Segurança Aplicacional 4JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  5. 5. >< • Implica segurar todo o ambiente de execução • Software, OS, comunicações, armazenamento • Uma fraqueza num componente representa um ponto de falha. • Dependência de componentes externos é um problema • NPMGate, Stagefright, Heartbleed/DROWN… • Dependências de sistemas (Windows 3.11, NT, XP?) Segurança Aplicacional 5JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  6. 6. >< • … mas vivemos no mundo das “Apps” e “Mashups” • Controlo reduzido sobre o ambiente de execução • Sistemas produzidos de forma não controlada • Ao custo mais baixo • sobre múltiplos sistemas operativos "Write once, run anywhere" (WORA), Sun Microsystems Problema… 6JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  7. 7. >< • Grande rotatividade de colaboradores • Manter FTE experientes é caro… Problema… 7JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  8. 8. >< • Aplicações são utilizadas 24/7 • recolhendo dados pessoais/sensíveis • recolhendo meta-dados possivelmente sensíveis • desenvolvidas ad-hoc Problema… 8JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  9. 9. >< • Dados são armazenados na “cloud” • Ou seja: algures, não se preocupem com isso • Seguros? claro! (?) De quem? 9JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  10. 10. >< http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/ 10JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  11. 11. >< • Confidencialidade dos dados armazenados e dos algoritmos • Autenticidade dos componentes • Integridade da execução • Não Repudiação das operações • Disponibilidade do fornecimento do produto • Privacidade dos utilizadores Objetivos da Segurança 11JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  12. 12. >< • Inicialmente utilizada apenas para confidencialidade Criptografia 12 Flickr, timg_vancouver/200625463 JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  13. 13. >< • Implementa funções básicas: • Cifrar: tornar confidencial • Decifrar: abrir texto confidencial • Assinar: Criar uma assinatura digital • Verificar: Verificar uma assinatura digital • Princípios fundamentais da segurança prática • Cifras bem conhecidas • Segurança reside na complexidade da chave • e na aplicação dos processos Criptografia 13JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  14. 14. >< 14 CipherPrivate Key Decipher ??? Cryptogram Cryptogram Public Key CipherKey Decipher Key ??? Cryptogram Cryptogram JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  15. 15. >< • É já parte obrigatória de muitos processos • Fornece garantias de confiança • garantias matemáticas e não legais/processuais • Sempre que possível dissociada do fator humano • chaves aleatórias • processos aplicados sem exceções • processos obrigatórios Criptografia 15 Imagem: Flickr, ignatgorazd JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  16. 16. >< acesso aos repositórios, alterações não autorizadas, não repudiação • Mecanismos de controlo de acesso • Disponível em SSH, HTTPS, VPN • Chaves pré-distribuídas ao pessoal autorizado • Armazenamento seguro (ex. CC e Bitlocker) • Sistemas de controlo de versões • Alterações criptograficamente assinadas • Alterações passíveis de ser validadas (Code Review, Code Acceptance) Desenvolvimento 16JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  17. 17. >< $ git commit -a -m “Fixes #342” --gpg-sign=B168F3A $ git log --show-signature commit 3d53a4be3f6f9540274c052347d726367bbfa8de gpg: Signature made dev1 8 jan 21:02:58 2016 WET using RSA key ID B168F3A gpg: Good signature from “Developer 1 <dev1@companyX.net>" Author: Developer 1 <dev1@companyX.net> Date: Fri Jan 8 21:02:58 2016 +0100 GIT com PGP 17 Alterações assinadas por chave de cada colaborador Campo Signed-off-by não possui características criptográficas JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  18. 18. >< 18JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  19. 19. >< 19 AES 128 CBC JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  20. 20. >< 20 AES 128 ECB (a maneira que normalmente aparece nos fóruns) JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  21. 21. >< Distribuição ilegal, corrupção dos objetos, controlo de acesso • Assinatura dos distribuíveis com chave privada do autor • pacotes deb, JAR, MSI, drivers • executáveis (PE, Mach-O, ELF) • Controlo criterioso dos canais de distribuição • Limites de acesso aos servidores • Controlo dos sistemas finais • Vulneráveis a adições de CAs/chaves públicas Distribuição 21JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  22. 22. >< • Métodos automatizados: OS updates • Métodos manuais Distribuição 22 https://www.kernel.org/pub/linux/kernel/v4.x/ … patch-4.5.gz 14-Mar-2016 04:39 15M patch-4.5.sign 14-Mar-2016 04:39 473 patch-4.5.xz 14-Mar-2016 04:39 8.2M sha256sums.asc 06-Apr-2016 10:37 23K xzcat patch-4.5.xz | gpg --verify patch-4.5.sign - gpg: Signature made Mon Mar 14 04:35:39 2016 WET using RSA key ID 00411886 gpg: Good signature from "Linus Torvalds <torvalds@linux-foundation.org>" JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  23. 23. >< integridade, permissões, confidencialidade, privacidade • Onde existem mais problemas no processo • Plataforma pode não ser controlada pelo autor • Atacantes possuem acesso físico • Outras aplicações em coexistência • Existência de ferramentas de depuração/análise • Falta de treino dos utilizadores • … Execução 23JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  24. 24. >< • Assinaturas de código: OS X Mach-O Execução 24 Executable=/Applications/Franz.app/Contents/MacOS/Electron Identifier=io.adlk.franz Format=app bundle with Mach-O thin (x86_64) CodeDirectory v=20200 size=197 flags=0x0(none) hashes=3+3 location=embedded Hash type=sha1 size=20 CandidateCDHash sha1=8b8572bd375d42728b195f5b3916a8a865e832e0 Hash choices=sha1 CDHash=8b8572bd375d42728b195f5b3916a8a865e832e0 Signature size=8563 Authority=Developer ID Application: OMITTED (TAC9P63ANZ) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=07 Mar 2016 11:44:22 Info.plist entries=21 TeamIdentifier=TAC9P63ANZ Sealed Resources version=2 rules=12 files=10 Internal requirements count=1 size=176 JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  25. 25. >< 25JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  26. 26. >< 26 Genkin et al, RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  27. 27. >< • Confidencialidade dos dados armazenados • Segredos comerciais • Segredos privados • Metadados de utilização • Cifras utilizadas para cifrar dados das aplicações • Necessário armazenar as chaves • Tokens seguros? :( • Chaves complexas? :(( • Alterar chaves todos os meses? :((( Execução 27JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  28. 28. >< • Comunicações devem ser seguras entre intervenientes • Cifras utilizadas para assinar/cifrar dados nas comunicações entre interlocutores • ex. Transport Layer Security (TLS) • Preferencialmente entre extremos • Segurança direta sobre os objetos (Email) • Túneis de comunicação (VPN, TLS) Execução 28JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  29. 29. >< • Sistemas são controlados verticalmente • Normas de interoperabilidade • Ambientes embebidos colocam novos desafios • CPU: Dezenas de MHz, • Memória: Dezenas KB RAM, centenas KB Flash • Operação em locais remotos • configuração/atualização OTA • recolhendo dados sensíveis JOÃO PAULO BARRACA, JPBARRACA@UA.PT Execução em IoT/M2M 29JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  30. 30. >< • Aplicações não são jogos, calculadoras, processadores • Aplicações • adquirem dados reais • interagem com mundo real • Ataques violam privacidade • podem comprometer a integridade física JOÃO PAULO BARRACA, JPBARRACA@UA.PT Execução em IoT/M2M 30JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  31. 31. >< • Cifras são fundamentais no controlo do dispositivo • Comunicações e execução dos algoritmos • Processos de execução e atualização seguros • Bootloaders que só aceitam código assinado • Transmissões seguras • Associações seguras às plataformas M2M • EAP antes de qualquer operação • Auditoria/validação remotas Execução em IoT/M2M 31JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  32. 32. >< • Segurança tem impacto decisivo nas soluções • Sendo frequentemente descartada • Segurança obriga a maior custo • Memória para as chaves • CPU para os algoritmos • Solução passa por implementações em hardware • ex. AES Execução em IoT/M2M 32 Tempo de cifra: RSA 1024=~12.5s JOÃO PAULO BARRACA, JPBARRACA@UA.PT
  33. 33. >< “If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.” ― Sun Tzu, The Art of War Obrigado 33JOÃO PAULO BARRACA, JPBARRACA@UA.PT Questões?

×