Local blog for Italian speaking developers
Adiantum: crittografia per NBU (Next Billion Users)
21 febbraio 2019
Pubblicato da Paul Crowley ed Eric Biggers, Android Security & Privacy Team
La crittografia di archiviazione protegge i dati qualora il tuo telefono dovesse capitare nelle mani sbagliate Adiantum è innovativo in questo senso perché rende la crittografia di archiviazione più efficiente per i dispositivi senza accelerazione crittografica e garantisce che
tutti
i dispositivi possano essere crittografati.
Oggi Android offre la crittografia di archiviazione utilizzando Advanced Encryption Standard (AES). La maggior parte dei nuovi dispositivi Android offre il supporto hardware per AES tramite le ARMv8 Cryptography Extensions. Tuttavia, Android funziona su una vasta gamma di dispositivi, ossia non solo i telefoni più avanzati e di fascia media, ma anche i telefoni
Android Go
di livello base venduti principalmente nei paesi in via di sviluppo, insieme a
smart watch
e
TV
. Per offrire opzioni a costi inferiori, i produttori di dispositivi utilizzano a volte processori di fascia bassa, come ARM Cortex-A7, che non fornisce il supporto hardware per AES. Su questi dispositivi, AES è così lento da non offrire una buona esperienza utente, perché le applicazioni possono richiedere molto più tempo per essere avviate e di solito il dispositivo risponde più lentamente. Pertanto, anche se la crittografia di archiviazione era già
richiesta
per la maggior parte dei dispositivi a partire da Android 6.0 nel 2015, i dispositivi con prestazioni AES scadenti (50 MiB/sec e inferiori) sono esenti. Ci siamo impegnati per cambiare questo aspetto perché crediamo che la crittografia sia importante per tutti.
Grazie alla crittografia HTTPS, questo problema è stato risolto. La
crittografia stream ChaCha20
è molto più veloce di AES quando l'accelerazione hardware non è disponibile e al contempo è estremamente sicura. È veloce perché si basa esclusivamente su operazioni supportate nativamente da tutte le CPU: aggiunte, rotazioni e XOR. Per questo motivo,
nel 2014 Google ha scelto ChaCha20
in concomitanza con l'
autenticatore Poly1305
, anch'esso veloce nel software, per una nuova suite di crittografia TLS che consente di proteggere le connessioni Internet HTTPS. ChaCha20-Poly1305 è stato standardizzato come
RFC7539
e migliora notevolmente le prestazioni HTTPS su dispositivi privi di istruzioni AES.
Tuttavia, la crittografia di dischi e file rappresenta una problematica particolare. I dati sui dispositivi di archiviazione sono organizzati in "settori" generalmente di 4096 byte. Quando il file system effettua una richiesta al dispositivo per leggere o scrivere un settore, il livello di crittografia intercetta quella richiesta e la converte da testo non crittografato a crittografato. Ciò significa che dobbiamo effettuare una conversione da testo non crittografato con 4096 byte a quello crittografato con 4096 byte. Tuttavia, per usare RFC7539, il testo crittografato deve essere leggermente più grande del testo non crittografato per poter lasciare lo spazio necessario per il
nonce
crittografico e le informazioni sull'
integrità del messaggio
. Esistono tecniche software per trovare dove archiviare queste informazioni supplementari, ma riducono l'efficienza e possono rendere più complessa la progettazione del file system.
Quando AES viene utilizzato, la soluzione classica per la crittografia del disco è utilizzare le modalità operative XTS o CBC-ESSIV, che preservano la lunghezza. Attualmente Android supporta AES-128-CBC-ESSIV per la crittografia su disco completo e AES-256-XTS per la crittografia basata su file. Tuttavia, se le prestazioni di AES non sono soddisfacenti, non esiste un'alternativa ampiamente accettata che offra prestazioni valide per i processori ARM di fascia bassa.
Per risolvere questo problema, abbiamo progettato una nuova modalità di crittografia chiamata
Adiantum
. Adiantum ci consente di utilizzare il codice stream ChaCha in una modalità di preservazione della lunghezza, adattando le idee da proposte basate su AES per la crittografia che preserva la lunghezza, come
HCTR
e
HCH
. Su ARM Cortex-A7, la crittografia e decrittografia di Adiantum su settori a 4096 byte è di circa 10,6 cicli per byte, circa 5 volte più veloce di AES-256-XTS.
A differenza di modalità come XTS o CBC-ESSIV, Adiantum è una vera modalità wide-block: la modifica di qualsiasi bit in qualsiasi parte del testo non crittografato modificherà in modo inequivocabile tutto il testo crittografato e viceversa. Funziona eseguendo prima un hash di quasi tutto il testo non crittografato grazie a un hash con chiave basato su Poly1305 e un'altra funzione di hash con chiave molto veloce chiamata NH. Abbiamo anche eseguito l'hash di un valore chiamato "tweak" che viene utilizzato per garantire che i diversi settori siano crittografati in modo diverso. Questo hash viene quindi utilizzato per generare un nonce per la crittografia ChaCha. Dopo la crittografia, eseguiamo nuovamente l'hash, in modo da avere la stessa intensità nella direzione della decrittografia di quella della crittografia. Tutto questo è organizzato in una configurazione nota come rete Feistel, che consente di decrittografare ciò che abbiamo crittografato. È richiesta anche una singola chiamata AES-256 su un blocco da 16 byte, ma per gli input da 4096 byte questa parte non è critica dal punto di vista delle prestazioni.
Le primitive crittografiche, come ChaCha, sono organizzate in "round", e ogni round aumenta la confidenza nella sicurezza a scapito della velocità. Per rendere la crittografia del disco sufficientemente veloce su un'ampia gamma di dispositivi, abbiamo deciso di adoperare la variante a 12 round di ChaCha piuttosto che quella a 20 round più comunemente usata. Ogni round aumenta notevolmente la difficoltà di attacco; la variante da 7 round è stata compromessa nel 2008, e sebbene molti paper siano migliorati in relazione a questo attacco, fino ad ora non è noto nessun attacco su quella a 8 round. Il rapporto tra round utilizzati e compromessi in realtà risulta migliore per ChaCha12 rispetto ad AES-256.
Anche se Adiantum è appena stato introdotto, sappiamo di poter contare sulla sua sicurezza. Nel nostro paper dimostriamo che possiede buone proprietà di sicurezza, con il presupposto che ChaCha12 e AES-256 siano sicuri. Questa è una pratica standard in crittografia: dalle "primitive" come ChaCha e AES creiamo "costruzioni" come XTS, GCM e Adiantum. La maggior parte delle volte possiamo offrire argomenti validi ma non una prova schiacciante che le primitive siano sicure; al contrario, possiamo dimostrare che se le primitive sono sicure, lo sono anche le costruzioni che creiamo usandole. Non dobbiamo fare supposizioni su NH o sulla funzione hash Poly1305, poiché questi hanno dimostrato di possedere la proprietà crittografica ("ε-almost-∆-universality") su cui ci basiamo.
Adiantum prende il nome dal genere botanico della felce capelvenere, che nel linguaggio vittoriano dei fiori (floriografia) rappresenta la sincerità e la discrezione.
Risorse aggiuntive
I dettagli completi relativi alla progettazione e alla prova sulla sicurezza sono contenuti nel nostro paper
Adiantum: length-preserving encryption for entry-level processors
di IACR Transactions on Symmetric Cryptology, che sarà presentato alla conferenza Fast Software Encryption (FSE 2019) a marzo.
Le implementazioni generiche e ARM-ottimizzate di Adiantum sono disponibili nei
kernel comuni di Android v4.9 e versioni successive
e nel
kernel Linux mainline v5.0 e versioni successive
. Il codice di riferimento, i vettori di test e una suite di benchmarking sono disponibili su
https://github.com/google/adiantum
.
I produttori di dispositivi Android possono
abilitare Adiantum
per la crittografia basata su disco completo o su file per dispositivi con prestazioni AES <= 50 MiB/sec e avvio con Android Pie. Se si dispone del supporto hardware per AES, AES è più veloce di Adiantum, ma AES deve essere comunque utilizzato se le prestazioni sono superiori a 50 MiB/sec. In Android Q, Adiantum farà parte della piattaforma Android e intendiamo aggiornare il
Compatibility Definition Document di Android
(CDD) per richiedere che tutti i nuovi dispositivi Android vengano crittografati utilizzando uno degli algoritmi di crittografia consentiti.
Riconoscimenti: in questo post ci siamo avvalsi dei contributi di Greg Kaiser e Luke Haviland. Adiantum è stato progettato da Paul Crowley e Eric Biggers, implementato in Android da Eric Biggers e Greg Kaiser, e denominato da Danielle Roberts.
Etichette
Android
Firebase
machine learning
Google Cloud Platform
GDL
Eventi
Google Developers Live
Google Play
TensorFlow
App
Chrome
Cloud
api
GDLItalia
GDE
GDG
Google Assistant
iOS
Kotlin
Actions on Google
Deep Learning
AppEngine
AMP
BigQuery
Cloud Functions
Flutter
Android Studio
Google Developers Expert
Università
Google AppEngine
JavaScript
AI
Android Wear
GAE
Google Play Store
HTML5
Maps
security
Android App Development
AngularJS
IoT
Kubernetes
Annunci
Cloud Firestore
Cloud Machine Learning
Google I/O
Polymer
Android Things
Community
DevTools
Google App Engine
intelligenza artificiale
Entrepreneurship
Firebase Analytics
GSoC
Games
Google Cast
ML
open source
Crashlytics
Dart
Diversity
Drive
Google Data Studio
Google Play Games
TensorFlow Lite
Android Developers
Android O
Cloud Spanner
Cloud TPU
Compute Engine
DevFest
Google Compute Engine
Google Developers
Material Design
Mobile
PWA
Python
Startup
AIY Project
ARCore
Android Jetpack
AndroidDev
Androidq
Apps Script
Artificial Intelligence
Augmented Reality
Firebase Cloud Messaging
Google Cloud
Google Maps
Gsuite
IO19
ML kit
Research
VR
coding
unity
#io19
AR
Android Dev Summit
Android Developer
Android Q
Cardboard
Cloud AI
Coral
Developers
Dialogflow
Firebase Realtime Database
Gmail
Google AI
Google Cloud Messaging
Google ContainerEngine
Google Play Console
Kotlin Coroutines
NLP
Programming
Responsive Design
TensorFlowjs
Testing
WTM
Women
beacons
cloud storage
developer
node JS
student programs
women techmakers
API Cloud Vision
Add-ons
Android P
AndroidDevStory
Animation
AutoML
Brillo
Classroom
DSC
Database
Developer Student Clubs
Edge TPU
Fabric
Featured
Flutter Web
G Suite
GWT
GoLang
Google
Google Brain
Google Cloud Next
Google Container Engine
Google Developer Groups
Google I/O Extended
Graph
Hosting
Instant Apps
Keras
Livedata
Mobile Sites
Prediction
Privacy
Project Tango
SDK
Stackdriver
Tales
UI
Udacity
Virtual Reality
Web
Web Development
YouTube
analytics
android security
api.ai
courses
google io
indies
natural language processing
reti neurali
sign-in
young developers
2d Animation
3d
AIY
ARkit
Adversarial Learning
Alpha
Android App
Android App Developmen
Android App bundle
Android Architecture
Android Architecture Components
Android Auto
Android Automotive OS
Android Dev Summit Android Developer
Android Developer Challenge
Android Developers GooglePlayAwards
Android Development
Android Go
Android Instant App
Android Pie
Android Q Scoped Storage
Android Q audio
Android Styles
Android audio playback capture
Android codelabs
AndroidTV
AndroidX
Angular
Aogdevs
Api Design
App Development
App Distribution
Apps
Architecture
Architecture Components
Arduino
Best Practices
Betatesting
Bugs
C++
Certification
Cloud Anchors
Cloud Next
Cloud Run
Cloud Service Platform
Cloud Shell
Cloud Study Jam
Coached Conversational Preference Elicitation
Commerce
Community Connector
Computer Science
Consistency
Containers
Converge
Conversation Design
Crash Reporting
DLS Design
Dagger
Data Science
Databases
Dependency Injection
Design
Developer Communities
Developer Community
Developer Culture
Developer Story
Developing Media Apps
Development
Eager
Edge TPU Dev Board
Education
Emulatore Android
Error Message
Eslint
Europe
Firebase Extensions
Firebase Summit 2019
Firebasehosting
Flutter 1.5
Flutter at IO
FlutterDark
GCE
GDD
Game Development
Gboard
Gesture Navigation
Glass
Go
Google AI Quantum
Google App Script
Google Cloud Functions
Google Cloud billing
Google Coral
Google Developer Days
Google Home Hub
Google IOS Android
Google Identity Platform
Google Launchpad
Google Lens
Google Now
Google Photos
Google Play Devs
Google Play Indie Games Festival
Google Play Instant
Google Plus
Google codelabs
Google+
GoogleDevWeekly
GoogleLaunchpad
GooglePlay
Graphics
Healthcare
I/O
IO
IO19 Flutter
In-app Billing
Indie Games
Indie Games Festival
Indie games showcase
Indie showcase
Ingress
Instant Games
Issues
Java
Jetpack
Knative
Kotlin Beginners
Kotlin Everywhere
Kotlin codelabs
Lighthouse
Live Caption
Live Streaming
Localization
Location
M-Theory
Mondaygram
Monetization
NYT
NativeScript
Navigation
Neural Graph Learning
Neural Structured
Nodejs
OS
OS Updates
Olivex
One Time Codes
Online Education
PHA
Performance Monitoring
Policy
Posenet
Project Mainline
Project Treble
Quantum Computing Theory
Reactive Programming
Regression
Remote Config
Resonance Audio
Room
Scoped Storage
Semantics
Semi Supervised Learning
Serverless
Sms Retriever Api
Sms Verification
Speech Recognition
Swift
Tensorflow Core
Tensorflow Hub
Test Lab
Text
Tokenizer
Tpu
Transformers
UX
UX Design
UX Research
Universal Sentence Encoder
Unsupervised Data Augmentation
Unsupervised Learning
User Experience
Viewmodel
Voice
WWW
Wear OS
WebAssembly
Widget
Women in Tech
WomenTechmakers
android kotlin
app stability
assistant
audio recording
augmented faces
authsub
best practices and updates
billing
botnet
business
c++ games
cancer
chatbot
chrome privacy
codelab
codelabs
competition
daydream
designer
dominio .dev
error handling
event
firebase games
firebase gdc
firebase hosting
firebase unity
game center authentication
game testing
games authentication
gdc
google summer of code
googledevelopers
grow
hashcode
indie
indie developers
internship
kids
machine intelligence
machine learning accelerator
maker
multi-platform
nearby
oauth
openid
performance
persistent AR
privacy sandbox
prizes
prototype
purchase flows
queries
realtime
responsible AI
security rules
showcase
solutions challenge
startup africa roadtrip
startup times
students
summer of code
unity crashlytics
verify apps
win
Archivio Blog
2020
feb
gen
2019
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2018
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2017
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2016
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2015
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2014
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2013
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
Feed
Follow @GoogleDevsItaly