
Spanish: 
Hola a todos.
Hablaremos de la encriptación
de datos en Android.
Me llamo Jon Markoff.
Soy Developers Advocate
de seguridad en Android.
Hola, soy Nicole Borrelli
y soy ingeniera en programas
para desarrolladores.
Hoy, vamos a hablar sobre tres temas:
Administración de claves
y autorización de claves,
operaciones de encriptación
(como encriptación, bloqueo
y desbloqueo de datos)
y sobre algunos temas
más avanzados
de cosas que van más allá
de lo que la seguridad de Jetpack hace.
Entonces, antes de comenzar...
La primera vez que di esta charla,
vi esto y me quedé pensando:
“¿Qué está pasando aquí?”
¿Hay alguna advertencia,
la advertencia es sobre la respuesta
o es sobre qué dice la advertencia?
Hay muchas advertencias aquí.
Si encuentran esta publicación
de Stack Overflow,

Indonesian: 
-Hai, semuanya.
Terima kasih sudah datang
di enkripsi data Android.
Saya Jon Markoff,
developer advocate
untuk keamanan Android.
-Hai,
saya Nicole Borrelli,
engineer program developer.
-Hari ini, kita akan
bicara tentang tiga topik,
yaitu manajemen kunci
dan otorisasi kunci,
operasi enkripsi, termasuk
mengenkripsi, mengunci,
dan membuka kunci data.
Terakhir, beberapa topik lanjutan
untuk hal-hal yang sedikit
di luar dari
cara kerja keamanan Jetpack.
Sebelum kita mulai--
-Jadi saat pertama kali
saya menyampaikan ini,
saya melihat ini
dan berpikir, jadi apa
yang salah dengan ini?
-Ya, jadi--
-Apakah ada peringatan,
misalnya tentang jawaban,
atau tentang isi peringatan itu?
-Ada banyak peringatan di sini.
Jika Anda menemukan postingan
Stack Overflow ini,

Chinese: 
大家好 感谢前来参加 Android 数据加密话题的演讲
我是 Jon Markoff
是 Android 安全团队的开发推广工程师
我是 Nichole Borrelli 开发者项目工程师
今天我们想讲三个话题
密钥管理与密钥认证
加密操作 也就是对你的数据进行加密和解密
以及一些比较高级的话题
涉及 Jetpack Security 能力之外的内容
在开始之前
我第一次准备这次演讲的时候 看到了它
然后我就在想：它错在哪里？
是为警告而警告 还是要看警告的内容？
处理这方面问题的时候会遇到很多警告
通常 如果你在 Stack Overflow 找帖子的话

Korean: 
안녕하세요
Android 데이터 암호화 회의에
참석해 주셔서 감사합니다
저는 Android 보안팀의
개발자 지원 담당자인
존 마코프입니다
안녕하세요
저는 개발자 프로그램 엔지니어
니콜 보렐리입니다
오늘 우리는 세 가지 주제를
다룰 예정인데요
키 관리 방식과 키 인증,
암호화 작업에 대해 설명드립니다
암호화 작업은 데이터 암호화,
잠그기, 잠금 해제를 포함합니다
마지막에는
Jetpack 보안과는
다소 관련성이 낮은
고급 주제를 몇 가지
다루겠습니다
우선 시작하기 전에...
이런 내용을 처음 진행할 당시
이런 문제가 떠올랐습니다
어디에 문제가 있는가 하는
의문이었죠
그러니까...
경고가 답을 찾는 데
도움이 되는지
경고가 말해주는 것이
전부인지에 대한
의문 말입니다
이 문제에 대해서
많은 경고가 있습니다
이 Stack Overflow 포스트를 찾으려면

Portuguese: 
Olá.
Obrigado pela presença
em "Criptografia de dados no Android".
Meu nome é Jon Markoff,
sou mediador de desenvolvedores
em segurança no Android.
Olá, meu nome é Nicole Borrelli,
sou engenheira
de programas para desenvolvedores.
Hoje falaremos
sobre três tópicos.
Falaremos sobre gerenciamento
e autorização de chaves,
operações de criptografia,
para criptografar,
bloquear e desbloquear dados.
Por último, alguns tópicos avançados
sobre recursos não inclusos
no Jetpack Security.
Antes de começar…
Da primeira vez
que fiz esta apresentação, vi isto
e pensei:
qual é o problema exatamente?
O aviso se refere
à resposta
ou ao que ele mesmo diz?
Há muitos avisos aqui.
Se você encontrar
esse post no Stack Overflow…

English: 
[MUSIC PLAYING]
JON MARKOFF: Hey, everyone.
Thanks for joining us for
data encryption on Android.
My name is Jon Markoff, and
I'm a developer advocate
on Android security.
NICOLE BORRELLI: Hi,
and I'm Nicole Borrelli,
and I'm a developer
programs engineer.
JON MARKOFF: So
today, we're going
to talk about three topics.
So we're going to talk
about key management
and authorizing keys,
encryption operations--
so that's encrypting, locking,
and unlocking your data.
And finally, some
more advanced topics
for things that are a
little bit outside of what
Jetpack security does.
So before we jump right in--
NICOLE BORRELLI:
So the first time
that I was giving
this talk, I saw this
and I was thinking
to myself, so what
exactly is wrong with this?
JON MARKOFF: Yeah, so--
NICOLE BORRELLI: Is
there a warning-- is
the warning about the
answer, or is the warning
about what the warning says?
JON MARKOFF: There's a
lot of warnings on this.
So if you actually find
this Stack Overflow post,

Japanese: 
[音楽]
こんにちは
今日はデータ暗号化の話をします
Androidセキュリティの
ジョン・マルコフです
こんにちは
ニコル・ボレリです
開発者プログラムエンジニアです
さて
今日話す３つのトピックは
キー管理と
キーの承認と暗号化操作です
つまりデータの暗号化 ロック 解除です
最後にJetpackセキュリティ以外の
より高度な点について話します
では 始める前に
初めて
この話をした時に
思ったのです
実際 何が問題なんだろう？
それは
それは警告なのか？
答えに対する警告？それとも
警告が言っていることへの警告なのか？
この件に関しては
多くの警告があります

Portuguese: 
É só procurar
por "Android encryption AES",
"Android encryption symmetric",
algo assim.
É o primeiro resultado
ao procurar como criptografar dados
no smartphone ao criar um app.
Como você pode ver,
há muitos elementos suspeitos.
Ao criar um app, a segurança dos dados
é muito importante.
Aqui temos vários avisos do tipo:
"Não faça isso, isso é errado",
o que não ajuda.
O maior problema é que isso é de 2011.
Hoje isto está completamente errado.
Não ajuda em nada.
O maior problema
é que ele não usa o Android keystore,
que é uma maneira segura
de gerenciar chaves
e evitar que as pessoas
tenham acesso a dados criptografados.
No Google I/O deste ano,
lançamos o Jetpack Security,
que permite criptografar facilmente dados,
arquivos e preferências compartilhadas
sem precisar entender
os detalhes de segurança.
Uma dúvida que eu tinha era a seguinte:
o Android é um sistema operacional seguro.
Falamos sobre isso ontem.

Japanese: 
スタックオーバーフローの投稿は
Android暗号化AESにあります
実際暗号化方法を検索すると
トップの検索結果として表示されます
ここには次のように
疑わしいものがたくさんあるので
アプリ構築時にデータを保護することは
重要です
そしてここでは
警告が表示されますが
全く役に立ちません
そして最大の問題は
これは2011年のものですが
完全に間違っています
役に立ちません
ここで一番大きな問題は
Androidキーストアを
使用していないことです
これはキーを管理し 暗号化したデータに
アクセスできないようにします
Google IOは
Jetpackセキュリティを発表しました
セキュリティの詳細を知らなくても
データや共有設定を簡単に
暗号化できます
私が疑問に思ったのは
Androidは安全なOSなのか
ということです
これは昨日話しました

English: 
you can find it by looking up
the Android encryption AES,
Android encryption symmetric--
something like that.
It's actually the
top result when
you try to figure out
how to encrypt data
in an app on your phone
when you're building an app.
And as you can see, there's
a lot of things here
that might be kind of
suspect as to-- when you're
trying to build an app,
securing data and things
is really important.
And here, there's several
warnings, like don't do this--
this is wrong--
so it's completely unhelpful.
And the biggest issue
here is this is from 2011.
So this is completely
wrong at this point,
it doesn't really help you.
And the biggest
issue really here
is that it doesn't use Android
key store which is a safe way
to manage keys and
basically prevent someone
from getting access to the
data that you've encrypted.
So at Google IO this
year, we launched
Jetpack security,
which basically allows
you to easily encrypt your data,
files, and shared preferences
without having to
really understand
the ins and outs of security.
NICOLE BORRELLI: So
the question I had is--
so Android is a secure
operating system.
We talked about this yesterday.

Spanish: 
pueden encontrarla si buscan
la encriptación AES,
encriptación simétrica de Android,
o algo así.
Es el primer resultado cuando quieren
saber cómo encriptar datos
en una app de su teléfono
cuando crean una app.
Y, como pueden ver,
hay muchas cosas aquí
que podrían ser sospechosas...
si intentan crear una app,
es importante asegurar
sus datos y sus cosas.
Aquí hay varias advertencias,
como “No haga esto, está mal”.
“Esto no ayuda en nada”.
El mayor problema aquí
es que es de 2011.
Entonces, en este punto,
es completamente incorrecto,
realmente no ayuda.
Y el mayor problema aquí
es que no usa el almacén de claves
de Android, una forma segura
de administrar claves
y evitar que alguien
acceda a los datos que encriptaron.
Este año, en Google IO, lanzamos
la seguridad de Jetpack,
que, básicamente, permite
encriptar datos, archivos
y preferencias compartidas
sin tener que entender
los pormenores de la seguridad.
Entonces, mi pregunta es:
“¿Android es un sistema
operativo seguro?”
Hablamos sobre esto ayer.

Indonesian: 
Anda bisa temukan
di enkripsi AES Android,
enkripsi simetris Android,
atau semacamnya.
Itu hasil teratas
saat mengenkripsi data
di aplikasi atau ponsel
saat membuat aplikasi.
Seperti yang terlihat,
ada banyak hal di sini
yang mungkin mencurigakan.
saat membuat aplikasi,
mengamankan data
sangat penting.
Di sini, ada beberapa peringatan,
misalnya jangan lakukan ini,
ini salah,
jadi ini tidak membantu.
Masalah terbesarnya
adalah ini dari tahun 2011.
Jadi ini sangat salah
dan tak membantu Anda.
Masalah besar
lainnya adalah
di sini tidak digunakan keystore Android,
yang merupakan cara aman
untuk mengelola kunci
dan mencegah seseorang
mengakses data
yang telah Anda enkripsi.
Di Google IO tahun ini,
kami luncurkan
keamanan Jetpack,
yang memungkinkan Anda dengan mudah
mengenkripsi data, file,
dan preferensi bersama
tanpa harus memahami
keamanan secara detail.
-Jadi, pertanyaan saya adalah,
karena Android adalah
sistem operasi yang aman.
Kita bicarakan ini kemarin.

Korean: 
Android 암호화 AES나
Android 암호화 Symmetry 등을
검색해서 찾을 수 있습니다
앱을 제작할 때
휴대전화의 앱에서
데이터를 암호화하는 방법을
고안할 때 매우 효과적입니다
보시다시피 의심스러운
점들이 많습니다
앱을 제작할 때
데이터와 제반 사항에 대한
보안은 매우 중요합니다
무언가를 하지 말라거나
무언가가 잘못되었다는 식의
여러 경고가 있지만
전혀 도움이 되지 않습니다
가장 중요한 문제는
2011년에 제기된 이것입니다
현재로서는 완전히 잘못된 것으로
도움이 되지 않습니다
현재 가장 중요한 문제는
키를 관리하고
암호화된 데이터로의 접근을
근본적으로 차단하는
안전한 방법인 Android 키 저장소를
사용하지 않는다는 것입니다
그래서 올해 Google I/O에서는
보안 환경을 세부적으로
파악할 필요 없이
데이터와 파일, 그리고
공유된 환경설정을
쉽게 암호화할 수 있는
Jetpack 보안을 선보였습니다
오늘 한 가지
살펴보고 싶은 것이 있는데요
일단 Android는
안전한 운영체제입니다

