aboutsummaryrefslogtreecommitdiff
path: root/cryptorave.mdwn
blob: 0cf768b29af75f3b71b8c2d3c8016ac7d005ec0f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
[[!meta title="Criptografia funciona: as soluções e os limites atuais"]]

- Criptografia funciona: as soluções e os limites atuais.
- Silvio Rhatto @ Cryptorave 2014.
- [Página do evento](https://cryptorave.org).
- [Slides em PDF](slides.pdf).

Quais são os limites das tecnologias atuais para combater a vigilância em
massa? Quais são os novos projetos e as soluções que estão sendo desenvolvidas?

Breve em https://rhatto.sarava.org/cryptorave

CRIPTOGRAFIA FUNCIONA: AS SOLUÇÕES E OS LIMITES ATUAIS
======================================================

    "Communicação nerd a nerd está OK, mas e quanto ao
     mundo real? E quanto aos meus amigos/as? E quanto
     à minha família?"

     -- Dan Kaminsky, pesquisador de segurança.
        http://mashable.com/2013/03/04/wickr/

TL;DR
=====

1. Neutralidade: a rede deve ser apenas o entregador das mensagens, lidando apenas com endereçamento.
2. Endereçamento seguro: criptografia ponta-a-ponta de dados e metadados.
3. Sistemas e protocolos estão em disputa pela padronização.
4. É mais fácil resolver a etapa da rede do que a segurança nos dispositivos dos usuários.

Software livre: é pressuposto!
==============================

O sexteto da segurança:

* As quatro liberdades: rodar, estudar, redistribuir e melhorar programas.
* Princípio de Kerckhoffs: o sistema deve ser seguro mesmo se tudo do sistema é conhecido, exceto as chaves.
* Lei de Linus: quanto mais olhos no código, mais bugs são encontrados.

Consideramos que os sistemas são conhecidos. Mais ainda, devemos torná-los conhecidos
para que possam ser melhorados!

Software livre: não é condição suficiente para segurança!
=========================================================

* O que um olho não viu pode existir!
* O que um olho viu e não publicizou pode ser explorado maliciosamente!
* Software desatualizado é parque de diversões alheias.
* Com software proprietário o problema é muito pior!

![Heartbleed Bug](heartbleed.png)

Segurança na rede
=================

* Para que mais olhos enxerguem, precisamos de soluções com massa crítica.
* Que operem fora de silos e jardins murados.
* Fator Babel: de tal modo que que se tornem **padrões** e **ubíquas**
* O comportamento seguro deve ser o *padrão*

A pergunta central é: para mudarmos os protocolos, a melhor estratégia é:

1. De ruptura: criamos novos serviços seguros e encorajamos a migração direta dos/as usuários?
2. Incremental: upgrade transparente de protocolos conforme os softwares forem atualizados?

Os grandes problemas
====================

* Há uma série de problemas difíceis de serem resolvidos, especialmente porque para eles não
  existe consenso ou mesmo propostas de soluções.

* Assim, a estratégia será incremental!

* Ei-los: gestão de chaves, proteção de metadados, assincronicidade com sigilo futuro,
  comunicação em grupo, compartilhamento de recursos, disponibilidade, atualização e autenticação
  seguras, facilidade de uso, etc.

  https://oblivia.vc/pt-br/content/problemas-difíceis-na-comunicação-segura

Aprendendo com os erros...
==========================

* Exemplo limite: Lavabit: qualquer nova plataforma deve ter um modelo de ameaças
  mais resistente.
* Exemplo ruim: Telegram: não crie protocolos em casa e forneça-os como serviço de massa
  sem antes submetê-los ao escrutínio público.

Comparativo entre arquiteturas
==============================

![https://leap.se/en/docs/tech/infosec](table.png)

LEAP Encryption Access Project
==============================

* Foco: autenticidade, usabilidade e proteção de metadados.
* Serviços: email, VPN, mensageria. 
* Plataforma automatizada no lado do servidor.

![https://leap.se/en/docs/tech/infosec](leap.png)

Outras plataformas
==================

* Relatório sobre projetos de comunicação segura: https://github.com/OpenTechFund/secure-email
* TextSecure: abre perspectivas para mensageria instantânea.
* DarkMail, SilentCircle, Wickr, etc: abrirão o código?
* Sistemas de cauda longa (Pond, Enigmabox, etc): https://rhatto.sarava.org/services/
* Voz e vídeo (ZRTP).

Segurança dos dispositivos
==========================

* Sistemas operacionais mais seguros.
* Hardware aberto: evitando backdoors.
* Geração satisfatória de números aleatórios.
* Agoritmos e protocolos criptográficos do estado da arte.
* Armazenamento criptografado.

Segurança mental
================

* Como resolver o problema das senhas?
* Fácil de lembrar, fácil de quebrar.
* Gerenciadores de senhas.
* Biometria: facilmente forjável.
* Tokens afanáveis?
* Implante de senhas e chaves? :P

Perspectivas e previsões
========================

Poderíamos pensar numa agenda cypherpunk para segurança de massas?

Criptografia
============

* Difícil de prever, depente de descobertas paradigmáticas!
* Aplicação do estado da arte na prática: computação homomórfica, zero-knowledge!

Hardware
========

* Onde estão as foundries locais?
* Será mais fácil produzir plataformas abertas?
* Patentes e propriedade intelectual afeta especialmente o hardware.

Softwares
=========

* Linguagens de programação e frameworks pró-ativos.
* Bibliotecas com melhores implementações de primitivas criptográficas (NaCl, cripto++, RELIC, polarssl, GnuTLS...)
* Checagem a integridade de código fonte e binários deve ser a regra (assinaturas, compilação determinística).

Protocolos e Serviços
=====================

* Superar problemas difíceis.
* Disputar com protocolos e serviços menos seguros.
* Conseguir o apoio da base de usuários/as.

Financiamento
=============

* Desenvolvimento em seguraça custa caro pois demanda estudo e cuidado!
* Crowdsourcing e micropagamentos.
* Modelos de negócios diretos ao invés da espionagem e mineração de dados, com serviços massivos a preços acessíveis.
* Que permita auditoria dos softwares, plataformas e serviços.

Educação
========

* Maior acesso ao público de informações sobre segurança.
* É preciso incentivar uma nova geração de estudantes de criptografia! :)

Legislação
==========

* Marcos regulatórios compatíveis com requisitos de privacidade (sem retenção de dados, por exemplo).
* Mesmo num cenário draconiano a tecnologia consegue evadir medidas de vigilância.

Fim
===

* Perguntas?
* Podemos fazer previsões para os próximos cinco e dez anos?
* rhatto @ sarava.org / https://seguranca.sarava.org / https://oblivia.vc
* OpenPGP 66CA 01CE 2BF2 C9B7 E8D6  4E34 0546 8239 64E3 9FCA