Chinese: 
只要搜索 Android encryption AES
Android encryption symmetric 之类关键词
这样的结果就会跳出来
而且当你搜索 如何在构建应用时对自己手机上的数据进行加密 的时候
这个结果的排名是最靠前的
如你所见 这里的内容有很多都像是有用的信息
构建应用时 数据保全是很重要的
而这里有好几个警告 指出这样做是不对的
然而这些警告完全没有意义
而且最大的问题在于 这都是2011年的信息
现在来看已经属于完全错误了
根本帮不到你
最大的问题是 它没有使用 Android Keystore
这是一种安全的密钥保管方式
可以避免别人访问你的加密数据
在今年的 Google I/O 大会上 我们发布了 Jetpack Security
它可以让你在无需深入了解安全领域的前提下
就轻松加密你的数据 文件 以及共享的偏好设置
我遇到的问题是
Android 是一个安全的操作系统
这个我们昨天就谈过

English: 
We've got SE Linux,
we've got user IDs
that separate
things, and we've got
on modern versions
of Android, we've
got file-based
encryption already.
So what is it that we're
using the Jetpack security
library for?
JON MARKOFF: That's
a great question.
So there's a few reasons
you might want to use it.
One, if you're
building an app that's
been running on a rooted or
compromised device in some way,
because the file
system is unlocked
if the user is
present on the device,
that means that even though
you have full disk encryption,
the data is now available to
an attacker or someone that's
getting the device.
Secondly, you might
actually have data
that you don't want
your user to see.
So if you have like
API keys, tokens,
things like that to
authorize services,
you probably don't
want those leaked,
and you probably
don't want anyone
to get access to that
because technically, they
could start pretending to
be you, and using your quota
and getting free things
that you have to pay for.
So the first really
big important thing
here is key management.
So if you have like a car
key, house, or apartment key,
something like that, that's
something you can keep on you
and kind of secure.

Spanish: 
Tenemos SE Linux,
tenemos ID de usuario
que separan cosas y tenemos
versiones modernas de Android.
Tenemos encriptaciones
basadas en archivos.
Entonces, ¿para qué usamos
la biblioteca de seguridad de Jetpack?
Esa es una buena pregunta.
Hay motivos para querer usarla.
Uno, si están desarrollando una app
que se ejecutó en un dispositivo
con derechos de administrador
o comprometido de alguna forma
porque el sistema está desbloqueado
si el usuario está presente,
eso significa que incluso
si todo el disco está encriptado,
los datos están disponibles
para un atacante
o quien tenga el dispositivo.
Dos, podrían tener datos
que no quieren que su usuario vea.
Si tuvieran claves de API, tokens
o algo así para autorizar servicios,
no querrán que se filtren y que alguien
acceda a ellas porque, técnicamente,
podrían hacerse pasar por ustedes
y usar sus datos
para recibir cosas gratis
que ustedes tendrán que pagar.
Entonces, aquí, lo más importante
es la administración de claves.
Si tienen llave del auto,
la casa, el apartamento o algo así,
es algo que cargarán consigo
y de manera segura.

Japanese: 
既にSE LinuxやユーザーIDで分離でき
Androidの最新バージョンには
ファイルベースの暗号化があります
Jetpackセキュリティライブラリは
何に使用するのでしょう？
いい質問です
理由はいくつかあります
１つは ルート化または侵害されたデバイスで
実行されているアプリを構築する場合です
ユーザーがデバイス上にいると
ファイルシステムのロックが
解除されるため
暗号化していても
攻撃者はデータを利用できます
またAPIキーなど
ユーザーに見せたくないものもあります
サービスを許可するものは
知られたくないです
実際 なりすまして
有料のものを
無料で取得する可能性があるので
誰にもアクセスさせたくありません
ここで本当に重要なのは
キー管理です
車の鍵 家やアパートの鍵などは
自分で持っていて
安全に管理できます

Korean: 
우리에게는 식별을 가능하게 해 주는
SE Linux와 사용자 ID가 있고
Android의 최신 버전이 있으며
파일 기반 암호화가
이미 가능합니다
그러면 왜 우리는
Jetpack 보안 라이브러리를
사용하는 걸까요?
좋은 질문입니다
몇 가지 이유가 있습니다
첫 번째로 어떤 방식으로든
노후됐거나 손상된
기기에서 실행되는
앱을 제작하는 경우
사용자가 기기를
사용 중이라면
디스크 전체를
암호화했더라도
공격자 등이 기기에 접근하여
악용할 수 있습니다
두 번째 이유로
사용자가 보면 안 되는
데이터가 있을 수 있습니다
서비스 인증을 위한
API 키나 토큰 같은 것이
유출되거나 누군가가 접근하는 것을
원치 않을 것입니다
왜냐하면 누군가가
접근하여 본인인 척 가장해
비용을 지불해야 하는 서비스를 공짜로
이용할 수 있기 때문입니다
따라서 키 관리가
가장 중요합니다
자동차 키, 집 키나
아파트 키로 보안을
유지하는 것과
같은 것입니다

Chinese: 
我们有 SE Linux 用户 ID 用来分隔不同的内容
在较新的 Android 版本上
我们还配置了基于文件的加密功能
那么 Jetpack Security 代码库的用途要体现在哪里呢？
很好的问题
它值得使用的原因有以下几种
第一 如果你正在构建的应用
一直以来都运行在一台被 root 过或者被攻破的设备上
那么 因为文件系统被解锁了
所以 如果用户使用了这台设备
这就意味着 即使你使用了全盘加密技术
攻击者 或是任何取得设备使用权限的人
还是可以访问你的数据
第二 有些数据可能是你不愿让用户看到的
如果你有一些用来授权各种服务的 API 密钥 令牌等东西
那么你大概是不愿意让它们泄露出去的
而且你大概也不想让任何人来访问它
因为 他们可以假装成你
使用你的指标来免费获取物品 而付账的会是你
所以 第一件重要的事就是 密钥管理
你的汽车钥匙 房子钥匙 公寓钥匙等
可以随身携带 所以可以说是比较安全的

Portuguese: 
Temos o SELinux, IDs de usuários
que separam as coisas
e, nas versões modernas do Android,
temos criptografia baseada em arquivos.
Para que usar
a biblioteca de segurança do Jetpack?
Essa é uma ótima pergunta.
Há alguns motivos para usá-la.
Primeiro, se você estiver criando um app
executado em um dispositivo
com acesso root ou comprometido,
como o sistema de arquivos
está desbloqueado,
se o usuário estiver no dispositivo,
mesmo que haja
criptografia total do disco,
os dados estarão
disponíveis para um invasor
ou alguém com acesso ao dispositivo.
Segundo, talvez você tenha dados
que não queira mostrar ao usuário.
Se você tiver chaves de API, tokens etc.
para autorizar serviços,
não vai querer que eles vazem,
nem que as pessoas tenham acesso a eles,
porque elas poderiam
se passar por você, usar sua cota
e receber serviços de graça
que você precisará pagar.
O primeiro item importante é
o gerenciamento de chaves.
A chave de um carro,
uma casa ou um apartamento
fica com você
de modo seguro.

Indonesian: 
Kita punya SE Linux,
ada ID pengguna
yang memisahkan beberapa hal,
dan ada versi modern Android,
dan enkripsi berbasis file.
Jadi untuk apa
menggunakan librray
keamanan Jetpack?
-Itu pertanyaan bagus.
Ada beberapa alasan
untuk menggunakannya.
Satu, jika Anda membuat aplikasi
yang berjalan di perangkat
yang di-root atau disusupi,
karena sistem file tidak terkunci
jika pengguna ada di perangkat,
itu berarti walaupun Anda punya
enkripsi disk penuh,
data jadi dapat diakses
oleh penyerang atau seseorang
yang mendapatkan perangkat.
Kedua, Anda mungkin punya data
yang tak ingin dilihat
pengguna.
Jadi jika Anda punya kunci API, token,
file otorisasi layanan,
hal ini tak boleh bocor,
atau diakses siapa pun
karena secara teknis
mereka bisa pura-pura jadi Anda,
memakai kuota
dan memanfaatkan item
yang harus Anda bayar.
Hal paling penting
pertama di sini adalah
manajemen kunci.
Jika Anda punya kunci mobil, rumah,
apartemen,
semua itu hal yang Anda simpan
dan membuat Anda aman.

Korean: 
휴대전화나 데이터의 경우
완벽한 물리적 안전을
보장할 수는 없습니다
사용하는 기기가 손상되었거나
누군가가 상태를
악화시켰을 경우
또는 기기를 분실했거나
도난당했을 경우
원하는 대로
키를 보호할 수 있는
방법이 없습니다
본인 수중에 있더라도
기술적인 문제가 생길 경우
해당 키가 본인에게
불리한 방식으로
악용될 수 있습니다
따라서 'Android 키 저장소'로
이 문제를 해결해야 합니다
이는 하드웨어 기반이기 때문에
기기의 별도의 메모리 공간에서
실행됩니다
따라서 앱이 키에 접근할 수 있어도
앱이 키 자료를
알 수는 없으므로
사용자가 키를 조작할 수 없습니다
Jetpack 보안은 키를 만들 때
기본값이 생성되므로
사용자가 보안 사항을 상세히
알고 있지 않아도 됩니다
또한 기기의 별도의 하드웨어 부분인
스트롱 박스라는 기능도
사용할 수 있습니다
별도의 칩이므로
기술적인 면에서
약간 속도가 느려
미미한 성능 저하가
있을 수는 있지만

Spanish: 
Pero con teléfonos o datos,
realmente no pueden garantizar
que esté bien.
Si su dispositivo está comprometido,
alguien tiene permisos de administrador
o lo perdieron o alguien lo robó,
realmente no saben...
no tienen forma de proteger esa clave.
Incluso si está en su bolsillo,
técnicamente, si algo sucede,
se podría usar la clave en contra suyo.
Entonces, podemos evitarlo si usamos
el “almacén de claves de Android”.
Está respaldado por hardware.
Se ejecuta en otro espacio de la memoria;
es decir, aunque la app tiene acceso
a las claves, no puede saber
el material de claves
y ustedes no pueden
conseguirla por su cuenta.
Creamos la seguridad de Jetpack para que,
cuando creen una clave, se creen
valores predeterminados confidenciales
y no tengan que entender
los pormenores de la seguridad.
También pueden usar una caja fuerte,
un espacio aparte
en el hardware en el dispositivo.
De hecho, es un chip separado,
por lo que habrá una leve implicancia
del rendimiento por usarla,
porque técnicamente es más lenta,

Japanese: 
でも 電話やデータを使用する場合
問題がないことを
物理的に確認できません
端末が侵害されたり
誰かがルーティングした場合
または端末を盗まれたとしても
本当にわかりません
キーを保護する方法はありません
ポケットに入っていても
技術的に何か起きても
キーは悪用される可能性があります
そこでAndroidキーストアを使用して
防止します
これはハードウェアでバックアップされ
別のメモリスペースで実行されます
アプリがキーにアクセスできても
キーマテリアルは不明なので
キーを入手できません
Jetpackセキュリティは
キーを作成する時
適切なデフォルトを作成します
端末のハードウェアの別の部分にある
ストロングボックスなども使用できます
これは独立したチップで
少し遅いため
パフォーマンスに若干影響がありますが

Portuguese: 
No entanto, com smartphones ou dados,
não há como garantir
a segurança fisicamente.
Se o dispositivo for comprometido,
se alguém habilitar o acesso root,
se você perder o dispositivo
ou se ele for roubado,
não há como proteger essa chave,
porque, mesmo no seu bolso,
se algo acontecer,
a chave pode ser usada contra você.
Para solucionar isso, usamos um recurso
chamado "Android keystore".
Ele é baseado em hardware,
ou seja, é executado em um espaço
de memória separado no dispositivo.
Assim, mesmo se o app
tiver acesso às chaves,
ele não identifica o material delas.
Você não tem acesso à própria chave.
O Jetpack Security foi criado
de modo que,
ao criar uma chave, ele gera padrões.
Você não precisa entender
os detalhes de segurança.
Podemos usar recursos como o strongbox,
que é um hardware separado
no dispositivo,
um chip separado.
Por isso, haverá um pequeno impacto
sobre o desempenho,
porque ele é um pouco mais lento.

English: 
But with phones
or with data, you
can't really just physically
make sure that it's OK.
If your device is
compromised in some way,
and if someone has rooted
it, or if you've actually
lost your device and it's been
stolen, you don't really know--
you don't have a
way of protecting
that key like you do.
Because even if
it's in your pocket,
technically if
something's happened,
that key could be used
against you in some way.
So we get around this
by using something
called the "Android keystore."
It's hardware
backed, so that means
that it runs in
a separate memory
space on the device, which means
even though your app has access
to the keys, your
app actually doesn't
know what the key material
is, so you can't actually
get the key yourself.
The Jetpack
security, we built it
so that when you create a key,
it creates sensible defaults
so you don't have to
understand all the ins
and outs of security.
You can also use
features like strong box
which is actually a
separate piece of hardware
on the device.
And that actually
is a separate chip,
so there will be a
slight performance
implication from
using it because it
is a little bit
slower technically,

Indonesian: 
Tetapi dengan telepon atau data
Anda tak bisa secara fisik
memastikan semuanya baik.
Jika perangkat Anda disusupi,
dan ada yang melakukan root,
atau ponsel Anda
hilang dan dicuri,
Anda tak bisa tahu,
dan tidak punya cara
melindungi kunci.
Sebab bahkan jika ada
di kantong
secara teknis jika terjadi sesuatu,
kunci bisa dipakai untuk
menyerang Anda.
Jadi kita atasi
hal-hal seperti ini
dengan "Keystore Android".
Ini didukung hardware, artinya
berjalan di ruang memori terpisah
di perangkat, artinya
walau aplikasi punya akses
ke kunci, aplikasi tak tahu
apa material kunci,
bahkan Anda pun
tidak bisa mengambil kunci.
Kami bangun Keamanan Jetpack
agar saat Anda membuat kunci,
ada default praktis
jadi Anda tak perlu memahami
semua detail keamanan.
Ada juga fitur strong box
yaitu hardware terpisah
pada perangkat.
Itu adalah chip terpisah,
jadi performa akan sedikit terpengaruh
jika menggunakannya
karena secara teknis
lebih lambat,

Chinese: 
但是如果是手机或者数据的话
那么你其实没有什么物理的办法来确保它是安全的
如果你的设备被以某种形式攻破了
如果有人 root 了它 或是偷走了它
那么你其实没有办法用保护车钥匙的方式来保护它
因为 即使你的手机就放在你的裤兜里
技术上讲 如果出现了事故
别人依然可以使用你的密钥来做出对你不利的事来
我们解决这个问题的方式是
推出了 Android Keystore
它是由硬件支撑的
这意味着 它运行在设备中单独的存储空间里
也就是说 即使你的应用可以访问密钥
你的应用也仍然不知道密钥是由什么构成的
所以你还是拿不到密钥本身
我们构建 Jetpack Security 的意图是
当你创建密钥的时候
它自带大家常用的完整功能 (sensible default)
这样你就不需要再去了解那些安全领域的专业知识了
你也可以使用诸如 Strong Box 这样的功能
其实这个功能就是设备上的一个单独的硬件
一块单独的芯片
所以 使用它可能会对应用性能表现产生轻微影响
因为 技术上讲 它的速度较为缓慢

Spanish: 
pero también es una forma
muy segura de manejar sus datos.
Todas las operaciones sucederán
en este espacio separado de la memoria,
por lo que si encriptan o desencriptan
la firma o algo similar,
sabrán que la clave no se filtrará
en su aplicación.
Entonces, si alguien espía
lo que están haciendo, estarán protegidos.
Para comenzar, en la seguridad de Jetpack,
brindamos una clase de claves maestras
que permiten crear claves
e ingresar un almacén de claves.
Lo que quiero decir es que usar
AES-256 es estándar.
Eso significa encriptación avanzada
estándar de 256 bits.
Esta es la clave que usarán
prácticamente para todo.
Es segura y reconocida.
Aquí dice "especificación de GCM".
Usamos GCM con modo de bloqueo
y no rellenamos nada.
Entonces, si quieren encriptar
una pequeña cantidad de datos
que es igual o menor a la clave,
realmente no necesitan relleno o bloqueo.
Algo importante es que ocurren
muchos ataques y riesgos
con la encriptación si los datos
son mayores a la longitud de la clave.

Chinese: 
不过 用这种方式来管理数据其实是相当安全的
所有操作都会在单独的运存中进行
也就是说 当你进行加密-解密签名之类操作的时候
你就会知道 密钥不会泄露到应用中
所以 如果有人在用某种方式监视你的话 你就会没事
在 Jetpack Security 中
我们会在起步阶段提供 MasterKey 类
它可以让你创建密钥 并进入 Keystore
它会默认使用 AES-256 加密
这意味着 它的加密标准是常见的256位
这就是平时常用的密钥的体积
它很安全 而且广为人知
大家可能还会注意到 这里还写着 GCM_SPEC
我们使用 GCM 区块模式 并且不做代码填充
如果你想要对文件体积相当于一个密钥的少量数据进行加密
那么你其实不需要代码填充和区块模式
需要注意的是 在加密方面 很多的攻击和难题
都发生在当数据长度大于密钥长度的时候

Korean: 
데이터 관리를 위한
매우 안전한 방법입니다
모든 작업이 이 별도의 
메모리 공간에서 이루어집니다
암호화하고 복호화할 때
키가 애플리케이션으로
유출되지 않을 거라고
안심할 수 있습니다
따라서 누군가
작업을 훔쳐보더라도
문제되지 않습니다
Jetpack 보안에서는
처음 사용할 때부터
키를 생성하여
키 저장소를 입력할 수 있는
마스터 키 클래스가 제공됩니다
기본 설정으로
AES-256를 사용하는데
고급 암호화 표준인
256비트를 사용합니다
일반적인 크기이면서도
상당히 광범위한 용도를 지닌 키이며
안전하고 친숙한 방식입니다
GCM 사양이란 것도 보이는데
차단 모드 GCM을
사용하며 패딩을 사용하지 않습니다
키 길이 이하에 해당하는
소량의 데이터를 암호화할 때는
패딩이나 차단 모드가 필요치 않습니다
한 가지 중요한 점으로서
키 길이보다 긴 데이터가 있을 경우
암호화 과정에서
많은 공격과 위협이
있을 수 있습니다

Indonesian: 
tapi ini juga cara aman
untuk mengelola data Anda.
Semua operasi akan berjalan
di ruang memori terpisah,
artinya jika
menandatangani enkripsi-dekripsi
anda tahu bahwa kunci tidak akan
dibocorkan ke aplikasi.
Jadi jika ada yang memata-matai,
Anda akan baik-baik saja.
Di keamanan Jetpack, untuk memulai,
kami memberikan kelas kunci master
agar Anda bisa membuat kunci
dan memasuki keystore.
Dan defaultnya memakai AES-256.
Artinya standar enkripsi canggih,
256 bit.
Itu kunci ukuran normal
yang bisa
digunakan untuk apa pun.
Ini standar aman yang telah dikenal.
Anda juga akan menemukan
spek GCM.
Kami menggunakan
mode blok GCM tanpa padding.
Jika Anda ingin mengenkripsi 
sejumlah kecil data
seukuran kunci atau lebih kecil,
Anda tak perlu padding
atau mode blok.
Yang penting di sini adalah
banyak serangan dan tantangan
terjadi dengan enkripsi
jika data Anda
lebih panjang dari kunci.

Japanese: 
データを管理する安全な方法です
そしてすべての操作は
この別個のメモリ空間で行われます
つまり 暗号化と復号をしても
キーがアプリケーションに漏洩しません
なので誰かが
あなたをスパイしていても
大丈夫です
Jetpackセキュリティは
すぐ使用できるように
キーを作成しキーストアを入力する
マスターキークラスを提供しています
デフォルトでは
AES-256を使用しています
256ビットのAES暗号化標準です
これは何にでも使用できる
通常サイズのキーで
安全です
また GCM仕様なので
ブロックモードGCMを使用し
パディングは行いません
キーサイズ以下の
データを暗号化する場合は
パディングや
ブロッキングモードは不要です
但しキーの長さよりも
長いデータがあると
暗号化で多くの攻撃と
課題が発生します

English: 
but it's also a very safe
way to manage your data.
And all the operations
are going to happen
in this separate
memory space, which
means that if you do
encrypt-decrypt signing,
things like that, you
know that the key is not
leaked into your application.
So if someone is spying on
what you're doing in some way,
you're going to be OK.
So in Jetpack security, to
get started, out of the box,
we provide a master
keys class which
basically allows you to create
a key and enter a keystore.
And that-- I mean the
default is using AES-256.
So that means advanced
encryption standard--
256 bit.
This is the normal
sized key that you'd
use for pretty much anything.
It's safe, it's well known.
You also notice
it says GCM spec.
So we use the block mode
GCM, and we do no padding.
So if you want to encrypt a
small amount of data that's
the key size or less, you
don't really need any padding
or blocking modes.
One thing that's
important here is
that a lot of the
attacks and challenges
happen with encryption
when you have data that's
longer than the key length.

Portuguese: 
No entanto, é uma maneira
muito segura de gerenciar os dados.
Todas as operações ocorrerão
nesse espaço na memória separado.
Assim, ao criptografar,
descriptografar, assinar etc.,
você pode ter certeza
de que a chave não vazará para o app.
Se houver alguém espionando
o que você está fazendo
não haverá problemas.
No Jetpack Security, para começar,
oferecemos uma classe
MasterKeys pronta para uso.
Ela permite criar
uma chave e inserir um keystore.
Por padrão, ela usa AES-256,
que significa:
padrão de criptografia avançado
de 256 bits.
Essa é a chave de tamanho normal,
usada para praticamente tudo.
É um padrão seguro e conhecido.
Observe o GCM_SPEC.
Usamos o GCM
em modo de blocos e sem padding.
Ao criptografar
uma quantidade pequena de dados,
do tamanho da chave ou menos,
não é necessário padding
nem modos de blocos.
É importante notar
que muitos ataques e desafios
de criptografia ocorrem quando os dados
são maiores que a chave.

Korean: 
바로 이런 때
패딩과 차단 모드가 필요하며
Jetpack 보안이
유용합니다
애플리케이션 개발자인 여러분이
유의해야 할 점은
반드시 키를
키 저장소에 보관하거나
키를 안전한 방식으로 생성하거나
앨리어스가 있어야 한다는 겁니다
이를 찾아 나중에
사용할 수 있도록
키가 될 문자열이 있습니다
보다 발전된 설정을 사용해
잠시 후 니콜이 설명할
종류의 키 인증을 사용하여
사용자가 있도록 하려면
다른 옵션이 있습니다
현재는 키가 반드시
256비트이어야 합니다
GCM을 사용하고
패딩은 사용하지 않았습니다
아래에서 보실 다른 옵션인
스트롱 박스 설정이 지원되고
사용자가 있어야 하는 사용자 인증은
완전히 다른 선택적 기능입니다
아시다시피 그 중 일부는
Android Pie 이상에서만
이용 가능합니다
이 경우 동일한 방식입니다
키 생성기에서 생성 가능한
매개변수 특정 객체를 입력하고
기본적인 사항을
이용할 수 있습니다
이를 위해 Jetpack 보안에서
제공하는 사항을 기반으로 앱을

Indonesian: 
Di sinilah gunanya padding dan mode.
Dan ini adalah manfaat lain
keamanan Jetpack.
Sebagai developer aplikasi,
Anda ingin memastikan bahwa
Anda punya kunci
di keystore
atau kunci itu dibuat dengan aman
dan Anda punya alias.
Jadi ada string yang akan jadi kunci
untuk dicari dan digunakan nanti.
Jika ingin setelan yang lebih canggih,
misalnya ingin menggunakan
otorisasi kunci,
yang akan dibahas oleh Nicole,
untuk memastikan ada pengguna,
ada opsi lain yang bisa digunakan.
Saat ini, 
kami mengharuskan kunci 256 bit.
Kami memakai GCM tanpa padding.
Opsi lain yang ada di bawah ini,
seperti
autentikasi pengguna,
dukungan string box,
dan wajib ada pengguna
adalah fitur opsional.
Beberapa di antaranya,
berasal dari Android Pie
ke atas.
Sama halnya di kasus ini,
Anda memasukkan
objek spek parameter keygen
yang bisa dibuat, 
dan dapat menggunakan fitur dasar,
Anda bisa membuat
sebagai tambahan dari keamanan Jetpack

Spanish: 
Entonces, ahí es cuando el relleno
y los modos de bloqueo entran en juego.
Y, eso es algo que la
seguridad de Jetpack
aprovecha por ustedes.
Con respecto a su aplicación,
como desarrolladores solo necesitan
garantizar que tienen una clave 
en el almacén o que crearon una
y tienen un alias.
Hay una secuencia
que va a ser la clave
para buscar y usar más tarde.
Si desean establecer
configuraciones más avanzadas,
si quieren usar
autorización de claves,
que Nicole va a comentar pronto,
para garantizar que haya
un usuario presente, hay otras opciones.
Actualmente, imponemos
que la clave sea de 256 bits.
Usamos GCM y no hay relleno.
Otras opciones que ven abajo,
como dije, autenticación de usuario,
cajas fuertes respaldadas
y usuario requerido
son funciones totalmente opcionales.
Y, como pueden ver, solo son
de Android Pie y versiones posteriores.
Y lo mismo en este caso,
aprueban un objeto de especificación
de parámetros de keygen
que se puede crear y pueden usar el...

Japanese: 
そこでパディングモードと
ブロックモードを導入します
これもJetpackセキュリティの
メリットです
アプリケーション開発者としては
キーストアにキーがあり
安全に生成され
エイリアスがあるかを
確認する必要があります
これを調べて後で使用するための
キーとなる文字列があります
より高度な設定をしたい場合
ある種のキー認証を使用したい場合
ニコルが説明しますが
ユーザーがいることを確認する
オプションがあります
現在 キーは256ビットで
GCMを使用し パディングはなし
以下の別のオプション
ユーザー認証
ストロングボックスの設定
その他の機能はオプションです
この通り一部はAndroid Pie以上のものです
この場合も同じです
作成可能なkeygenパラメーター仕様
オブジェクトを渡し
基本を使用でき

Chinese: 
这些时候才需要使用代码填充和区块模式
而 Jetpack Security 很好地帮助你解决了这个问题
作为开发者 你对你的应用唯一需要关心的地方就是
要么确保你在 Keystore 中保存了密钥
要么确保你的密钥是采用安全方式生成的 而且你使用的是假名
我们提供了一个字符串 用来作为键查找与之对应的信息 以供之后使用
如果你确实想要进行高级设置
也就是使用一些密钥授权功能之类
来确保用户确实在场
Nicole 待会儿讲的就是这方面内容
那么你可以采用我们提供的一些选项
目前我们规定所有密钥必须为256位
我们使用 GCM 不进行代码填充
下面大家可以看到其他的一些选项
如我所说 用户验证 设置 Strong Box 支撑 要求用户在场
这些功能都是可选的
有些功能是从 Android Pie 才开始加入的
和本例相同
你传入可以生成的 KeyGenParameterSpec 对象
然后你可以依据我们在 Jetpack Security 中提供的相关代码

English: 
So that's where padding and
block modes come in place.
And that's again something
that Jetpack security
takes advantage for you.
So as far as your
application as a developer,
you're concerned
about-- you really
just need to make
sure you either have
a key in the keystore or that
it's been generated safely,
and that you have an alias.
So there's a string
that's going to be the key
to look this up and use later.
If you do want to set
more advanced settings--
so that you want to use some
sort of key authorization--
which Nicole will talk
about in a second--
to actually make sure that
there's a user present,
there's other options here.
Currently, we enforce that
the key must be 256 bit.
We used GCM and no padding.
The other options
you see below--
like I said, user
authentication,
set strong box backed,
and user required
are features that
are totally optional.
And some of them, as you can
see, are only from Android Pie
and up.
And the same thing
in this case--
you pass in a keygen
parameter spec object
that can be created, and
you can use the basic--
you can build on top of what
we provide in Jetpack security

Portuguese: 
Nesses casos,
o padding e os modos de blocos são úteis,
e esse é mais um dos benefícios
do Jetpack Security para você.
Em relação ao seu app,
como desenvolvedor,
você só precisa ter uma chave no keystore
ou verificar
se ela foi gerada com segurança
e ter um alias.
Há uma string que será a chave
para encontrar e usar isso mais tarde.
Se quiser definir
configurações mais avançadas,
a fim de usar
algum tipo de autorização de chave,
que a Nicole mostrará daqui a pouco,
para confirmar
se um usuário está presente,
há outras opções.
Atualmente, exigimos
que a chave tenha 256 bits.
Usamos o GCM e nenhum padding.
As outras opções abaixo,
como setUserAuthentication,
setIsStrongBoxBacked
e usuário obrigatório,
são recursos totalmente opcionais.
Alguns deles só estão disponíveis
a partir do Android Pie.
O mesmo se aplica neste caso,
basta passar um objeto KeyGenParameterSpec
que pode ser criado,
e você pode desenvolver com base

Portuguese: 
no que o Jetpack Security oferece.
Obrigada.
No slide anterior,
vimos que podemos criar uma chave
com que o usuário
precisa desbloquear o dispositivo
usando a autenticação com limite de tempo.
A melhor forma de implementar isso
é com o uso de solicitações biométricas.
Basicamente,
a melhor forma de fazer isso
é com a biblioteca AndroidX.
A configuração é muito simples.
Criamos um construtor, definimos o título
e a mensagem.
Em seguida, informamos se o uso
de credenciais será permitido,
essas coisas.
Depois disso, podemos autenticar.
Observe que estamos
usando o recurso com base no tempo,

Spanish: 
pueden construir sobre lo que brindamos
en la seguridad de Jetpack.
Gracias.
En la diapositiva anterior,
vimos que podemos tener una clave
que es donde el usuario tiene
que desbloquear el dispositivo usando
la autorización programada.
Entonces, la mejor forma
de implementar esto
es con solicitudes biométricas.
Esencialmente, podemos...
la mejor forma de hacerlo
es con la biblioteca de AndroidX.
Podemos… es bastante simple de configurar.
Configuramos un compilador,
establecemos nuestro título,
un mensaje.
Luego, decimos si queremos
permitir el uso de credenciales
y esa clase de cosas.
Y podemos autenticar.
Notarán que está basado en el tiempo

Indonesian: 
yang kami sediakan untuk ini.
-Terima kasih.
Jadi ya, di slide sebelumnya
kita tahu bahwa kita bisa
menggunakan kunci
yang mengharuskan
pengguna membuka perangkat
dengan otorisasi berbatas waktu.
Cara terbaik menerapkan ini adalah
dengan perintah biometrik.
Pada dasarnya, kita bisa
melakukan cara terbaik yaitu
dengan library AndroidX.
Cara menyiapkannya cukup mudah.
Kita siapkan builder, buat judul
yang diinginkan,
dan pesan.
Lalu tentukan apakah
penggunaan kredensial diizinkan,
dan semacamnya.
Lalu kita bisa mengautentikasi.
Contoh ini adalah
berbasis pada waktu,

Japanese: 
Jetpackセキュリティで提供する
ものの上に構築できます
前のスライドでユーザーが
期限付き認証を使用して
デバイスのロックを
解除する必要がある場所に
キーがあることを
確認しました
これを実装する最良の方法は
BiometricPromptを使用することです
基本的にこれができるのは
一番いいのは
AndroidXライブラリです
設定はとても簡単です
ビルダーをセットアップし
タイトルにしたいメッセージを
設定します
そして資格情報の使用を許可するかどうかを
設定します
すると認証できます
これは時間ベースなので

Korean: 
제작할 수 있습니다
고맙습니다
지금까지 사용자가
타이머 인증을 사용하여
기기를 잠금 해제해야 하는
키를 사용할 수 있음을
살펴봤는데요
이를 실행하기 위한
최선의 방식은
생체 인식 프롬프트를
사용하는 것입니다
근본적으로 가장 좋은 방식은
AndroidX 라이브러리를
사용하는 것인데
설정은 매우 쉽습니다
빌더를 설정하고
제목과 메시지를 설정합니다
그런 다음
사용자 인증 정보 사용을 허용할 것인지
등의 사항을 설정합니다
그런 다음 인증할 수 있습니다
저희는 시간 기반으로
작업하므로 암호나 서명을

English: 
for this.
NICOLE BORRELLI: Thanks.
So yes-- so on the
previous slide,
we looked at that we
can have a key that
is where the user has to
unlock the device using
the timed auth.
And so the best way
to implement this
is by using biometric prompt.
And essentially, we can--
so this is-- the
best way to do it
is with the AndroidX library.
And we can-- it's
pretty simple to set up.
We set up a builder, set
what we want our title to be,
a message.
And then we say whether we want
to allow using credentials,
that sort of thing.
And then we can authenticate.
You'll notice that
we're doing time based,

Chinese: 
在它的基础之上进行构建
谢谢
在上一张幻灯片中
我们发现 我们可以让密钥拥有这样的属性：
用户必须使用限时验证来解锁设备
想要实现这个功能 最佳的做法就是使用 BiometricPrompt
这方面最好的工具就是 AndroidX 代码库
设置起来相当简单
只需要设置构建器 设置想要的标题 信息
然后表示 是否允许使用认证信息 等等
然后就可以验证了
大家可能会注意到 这些操作是基于时间的

Chinese: 
所以我们不会向那里传送密文或签名
只要这样 然后就有了这个验证回调 就在上面这里
如果验证成功 你就可以使用密钥了
如果验证失败 你就可以向用户展示一条错误提示
这里的错误提示应该是可修复 (recoverable) 的
当然也有可能会出现不可修复的提示
所以你需要查看一下
如果设备没有弹出来任何生物验证提示
请让它回调这里
你在拿到密钥之后 就可以开始操作了
第一件可做的事就是 使用加密文件

Spanish: 
por lo que no vamos a pasar
una criptografía o firmas.
Simplemente voy a hacer esto
y obtendremos la devolución de llamada
de autenticación,
que pueden ver aquí.
Si la autenticación es exitosa,
pueden usar su clave.
Si no lo es, pueden indicar
el error al usuario.
Parte del error...
los errores aquí
deben ser errores recuperables.
También hay errores no recuperables
que pueden aparecer.
Querrán verificarlos y asegurarse de que…
si el dispositivo no tiene ninguna
clase de solicitud biométrica,
devolverá la llamada aquí.
Una vez que tengan la clave,
podemos hacer cosas con ella.
Lo primero que podemos hacer
es usar un archivo encriptado.

Japanese: 
暗号や署名は渡しません
実行するだけです
そしてここに認証コールバックがあります
認証が成功した場合は
キーを使用できます
失敗した場合は
ユーザーにエラーを表示します
ここでのエラーは
回復可能なエラーです
回復不可能なエラーなのに
ポップアップが出る場合もありますので
確認してください
デバイスにBiometricPrompt
などがない場合は
ここでコールバックします
キーを取得したら
それを使って様々なことができます
まず
暗号化されたファイルを使用できます

English: 
so we're not going to pass a
crypto or a signature there.
I'm just going to
do this, and we
have this
authentication callback
which you can see up here.
If the authentication
is successful,
of course, then you
can use your key.
If it's not, then you can
prompt the user with the error.
Some of the error--
the errors here
should be recoverable errors.
There's non-recoverable
errors that can also pop up,
so you just want to check
for those to make sure that--
like if the device doesn't have
any sort of biometric prompt,
it will callback here.
And so then once
you have the key,
then we can do stuff with it.
So the first thing that we can
do is use an encrypted file.

Indonesian: 
jadi tidak ada kripto
atau tanda tangan yang dimasukkan.
Saya akan melakukan ini,
dan mendapatkan
callback autentikasi
di atas sini.
Jika autentikasi berhasil,
tentu kunci bisa digunakan.
Jika tidak, error bisa ditampilkan
kepada pengguna.
Beberapa error di sini
adalah error yang bisa diperbaiki.
Ada error yang tak bisa diperbaiki
yang juga bisa muncul,
jadi periksalah untuk memastikan,
jika perangkat
tak punya perintah biometrik,
bahwa akan di-callback ke sini.
Jadi setelah Anda punya kunci,
kita bisa lakukan beberapa hal.
Hal pertama adalah menggunakan
file dienkripsi.

Korean: 
전달하지 않는다는
사실을 아실 겁니다
화면으로 보여드리겠습니다
보시는 것처럼 이런 인증 콜백이
있습니다
인증에 성공하면 당연히
키를 사용할 수 있습니다
그렇지 않으면 사용자에게
오류를 표시할 수 있습니다
그러한 일부 오류는 복구 가능한
오류이어야 합니다
복구 불가능한 오류가
갑자기 나타날 수 있으므로
기기에 생체 인식 프롬프트가
있는지 여부 등을
확인해야 할 수 있는데요
여기에서 콜백됩니다
키가 생긴 후에는
키를 사용해
작업할 수 있습니다
먼저, 암호화된 파일을
사용할 수 있게 됩니다

Portuguese: 
por isso, não passaremos
uma criptografia ou uma assinatura.
Basta fazer isso.
Temos esse callback de autenticação
que você pode ver aqui.
Se a autenticação for aprovada,
você poderá usar a chave.
Caso contrário,
poderá mostrar um erro ao usuário.
Alguns desses erros são recuperáveis.
Há erros não recuperáveis
que também podem aparecer,
verifique esses casos
para confirmar que, se o dispositivo
não tiver recursos biométricos,
ele fará um callback aqui.
Quando tivermos a chave,
poderemos usá-la.
A primeira ação que podemos executar
é usar um arquivo criptografado.

Chinese: 
它有一个与文件输入流和输出流类似的 API
但是它可以在你操作的时候进行无缝加密和解密
我们来看看
我们来创建一个文件
然后我们表示 我们想把它变成加密文件
那么 我们就可以写 给这个文件提供一个上下文
如果我们想要的话 可以传入一个假名 然后构建这个
拿回加密文件之后
如果我们想写入它 就可以使用 openFileOutput
如果我们想读取它 就可以使用 openFileInput
它的运作方式完全符合你的期待

Japanese: 
これを使用すると
通常の暗号化を
使用できるようになります
これはファイル入力ストリームや
ファイル出力ストリームに
類似したAPIを備えていますが
進行中にシームレスに暗号化
および復号できます
では これを見てください
ファイルを作成し
暗号化されたファイルにしたい場合は
ファイルにコンテキストを追加できます
必要に応じてエイリアスを渡し
作成できます
ファイルを暗号化した後
書き込みたい場合は
オープンファイル出力
読み取りたい場合は
ファイル入力を使用できます
これは
通常予想される方法と
全く同じように機能し

Korean: 
키를 사용해
암호화할 수 있고요
정규적인 기능을
사용할 수 있습니다
파일 입력 스트림,
파일 출력 스트림과
비슷한 API가 있는데요
작업 시 원활한 암호화
및 복호화가 가능합니다
화면을 보시겠습니다
파일을 하나 만듭니다
암호화된 파일로 하겠습니다
말하자면 파일에
문맥을 부여합니다
원한다면 앨리어스를
삽입할 수 있습니다
암호화된 파일을 만든 후
그 파일에 작성하고 싶다면
오픈 파일 출력을 사용할 수 있습니다
파일에서 읽어들이고 싶다면
파일 입력을 사용할 수 있습니다
일반적인 개념과 완전히 동일한
방식으로 진행되어
모든 것이 후드 아래에서

English: 
And so this, what it does is
it allows you to encrypt--
it allows you to use a regular--
it has an API similar
to file input stream
and file output stream,
but it seamlessly
encrypts and decrypts
as you're going along.
And so let's see.
So we've got this.
And we just create
a file, and we
say, OK, I want to have
this be an encrypted file.
So we can say--
with the file,
give it a context.
We can pass in an alias if
we would like and build this.
And then once we get
the encrypted file back,
if we want to write to it,
we can use open file output.
If we want to read from
it, we can use file input.
And then this works
exactly the same way

Indonesian: 
Cara ini memungkinkan Anda mengenkripsi,
dengan mudah,
karena memiliki API
serupa dengan file input stream
dan file output stream,
tetapi mengenkripsi
dan mendekripsi
dengan lancar.
Mari kita lihat.
Misalnya di contoh ini.
Kita baru saja membuat file,
dan ingin file dienkripsi.
Jadi misalnya kita bisa
berikan konteks dengan file.
Alias bisa dimasukkan jika diinginkan,
dan mulai membuatnya.
Setelah file dienkripsi
didapatkan kembali,
jika kita ingin menulisnya,
gunakan buka file output.
Jika kita ingin membacanya,
gunakan file input.
Prosesnya berjalan dengan cara yang sama

Spanish: 
Entonces, lo que hace
es permitirles encriptar...
les permite usar un...
tiene una API similar
para secuencia de entrada de archivos
y secuencia de salida de archivos,
pero encripta y desencripta
continuamente mientras avanzan.
Veamos.
Tenemos esto.
Acabamos de crear un archivo
y queremos que sea un archivo encriptado.
Entonces, podemos decir...
con el archivo, le damos contexto.
Si quisiéramos,
podríamos aprobar un alias.
Una vez que obtengamos
el archivo encriptado,
si queremos copiar datos,
podemos usar la salida de archivo abierto.
Si queremos leerlo,
podemos usar una entrada de archivo.
Y funciona como normalmente esperarían
y todo está encriptado y desencriptado

Portuguese: 
Isso permite criptografar…
permite usar…
Ele tem uma API
semelhante a FileInputStream
e FileOutputStream,
mas criptografa
e descriptografa de modo contínuo.
Vamos ver.
Temos este código.
Criamos um arquivo,
informamos
que esse arquivo será criptografado.
Podemos dizer:
com o arquivo,
damos a ele um contexto.
Podemos passar um alias,
se quisermos, e criá-lo.
Depois que recebermos
o arquivo criptografado,
para gravar nele,
podemos usar openFileOutput
e para lê-lo, openFileInput.
Isso funciona da forma
como normalmente esperamos.

Japanese: 
すべて内部で暗号化および復号されます
ファイル以外のJetpackセキュリティの
機能は
共有設定の暗号化です
APIキーなどの
機密データがある場合は
すぐ使用できる共有設定と
共有設定エディタインターフェースで
ほとんどの人が共有設定の仕組みを
理解でき
キーと値を活用できます
興味深い実装の詳細の1つは
見るとわかるように
値が１つしかない場合も
常に暗号化スキームを設定するよう
強制していることです
これは実際ライブラリ全体に遍在しています
その理由はここにデフォルトを入力した後
将来別のアルゴリズムやキーサイズなどを
追加できるからです
それでアップグレードした場合または
問題が発生した場合
またはAE2-256の問題を発見し
パッチが必要で

English: 
that you would normally expect,
and everything is encrypted
and decrypted under the hood.
JON MARKOFF: So the other
feature of Jetpack security
other than files is
encrypting shared preferences.
So if you have sensitive
data, like API keys like
I mentioned
previously, you can use
the out of the box shared
preferences and shared
preferences editor
interfaces which
allows you to
basically understand--
most people-- well,
most developers already
know how shared
preferences works,
and this allows you
to take advantage
of that using keys and values.
So one interesting
implementation detail
that we've used is
you'll notice in the code
here that we actually
force you always
to set the encryption scheme
even though there's only one
value.
And this is actually ubiquitous
through the whole library,
and the reason for that is,
what if we put default in here,
and let's say in the future,
we decide to add another--
add more algorithms,
add more keys sizes,
add more stuff like that.
So if you did that and you
upgraded, or you had an issue.
Or let's say that there
was for some reason,
someone found an
issue with AE2-256
and there needed to
be a patch, and we

Spanish: 
a niveles profundos.
La otra función de seguridad de Jetpack
es encriptar preferencias compartidas.
Si tienen datos sensibles,
como claves API, que ya mencioné,
pueden usar las preferencias
compartidas predefinidas
y las interfaces del editor
de preferencias compartidas,
La mayoría de los desarrolladores
ya saben cómo funcionan
las preferencias compartidas
y les permite aprovecharlas
usando claves y valores.
Un detalle de implementación importante
que usamos es que notarán en el código
que siempre les obligamos
a establecer el esquema de encriptado
aunque solo sea un valor.
De hecho, está presente
en toda la biblioteca,
porque qué sucedería
si lo pusiéramos como predeterminado aquí
y en el futuro quisiéramos agregar otro...
agregar más algoritmos,
más tamaños de clave
o cosas similares.
Si hicieran eso y actualizaran
o tuvieran un problema
o digamos que, por algún motivo,
hubiera un problema con AE2-256
y fuera necesario un parche

Portuguese: 
Tudo é criptografado
e descriptografado nos bastidores.
Outro recurso do Jetpack Security,
é a criptografia
de preferências compartilhadas.
Se você tiver
dados confidenciais, como chaves de API,
poderá usar as interfaces
de preferências compartilhadas
e o editor de preferências compartilhadas,
que ajudam a entender…
A maioria dos desenvolvedores
já sabe como elas funcionam.
Com esse recurso, você se beneficia disso
usando chaves e valores.
Um detalhe de implementação interessante
que usamos: você pode ver no código
que obrigamos você a sempre
definir o esquema de criptografia,
mesmo que haja só um valor.
Isso ocorre na biblioteca inteira.
O motivo disso é o seguinte:
imagine se colocássemos
um valor padrão aqui
e no futuro decidíssemos
adicionar mais algoritmos,
tamanhos de chaves,
coisas desse tipo.
Se fizéssemos isso,
e você atualizasse ou tivesse um problema
ou, por algum motivo,
alguém encontrasse
um problema com o AES-256
que exigisse uma correção

Korean: 
암호화되고 복호화됩니다
파일 이외에
Jetpack 보안의 다른 기능으로
공유된 환경설정의
암호화가 있습니다
앞에서 말씀드린 것처럼
API 키와 같이
민감한 데이터가 있다면
바로 사용 가능한 공유된 환경설정과
공유된 환경설정
편집기 인터페이스를
사용할 수 있습니다
대부분의 개발자가
공유된 환경설정의
역할을 이미 잘 알고 있으며
이를 통해 제반 키와 값을
활용할 수 있습니다
우리가 사용한 구현 방식의
흥미로운 점은
화면에 나오고 있는 코드에서는
1개의 값만 있더라도
항상 암호화 스키마를
설정해야 한다는 것입니다
전체 라이브러리에 걸쳐 그렇습니다
왜냐하면 여기에서 기본값을 설정하고
나중에 알고리즘을 추가하고
키 길이 등을 추가할 수
있습니다
그 후 업그레이드하지 않으면
문제가 생길 겁니다
아니면 어떤 이유로
AE2-256에
문제가 확인되어
패치가 필요하고
다른 알고리즘을
사용해야 하는

Chinese: 
而且所有东西都是在后台实现加密和解密的
除了文件 Jetpack Security 的另一个功能
就是加密共享偏好设置
如果你有敏感数据 比如我之前提过的 API 密钥
那么你就可以使用我们默认提供的
共享偏好设置 以及 共享偏好设置编辑器接口
它们可以让你理解...
当然大多数开发者已经理解共享偏好设置的运作模式了
这样就可以使用键和值
我们使用过的一个有趣的实现细节是
大家可以在这里的代码中看到
我们其实是在强制大家每次都设置加密方案
即使只有一个数值的时候也是如此
其实这种现象是在整个代码库内普遍存在的
原因是 如果我们在这里使用默认值会怎样
假如 今后有一天 我们决定添加更多的算法 更大的密钥文件 等等
如果你升级了 或者你出了问题
或者有人找到了 AES-256 的问题 必须打补丁
而我们必须使用另一种算法

Indonesian: 
seperti biasanya,
dan semua dienkripsi
dan didekripsi dalam proses itu.
-Fitur lain Jetpack selain file
adalah enkripsi pilihan dibagikan.
Jika ada data sensitif,
seperti kunci API
Anda bisa gunakan
antarmuka preferensi bersama
dan editor preferensi bersama
yang telah disertakan
dan telah dipahami oleh
kebanyakan developer,
sehingga Anda bisa memanfaatkannya
menggunakan kunci dan nilai.
Detail implementasi menarik
yang kita gunakan adalah, bisa dilihat
dalam kode ini,
kami mengharuskan Anda agar selalu
menentukan skema enkripsi
walau hanya ada satu nilai.
Ini ada di seluruh library,
alasannya adalah, jika kita
pasang default di sini,
dan anggaplah kemudian
kami tambahkan lagi
misalnya algoritme, ukuran kunci,
atau semacamnya.
Jika Anda gunakan default
dan meng-upgrade atau ada masalah,
Atau anggaplah ternyata
ada masalah dengan AES-256
dan harus ada patch, dan perlu

Chinese: 
那么 作为一名开发者 如果它是默认的
那么你就不会知道你用的是什么
因为默认值会随时间推移而改变 会出现很多意外
所以 尽管现在只有一个数值
它还是只会出现在这样的一个 API 里
这是我们出于安全考虑 刻意安排的
我之前被问到过这个问题 所以我才这么说
这种做法是我们刻意的 而且它有它的道理 我向大家保证
在本例中 与共享偏好设置类似
你创建一个 EncryptedSharedPreferences 对象
传入一个密钥假名
你在从应用中获取或创建任何 Android Keystore 密钥上下文的时候
就可以在 MaterKey 类中找到它
你要使用的算法 以及文件名 my_secret_prefs
运作模式是相当接近的 不用学习新东西
一切困难的事情都由它来代劳
另外值得一提的就是 键和值是采用不同手段加密的
这里你可能会注意到 它在使用的是静态初始向量（IV）
也就是说 每当你对密钥进行加密的时候

English: 
needed to use a different
algorithm, as a developer
you wouldn't really
know what you
were using if it was default
because defaults change
over time, things could happen.
So that's why even
though there's
only one value right
now, it's explicitly
in the API like this.
And that's intentional
for safety.
So I've have gotten
this question before,
that's why I'm saying that.
Just so-- it is intentional,
it does make sense.
I promise.
So in this case, similar
to shared preferences,
you create an encrypted
shared preferences object.
You pass in a key alias-- this
is where you would find it
from the master keys class
when you either get or create
any Android keystore key
context from application.
And the algorithms
are going to use--
and obviously my secret
preference is the file name.
So it works very similarly.
You don't have to
learn anything new,
and it does all the
heavy lifting for you.
One other thing
to mention as well
is the keys and values
are encrypted differently.
So you'll notice here that
it's using a static IV
or an initialization vector,
which basically means
that every time
you encrypt a key,

Indonesian: 
menggunakan algoritme berbeda,
developer mungkin tidak tahu
apa yang digunakan di default,
karena default berubah
seiring waktu, banyak hal bisa terjadi.
Itulah alasan walaupun hanya
ada satu nilai sekarang,
secara eksplisit
di API seperti ini.
Dan itu sengaja untuk keamanan.
Saya pernah dapat pertanyaan ini,
dan itulah jawabannya.
Ini sengaja dan masuk akal.
Percayalah.
Dalam hal ini, serupa dengan
preferensi bersama,
Anda membuat objek preferensi
bersama yang dienkripsi.
Lalu masukkan alias kunci dan di sinilah
Anda bisa menemukannya
dari class kunci utama saat Anda
mendapatkan atau membuat
konteks kunci keystore Android
dari aplikasi.
Dan algoritme akan menggunakan--
jelas preferensi rahasia saya adalah
nama file.
Cara kerjanya mirip.
Anda tak perlu belajar hal baru,
semua hal sulit dilakukan untuk Anda.
Satu hal lagi,
kunci dan nilai
dienkripsi dengan cara berbeda.
Dalam contoh ini, digunakan IV statis
atau initialization vector,
yang artinya
setiap kali Anda mengenkripsi kunci,

Japanese: 
別のアルゴリズムを使用する場合
開発者はデフォルトで
何を使っているかわかりません
常に変化するからです
なので値が１つしかない場合でも
APIに明示的に含まれています
これは安全のためです
以前質問があったのでお話ししました
これは意図的で 理にかなっています
この場合共有設定と同様に
暗号化された共有設定オブジェクトを作成します
アプリケーションからAndroidキーストア
キーコンテキストを取得 作成する際
マスターキークラスから見つけた
キーエイリアスで渡します
そしてアルゴリズムが使用して
同じように機能します
新しいことを学ぶ必要はありません
もう１つ重要なのは
キーと値は異なる方法で暗号化されることです
静的IPまたは
初期化ベクトルが使用されています
つまりキーを暗号化するたびに

Portuguese: 
e nós precisássemos
usar um algoritmo diferente,
você, o desenvolvedor,
não saberia o que está usando,
se estivesse com o padrão,
porque os padrões mudam com o tempo.
É por isso que,
embora haja só um valor no momento,
ele está explicitamente
na API dessa forma.
Isso é intencional, por segurança.
Já ouvi essa dúvida,
por isso estou dizendo isso.
Isso é intencional, tem um sentido.
Eu juro.
Neste caso, assim como
nas preferências compartilhadas,
criamos um objeto
EncryptedSharedPreferences.
Passamos um alias de chave,
que pode ser encontrado
na classe MasterKeys ao receber ou criar
um contexto de chave
do Android keystore para o app.
E o algoritmo usará…
Minha preferência secreta
é o nome do arquivo.
Funciona de modo semelhante.
Você não precisa aprender nada,
ele faz o trabalho pesado para você.
É importante mencionar
que as chaves e os valores
são criptografados de modo diferente.
Observe que usamos
IV estático, ou vetor de inicialização,
isso significa que,
sempre que uma chave for criptografada,

Spanish: 
y tuviéramos que usar
un algoritmo diferente,
como desarrolladores
no sabrían qué usan
si fuera predeterminado,
ya que eso cambia con el tiempo.
Y las cosas pasan.
Es por eso que, aunque solo hay
un valor en este momento,
está explícitamente en la API así.
Y eso es intencional por seguridad.
Me han preguntado esto antes,
por eso lo digo.
Es intencional, tiene un propósito.
Lo prometo.
Entonces, en este caso,
parecido a las preferencias compartidas,
crean un objeto de preferencias
compartidas encriptadas.
Aprueban un alias de clave;
lo encontrarán
en la clase de claves maestras
cuando obtengan o creen
un contexto del almacén de claves
de Android desde la aplicación.
Y los algoritmos van a usar...
mi preferencia secreta
es el nombre del archivo.
Funciona muy parecido.
No tienen que aprender nada;
hace el trabajo pesado por ustedes.
Otra cosa que debo mencionar
es que las claves y los valores
se encriptan de forma diferente.
Notarán que aquí se usa
un vector de inicialización (IV) estático
que básicamente significa
que cuando encripten una clave,

Korean: 
경우를 가정할 수 있습니다
기본값은
시간이 흐르면 변하고
항상 무슨 일이 생기므로
개발자가 기본값을 사용하면
그 값을 알 수 없을 것입니다
따라서 당장에 1개의 값만 있더라도
분명히 이와 같은 API에 있는 것입니다
보안상 이유 때문입니다
아까 제기한 질문에 대해 말씀드리는
이유이기도 합니다
타당한 이유가 있는데요
공유된 환경설정과
유사한 이 경우에는
암호화 및 공유된
환경설정 객체를 생성합니다
여러분은 키 앨리어스를 삽입하고
애플리케이션으로부터
Android 키 저장소의 키 문맥을 가져오거나
만들 때 마스터 키
클래스에서 찾는 곳이 여기입니다
그리고 알고리즘은
비밀 환경설정을
사용하게 됩니다
매우 유사한 방식으로 진행되는데
새로운 것을 배우실 필요가 없으며
모든 부담스러운 작업을
대신해 드립니다
말씀드릴 또 한 가지는
키와 값이 서로 다른 방식으로
암호화된다는 것입니다
보시다시피 정적 IV 또는 초기화 벡터가
사용되는데요
키를 암호화할 때마다

English: 
it's going to be
encrypted the same way,
and this allows
us to do lookups.
So the values will-- using
the same file encryption
as-- and same
encryption as the file.
But for keys, you always
want have this lookup,
and that allows us to also
encrypt the keys safely.
So why would we encrypt keys?
I think it's like email
address key and then the value
of some email address.
Well, some developers,
we've found,
also put sensitive
information as the key,
so you might not
necessarily want to do that.
So that's why we make sure
we encrypt the whole thing,
and that's why it's
safe to use pretty
much for any information.
So advanced encryption.
So we know-- we talked about
generating keys, authorizing
keys.
There's one thing I wanted
to bring up as well.
Jetpack security uses a
Google open source library
called "Tink."
Tink has cross-platform
security for a lot
of different platforms, a lot
of different mobile platforms,
and it's something we
use because it provides
a way and a method of
ensuring that-- there's
a lot of different
versions of Android,

Chinese: 
加密方法都会是一样的
这样我们才能查找
数值使用和文件相同的加密手段
但是对于密钥来说 查找功能是必需的
这样才能安全地对密钥进行加密
那么 我们为什么要对密钥进行加密呢？
就像是 电子邮件密钥 电子邮件地址数值
有些开发者会把敏感信息做成密钥
这样做可不太好
所以我们才会把密钥整个加密
这样一来 使用什么信息都没关系了
下面来谈谈高级加密
我们已经讲过了 密钥生成 密钥验证
下面我还想讲一个东西 那就是
Jetpack Security 使用的是 Google 开源代码库 Tink
Tink 为各种平台 包括移动平台 提供了跨平台安全功能
我们自己也使用它 因为它可以确保安全

Japanese: 
同じ方法で暗号化され
lookupが可能になります
値はファイルと同じ
暗号化を使用します
でもキーには常に
このlookupが必要です
キーを暗号化する理由は
メールアドレスキーと
アドレスの値と
同じです
一部の開発者は
機密情報をキーとして使用しているため
これは必要ないかもしれませんが
だからどんな情報に対しても
安全であることを確認したのです
高度な暗号化です
キーの生成 キーの承認について
話しました
もう１点
Jetpackセキュリティは
Tinkというオープンソースライブラリを
使用します
Tinkには様々なプラットフォームや
モバイルプラットフォーム向けの
クロスプラットフォームセキュリティがあり
Androidの様々なバージョンや

Korean: 
동일한 방식으로 암호화되며
이를 통해 조회할 수 있습니다
따라서 값은
동일한 파일 암호화
즉, 파일과 동일한 암호화를
사용합니다
그러나 키의 경우 이를 항상
조회할 수 있길 원하실텐데
그럼으로써 키를
안전하게 암호화할 수도 있습니다
그럼 왜 키를 암호화할까요?
저는 이메일 주소 키나
어떤 이메일 주소의 값과
같다고 생각합니다
어떤 개발자들은 민감한 정보도
키로 입력한다는 사실을
알게 되었는데요
여러분은 꼭 그렇게
하고 싶지 않으실 수 있습니다
그래서 모든 것을
암호화해야 하는 것이며
어떤 정보에도
암호화를 적극적으로
사용하는 것이 안전합니다
이제 고급 암호화입니다
키 생성, 키 인증에 대해
말씀드렸는데요
한 가지 더 설명드리고 싶은 것은
Jetpack 보안은 'Tink'라는
Google 오픈소스 라이브러리를
사용한다는 점입니다
Tink는 다양한 플랫폼,
많은 다양한 모바일 플랫폼을 위한
크로스 플랫폼 보안이며
수많은 다양한 Android 버전과
OEM을 보장하는 방식 및 방법을
제공하기 때문에 사용됩니다

Indonesian: 
kunci akan dienkripsi
dengan cara sama,
dan kita bisa melakukan pencarian.
Nilainya adalah ini,
menggunakan enkripsi file
dan enkripsi yang sama dengan file.
Untuk kunci, Anda selalu butuh pencarian,
agar kunci bisa dienkripsi
dengan aman.
Mengapa mengenkripsi kunci?
Saya rasa itu seperti kunci alamat email
kemudian nilai
beberapa email.
Kami lihat beberapa developer
memasukkan informasi sensitif
sebagai kunci,
meski sebaiknya itu tidak dilakukan.
Itulah alasannya
kita harus mengenkripsi semua,
dan ini aman digunakan
untuk informasi apa pun.
Sekarang lanjut ke enkripsi lanjutan.
Kita sudah bahas
pembuatan kunci dan otorisasi kunci.
Satu hal lagi yang ingin saya bahas.
Keamanan Jetpack menggunakan
library open source Google
bernama "Tink".
Tink punya keamanan lintas platform untuk
berbagai platform,
berbagai platform seluler,
dan kami menggunakannya
karena Tink memberikan
cara dan metode untuk memastikan bahwa,
karena ada banyak versi Android,

Spanish: 
se va a hacer de la misma manera,
lo que permitirá hacer búsquedas.
Los valores usarán
la misma encriptación de archivos
y la misma encriptación que el archivo.
Para las claves, querrán esta búsqueda,
que nos permite
encriptar claves con seguridad.
Entonces, ¿porqué deberíamos
encriptar las claves?
Creo que es como la clave
de un email y el valor
de algunos emails.
Descubrimos que algunos desarrolladores
usan información sensible para la clave.
No les sugerimos que hagan eso.
Por eso nos aseguramos
de encriptar todo
y por eso es seguro usarlo
casi para cualquier información.
Encriptación avanzada.
Sabemos... hablamos sobre
la generación y autorización de claves.
Hay otra cosa que quiero agregar.
Jetpack usa una biblioteca
de código abierto de Google, “Tink”.
Tink cuenta con seguridad multiplataforma
para varias plataformas diferentes,
plataformas móviles diferentes,
y es algo que usamos porque brinda
una forma de garantizar que…
Hay varias versiones de Android

Portuguese: 
a criptografia será feita da mesma forma.
Assim, podemos fazer buscas.
Os valores usarão
a mesma criptografia que o arquivo.
Para chaves, é bom fazer essa busca,
isso permite criptografar
as chaves com segurança.
Por que criptografar chaves?
É como a chave de um endereço de e-mail
e o valor do endereço.
Alguns desenvolvedores
também usam
informações confidenciais como chave.
Você não vai querer fazer isso.
Por isso, criptografamos tudo
e esse processo é seguro
para qualquer informação.
Criptografia avançada.
Falamos sobre a geração
e autorização de chaves.
Quero falar sobre mais uma coisa.
O Jetpack Security usa
uma biblioteca de código aberto do Google
chamada Tink.
Ela tem recursos de segurança
para várias plataformas,
muitas plataformas
para dispositivos móveis.
Nós a usamos porque ela fornece
um método para…
Há muitas versões do Android,

Korean: 
다양한 SSL 버전이
구현되어 있는데요
보호된 암호를
구현한 것입니다
모든 것을 갖추었고
많은 뉘앙스와 변경 사항을 풀고
API 스트리밍 같은 작업
암호화 스트리밍과
인증된 암호화 작업도
실행합니다
하나의 개념인데요
OpenJDK에서 제작한
Java 보안 확장자에서
사용 가능하지만
용어 때문에
누구나 이해하거나
사용 방법을 아는 것은
아닙니다
Tink는 수많은 기능을 제공하며
저희가 사용하기 때문에
말씀드린 것처럼
Android 확장자를 지원합니다
'대기열 순환'이라는 것도
말씀드리겠습니다
우리에게 마스터 키가 있지만
왜 마스터 키인지는
설명드리지 않았습니다
그 이유는 각 파일 또는
공유 환경설정 객체 또는
Tink의 원시 알고리즘 키 길이
때문입니다
저희는 모든 것에
대한 키 집합을 만듭니다

Indonesian: 
ada banyak OEM di luar sana,
ada berbagai versi SSL
yang diterapkan, yang sebenarnya
penerapan kripto.
Itu membantu karena
ada tim di belakangnya
yang bisa selesaikan perbedaan,
banyak perubahan,
serta menerapkan berbagai hal
seperti API streaming,
enkripsi streaming
dan enkripsi diautentikasi,
dan karena...
ini tersedia di ekstensi keamanan Java
yang dibangun di OpenJDK,
tetapi bukan sesuatu
yang dipahami atau diketahui
cara penggunaannya
karena istilah yang digunakan.
Tink memberi lebih banyak fitur,
dan memiliki ekstensi Android
seperti yang kami sebutkan,
karena kami menggunakannya.
Satu hal
yang perlu diperhatikan adalah
"rotasi kunci".
Walau kita punya kunci utama,
tak dijelaskan
kenapa ini adalah kunci utama,
alasannya karena setiap file
atau objek preferensi bersama,
atau setiap jenis primitif,
yang bisa jadi
algoritme atau semacamnya,
ukuran kunci algoritme
dalam Tink,
dan kami membuat set kunci untuk semuanya.

English: 
there's a lot of
different OEMs out there.
There's different versions
of [INAUDIBLE] SSL
that are implemented-- are
actually implementations
of crypto under the covers.
And that's helpful
for us because they've
a whole team behind
it, and they've
been able to solve a
lot of the nuances,
and a lot of the changes,
and also implement things
like streaming APIs--
streaming encryption as well
as authenticated encryption,
which is a concept
that's not necessarily--
it's available in the Java
security extensions that
are built in the OpenJDK,
but not necessarily something
that anyone really understands
or knows how to use because
of the terminology.
So Tink does provide
a lot more features,
and it does have an
Android extension
as we mentioned as well,
because we actually use it.
One thing to mention
is that something
called "queue rotation."
So even though that
we have a master key--
and we never explained
why it was a master key--
the reason is because each file
or shared preferences object,
or each type of a primitive--
which a primitive could
be an algorithm or something
like that-- algorithm key size
in Tink.
And we create key
sets of everything.

Spanish: 
y muchos OEM diferentes.
Hay distintas secuencias
de comandos que se usan.
Son implementaciones de criptografía.
Es útil para nosotros porque
tienen un equipo completo
que solucionó muchos problemas,
muchos de los cambios,
e implementaron cosas
como la transmisión de API,
la encriptación de transmisión 
y el encriptación autenticada,
que es un concepto que no…
Está disponible
en las extensiones de seguridad Java
creadas en OpenJDK, pero
no necesariamente algo
que cualquiera pueda comprender
o sepa cómo usar
debido a la terminología.
Tink brinda muchas funciones
y tiene una extensión de Android
como lo mencionamos, porque la usamos.
Algo que debo mencionar
es la “rotación en cola”.
Aunque tengamos una clave maestra
y nunca explicamos porqué lo es,
el motivo es que cada archivo
u objeto de preferencias compartidas
o cada tipo de una nube primitiva
sea un algoritmo o algo similar...
un algoritmo del tamaño de clave en Tink.
Creamos conjuntos de claves para todo.

Japanese: 
OEMに対応するために使用しており
様々なSSLバージョンが実装されています
これは便利でした なぜなら
チームがいて
多くのニュアンスや変更を解決でき
ストリーミングAPIや
ストリーミング暗号化
認証暗号化も実装できました
不可欠な概念ではありませんが
OpenJDKに組み込まれている
Javaセキュリティ拡張機能で
利用できますが
専門的なので理解する必要はありません
Tinkは多くの機能を提供し
Android拡張機能も備えており
私たちも実際に使用しています
もう１つ重要なのは
キューローテーションです
マスターキーがありますが
その理由は説明しませんでした
理由は 各ファイルまたは共有設定オブジェクト
または各プリミティブはTinkの
アルゴリズムキーサイズになります
そして

Portuguese: 
e vários OEMs.
Há diferentes versões de [INAUDÍVEL] SSL
que são implementações
de criptografia disfarçadas.
Isso é muito útil para nós
porque eles têm uma equipe toda
para resolver as nuances
e alterações e para implementar recursos
como criptografia
de streaming e autenticada,
que é um conceito que não necessariamente…
Está disponível
nas extensões de segurança do Java
no OpenJDK, mas é algo que nem todos
entendem ou sabem usar
por causa da terminologia.
O Tink fornece muitos outros recursos
e tem uma extensão para Android,
como dissemos,
porque nós a usamos.
É importante mencionar
a chamada "rotação de chaves".
Apesar de termos uma chave mestra,
não explicamos o porquê disso.
O motivo é que cada arquivo,
objeto de preferências compartilhadas
ou tipo de primitivo, que pode ser
um algoritmo ou algo assim…
tamanho de chave de algoritmo,
no Tink…
Criamos conjuntos de chaves de tudo isso.

Chinese: 
Android 有很多版本 有很多 OEM 商 很多 SSL
还有很多后台加密实现 这些对我们都很有帮助
因为它们的背后有一整支团队 可以解决大量细节问题和改动
同时实现一些诸如数据流 API 之类的东西
数据流加密 验证加密
它们都在 OpenJDK 内建的 Java 安全扩展中
但是出于术语方面的原因
并不是所有人都能搞懂它 也不是所有人都会用
Tink 提供了很多功能
其中包括我们之前提到过的 Android 扩展
我们自己就在使用它
值得一提的是 密钥轮换
虽然我们有主密钥 但我们从没解释过为什么它是主密钥
原因是 每个文件 或每个 SharedPreferences 对象
或每种基元类型
基元可以是算法密钥对之类的东西 放置在 Tink 里
我们会为所有东西创建密钥对

Chinese: 
Tink 可以直接为我们解决这个问题
所以 我们创建一个 AES-256 密钥 并用它来加密文件
它会自动在后台创建共享参数偏好对象密钥对
这样一来 我们每次使用 Tink 的时候
如果我们是在后台使用它 并且需要更改或轮换密钥
那么现在假如你把密钥保存在 SharedPreferences 中
而密钥遭到了某种攻击 你需要换掉它
这时你就可以轮换它
也就是说 在密钥串上专为这个基元或文件添加一个新密钥
这样你就可以迁移所有保存在新密钥串中的文件或数据了
这就是我们所谓的 密钥轮换
Tink 还支持讯息签名 MAC 混合加密等功能
如果你不知道混合加密是什么意思的话 我来讲解一下
它同时使用对称加密和不对称加密技术
比如一个 RSA 密钥和一个 AES 密钥
用来加密较大的文件集
同时也可以通过分享公钥的方式来和他人分享数据

Korean: 
Tink는 이러한 과제를
기본적으로 처리합니다
따라서 AES-256 키를 만들어
파일을 암호화하는데요
보호된 공유된 환경설정 키 집합을
자동 생성합니다
이를 통해 어떤 이유로든
Tink를 사용할 때마다
보호된 상태로
Tink를 사용할 수 있는데요
이때 키를 변경하거나
순환해야 합니다
어떠한 이유 때문에
공유 환경설정에
저장된 키를 변경해야 합니다
그런 키는 어떤 식으로든
손상되기 때문에
순환해야 합니다
즉, 특정 파일을 위한 키 집합에
새로운 키를 추가하고
저장된 모든 파일 또는
데이터를 새로운 키 집합으로
마이그레이션할 수 있습니다
이것이 소위
'대기열 순환'이라는 것입니다
Tink는 메시지 서명,
MAC, 하이브리드 암호화와
같은 기능도 지원합니다
하이브리드 암호화가 생소하시다면
대용량 데이터 집합을
암호화하는 AES 키를 갖춘
RSA 키와 같이 공개 암호화와
비대칭 및 대칭 암호화를
함께 사용하는 것이라고
생각하시면 됩니다
또한 다른 당사자와 공개 키를
공유하여 대용량 데이터 집합을
공유할 수도 있습니다

Japanese: 
全ての物のキーセットを作ります
Tinkはこれをすぐに処理し
ファイルにAES-256キーを作ると
Tinkは内部で自動的に
共有設定キーセットを作成します
これにより
Tinkを内部で使用するたびに
キーの変更やローテーションをしたい場合
例えばキーが共有設定に保存されていて
侵害され
変更する必要がある場合
特定のプリミティブや
ファイルのキーセットに
新しいキーを加えて
ローテーションでき
新しいキーセットに保存された
ファイルやデータを
移行できます
これがキューローテーションです
Tinkは
メッセージ署名 MACなども
サポートしています
ハイブリッド暗号化とは
AESキーを備えたRSAキーなど
公開と非対称暗号化の両方を使用して
大きなデータセットを暗号化し
公開キーを共有して
他のパーティーと
それを共有することもできます

Indonesian: 
Tink menangani ini langsung untuk kami.
Jadi misalnya membuat kunci AES-256
untuk mengenkripsi file,
Tink secara otomatis
membuat set kunci preferensi bersama
dalam prosesnya.
Dengan begitu,
setiap kali menggunakan Tink
tanpa menangani detail,
dan kunci perlu diubah atau dirotasi,
misalnya kunci yang disimpan
di preferensi bersama perlu diubah,
atau kunci telah disusupi,
Anda bisa merotasinya dengan
menambah kunci baru ke set kunci
untuk primitif atau file spesifik itu
dan Anda bisa memindahkan file atau data
yang telah disimpan ke set kunci baru.
Itulah yang disebut "rotasi kunci".
Tink juga mendukung fitur seperti
penandatanganan pesan,
MAC, dan enkripsi hibrida.
Jika belum tahu, enkripsi hibrida
menggunakan enkripsi publik serta
enkripsi
asimetris dan simetris,
seperti kunci RSA dengan AES untuk
mengenkripsi set data lebih besar,
serta agar bisa membagikan
dengan berbagi kunci publik
kepada pihak lain.

Portuguese: 
O Tink gerencia esse processo.
Quando criamos uma chave
AES-256 para criptografar um arquivo,
ele cria um conjunto de chaves
de preferências compartilhadas
automaticamente.
Dessa forma, cada vez
que o Tink é utilizado,
se você o usar internamente
e quiser alterar ou rotacionar uma chave…
Digamos que as chaves estejam salvas
nas preferências compartilhadas,
e você queira alterá-las,
porque elas foram comprometidas.
Você pode rotacioná-las.
Ele adicionará uma nova chave
ao conjunto de chaves
para o primitivo ou arquivo específico.
Assim, você pode migrar
todos os arquivos ou dados salvos
em um novo conjunto de chaves.
Isso se chama "rotação de chaves".
O Tink também oferece recursos
como assinatura de mensagens,
MACs, criptografia híbrida.
Caso não saiba
o que é criptografia híbrida,
é o uso de criptografia
assimétrica e simétrica,
como uma chave RSA
com outra AES para criptografar
conjuntos grandes de dados
e poder compartilhá-los
enviando uma chave pública para terceiros.

English: 
So Tink handles this
out of the box for us.
So [INAUDIBLE] create an
AES-256 key to encrypt a file,
it will automatically create
a shared preferences key set
under the covers.
And what this allows
us to do is every time
you use Tink for some
reason, if you're
using it under
the covers and you
need to change or rotate a key.
Let's say for some
reason, the keys that
are saved in shared preferences,
you need to change them,
they've been
compromised in some way,
you can rotate them which
means it'll actually
add a new key to
the key set that's
for that specific primitive
or that specific file,
and allow you to migrate
all the files or data that's
been saved into a new key set.
So that's something
called "queue rotation."
Tink also supports features
like message signing,
MACs, hybrid encryption.
If you don't know what
hybrid encryption is,
it's using both public and--
asymmetric and
symmetric encryption,
like an RSA key with an AES key
to encrypt larger sets of data,
but also be able to share
that by sharing a public key
with another party.

Spanish: 
Entonces, Tink hace esto por nosotros.
Si creamos una clave AES-256
para encriptar un archivo,
creará un conjunto de claves
de preferencias compartidas
a nivel más profundo.
Lo que nos permite hacer
es que cada vez que usen Tink,
en un nivel profundo,
y deben cambiar una clave...
Digamos que las claves se guardaron
en las preferencias compartidas
y deben cambiarlas
o fueron comprometidas,
pueden rotarlas, lo que significa que
agregará una nueva clave
al conjunto de claves
para ese primitivo o archivo específico
y les permitirá migrar
los archivos o datos
guardados en un nuevo conjunto de claves.
Eso es “rotación en cola”.
Tink también admite funciones
como firma de mensajes,
MAC y encriptación híbrida.
La encriptación híbrida usa
encriptación asimétrica y simétrica,
como una clave RSA y AES para encriptar
conjuntos de datos más grandes,
pero también para poder compartir
mediante una clave pública
con otra persona.

Indonesian: 
Ke depannya,
dan saya menerima
banyak pertanyaan tentang ini
di Twitter dan di sini juga,
Jadi saya hargai ketertarikannya,
sejauh ini sangat bagus.
Di 1.0 fitur ini akan tersedia.
Saya berjanji.
Kami bekerja dengan tim Tink
untuk menambahkan
dukungan KitKat plus.
Saat ini, Tink
sedang mengerjakan ini,
tapi tak mendukung
pasangan kunci RSA.
Untuk mendukung KitKat dan Lollipop,
keystore yang didukung hardware di Android
tak mendukung kunci simetris atau AES
hingga Marshmallow,
itu alasannya mengapa butuh
waktu lebih banyak.
Saya minta maaf dan
menghargai kesabaran Anda.
Kami sedang usahakan.
Kami juga merencanakan
fitur seperti rotasi kunci,
seperti yang kami sebutkan,
dan menambah dukungan penandatanganan.
Dan tentu saja selain itu
saya menghargai bug dan permintaan fitur
yang masuk,
dan kami akan terus upayakan.
Ini hal yang sedang kami kerjakan,
dan akan tersedia, jangan khawatir.
Kami menanti beta
dan semoga rilis tahun ini.

Portuguese: 
Sobre o futuro, recebi muitas perguntas
sobre isso no Twitter
e aqui até agora.
Eu agradeço o interesse.
Tem sido excelente.
Estamos a caminho do 1.0.
Está chegando, eu juro.
Estamos trabalhando com a equipe do Tink
para dar suporte
ao KitKat e versões acima.
O Tink está trabalhando nisso,
mas não tem suporte a pares de chave RSA.
Além disso, para compatibilidade
com KitKat e Lollipop,
o keystore baseado em hardware no Android
não é compatível com chaves AES
simétricas até o Marshmallow.
Por isso, está demorando um pouco.
Desculpe.
Agradeço a paciência de todos.
Estamos trabalhando nisso.
Também estamos analisando
recursos como a rotação de chaves
e a inclusão de suporte a assinaturas.
Claro, além de…
Eu agradeço os relatórios de bugs
e as solicitações de recursos,
continuaremos trabalhando nisso.
Estamos trabalhando nisso.
Está chegando, não se preocupem.
Pretendemos fazer um Beta e o lançamento
possivelmente ainda este ano.

Spanish: 
Entonces, espero... sé que tengo
muchas preguntas en Twitter
y muchas aquí también.
Aprecio su interés.
Ha sido genial hasta ahora.
Pronto estará disponible la versión 1.0.
Lo prometo.
Estamos trabajando con Tink
para agregar KitKat y la asistencia.
Actualmente, Tink trabaja en ello,
pero no admite pares de clave RSA.
Y para admitir KitKat y Lollipop,
el almacén de claves
respaldado por hardware en Android
no admite claves simétricas
o AES hasta Marshmallow,
y esa es la razón de porqué
llevó más tiempo.
Me disculpo. Agradezco su paciencia.
Estamos trabajando en ello.
Estamos viendo la rotación de claves,
y la incorporación de soporte para firmas.
Y, obviamente, más allá...
y agradezco que nos informen de errores
y nos pidan funciones.
Seguiremos trabajando en ello.
Definitivamente, estamos
trabajando en ello.
No se preocupen, llegará pronto.
Estamos estudiando una versión beta
y esperamos que se lance este año.

Korean: 
미리 말씀드리자면
트위터를 통해 이 문제에 대한
많은 질문을 받아 왔는데요
그런 많은 관심에 감사드리고
매우 좋은 질문들이었습니다
이제 1.0이 곧 출시됩니다
현재 KitKat 플러스
지원을 추가하기 위해
지금 Tink팀과 작업 중입니다
현재 Tink팀이 이 과제를 수행 중인데요
RSA 키 쌍을 지원하지는 않습니다
KitKat 및 Lollipop 지원과 관련하여
Android의
하드웨어 지원 키 저장소는
Marshmallow 이전에
대칭 또는 AES 키를
지원하지 않습니다
따라서 시간이 좀 걸리고 있습니다
죄송한 마음과 더불어
인내심에 대해 감사드리며
열심히 작업 중입니다
말씀드렸듯 키 순환 등의
기능에도 주목하고 있으며
서명 지원 기능도 추가하고 있습니다
이와 관련하여 버그 신고와
기능 요청을 해 주신다면
감사한 마음으로
접수해 해결하겠습니다
이런 것들을 현재 작업 중이며
곧 선보일 예정이니 걱정 마십시오
베타 버전을 선보인 후
올해 안으로 출시할 예정입니다

Japanese: 
これについてはTwitterでも
ここでも 多くの質問をいただいています
関心をお寄せいただきありがとうございます
次は1.0が
まもなくリリースされます
KitKatプラスサポートを追加しています
TinkはRSAキーペアに対応していません
KitKatとLollipopに対応するには
キーストアがMarshmallowまで
対称キーまたはAESキーをサポートしていないため
時間がかかっています
すみませんがお待ちください
キーローテーションや
署名サポートなどの機能にも
対応中です
バグの報告や機能のリクエストは大歓迎です
もうすぐリリースするので
心配しないでください
今年中にベータ版をリリースしたいです
[音楽]

Chinese: 
讲讲今后的事情 我在推特上被人问到很多次
很感谢大家对这个问题的关注 目前一切进展顺利
请期待即将推出的 1.0 版本 我向大家保证
我们还在与 Tink 团队协作
添加对 KitKat+ 版本设备的支持
虽然我们正在努力解决 但 Tink 目前还并不支持 RSA 密钥对
至于对 KitKat 和 Lolipop 版本的支持
由硬件支撑的 Android Keystore 目前还不支持
在 Marshmallow 之前的版本中采用的对称式加密和 AES 密钥
这正是耗费开发时间的主要因素
在这里向大家道歉 感谢大家的耐心等待 我们正在努力解决
如我所说 我们也在关注 密钥轮换 这样的功能
并且正在添加签名支持 等等
感谢大家提交的 bug 和功能请求
我们会不断努力的
开发过程正在进行 别担心 很快就会推出
希望我们可以在今年推出 beta 版本

English: 
So looking forward--
I know that I've
gotten a lot of questions
about this on Twitter
and a lot of
questions here so far.
So I appreciate the
interest in it--
it's been really great so far.
So looking to 1.0, it's coming.
I promise.
We're actually working
with the Tink team
right now to add
KitKat plus support.
Currently, Tink--
they're working on this,
but it doesn't
support RSA key pairs.
And to support
KitKat and Lollipop,
the hardware backed
keystore on Android
doesn't support symmetric or
AES keys until Marshmallow,
and that's the
reason why it's been
taking a little bit of time.
I apologize.
I appreciate
everyone's patience.
We're working on it.
We're also looking on
features like key rotation,
like we've mentioned, and also
adding some signing support.
And obviously beyond like--
and I appreciate the
bugs that are coming in,
and the feature requests, and
we'll keep working on that.
So it's definitely
something we're working at.
It's coming-- don't worry.
We're looking at a beta and a
release hopefully this year.
[MUSIC PLAYING]
