從往年Google I/O大年夜會(huì)上會(huì)商了“Android利用的安然和隱私”以來，良多人對(duì)如安在Android上利用暗碼學(xué)手藝有些疑問。大年夜大都標(biāo)題問題都是環(huán)繞在為了某一特定目標(biāo)該利用哪個(gè)API上。是以，我們?cè)谶@里就是來切磋一下如安在本地存儲(chǔ)中呵護(hù)用戶的敏感信息，好比說暗碼和auth token(【譯者】授權(quán)標(biāo)識(shí)表記標(biāo)幟，這里直接用auth token更天然)。
一種反模式(弊端的做法——譯者注)
凡是我們都能意想到應(yīng)當(dāng)利用SecureRandom類來產(chǎn)生密鑰，用來對(duì)本地的敏感信息進(jìn)行加密，如許的例子很等閑找到，但實(shí)際上這類做法是欠妥的。
在這類編制中，不將密鑰作為一個(gè)字符串直接存儲(chǔ)在APK文件中，而是經(jīng)由過程別的一個(gè)字符串來生成密鑰–有點(diǎn)近似于經(jīng)由過程用戶口令生成加密密鑰。這類需要的混合手段可使報(bào)復(fù)打擊者不等閑破解加密信息，可是對(duì)一個(gè)有經(jīng)驗(yàn)的報(bào)復(fù)打擊者而言，這類策略很等閑被繞過，是以我們不保舉這類編制。
事實(shí)上，Android現(xiàn)有的安然機(jī)制中已為這類數(shù)據(jù)供給了很好的呵護(hù)，敏感數(shù)據(jù)應(yīng)當(dāng)標(biāo)識(shí)表記標(biāo)幟上MODE_PRIVATE，然后存儲(chǔ)在內(nèi)部存儲(chǔ)中，請(qǐng)寄望，千萬不克不及存儲(chǔ)在SD卡中，因?yàn)榘莺蚬?jié)制沒法強(qiáng)迫在外部存儲(chǔ)上起感化。
連絡(luò)設(shè)備加密辦法，這類編制可以杜盡盡大年夜部門報(bào)復(fù)打擊。
除此以外，像我們上面描述的那樣利用SecureRandom類還存在別的一個(gè)標(biāo)題問題。從Android4.2開端，SecureRandom的默許實(shí)現(xiàn)是OpenSSL，開辟者沒法籠蓋SecureRandom的內(nèi)部狀況信息，例以下面這段代碼:
SecureRandom secureRandom = new SecureRandom();
byte[] b = new byte[]{(byte)1};
secureRandom.setSeed(b);
//在Android4.2上，下面這行代碼老是返回統(tǒng)一個(gè)數(shù)字。
System.out.println(secureRandom.nextInt());
(【譯者注】這段代碼可以看到經(jīng)由過程法度籠蓋了random對(duì)象中的種子，造成每次生成的隨機(jī)數(shù)序列都是一樣的)
在之前的Android版本中，SecureRandom是基于Bouncy Castle實(shí)現(xiàn)的，它承諾像上面代碼如許的把持，每個(gè)SecureRandom類的實(shí)例產(chǎn)生偽隨機(jī)數(shù)時(shí)利用的種子是從/dev/urandom獲得的。(【譯者注】/dev/urandom是類Unix系統(tǒng)中按照當(dāng)前計(jì)較機(jī)混亂狀況，如內(nèi)存利用，CPU占用率等信息計(jì)較出來的隨機(jī)數(shù)，讀者可以在Linux下嘗嘗cat /dev/urandom，它會(huì)不斷地輸出亂碼，一般用“熵”這個(gè)專業(yè)術(shù)語形容計(jì)較機(jī)的混亂狀況)。那些試牟利用產(chǎn)生隨機(jī)數(shù)的開辟者凡是是經(jīng)由過程替代現(xiàn)有的種子來產(chǎn)生隨機(jī)數(shù)序列的(參考相干實(shí)現(xiàn)文檔)，假定種子固定，那么產(chǎn)生的隨機(jī)數(shù)列就是可猜想的，這一點(diǎn)是不服安的。此刻經(jīng)由過程OpenSSL實(shí)現(xiàn)，使得這類弊端的行動(dòng)不再可能呈現(xiàn)。
不幸的是，那些依托老的SecureRandom類的利用法度會(huì)發(fā)現(xiàn)每次法度啟動(dòng)時(shí)產(chǎn)生的隨機(jī)數(shù)都不一樣了(事實(shí)上，這就應(yīng)當(dāng)是隨機(jī)數(shù)產(chǎn)生器的期看行動(dòng))。想要經(jīng)由過程這類編制對(duì)加密密鑰混合已不成行了。
(【譯者注】原作者的意思是有些利用對(duì)敏感信息做加密，加密的話需要密鑰，可是密鑰假定直接存起來感覺很不安心，因而經(jīng)由過程產(chǎn)生隨機(jī)數(shù)的編制來對(duì)密鑰混合一下，那么每次法度啟動(dòng)時(shí)都要用不異的密鑰往解密數(shù)據(jù)，因而經(jīng)由過程一個(gè)固定的信息，好比一個(gè)暗碼，或記住某個(gè)隨機(jī)數(shù)字，凡是良多人用當(dāng)前時(shí)候，然后經(jīng)由過程這個(gè)固定的信息作為種子產(chǎn)生隨機(jī)數(shù)，用這個(gè)隨機(jī)數(shù)做密鑰，相當(dāng)于對(duì)這個(gè)固定信息做了一次混合把持。實(shí)際上這類編制仍是不服安，安然性就變成了若何包管這個(gè)種子的安然性，治標(biāo)不治本。下面的部門作者的意思是應(yīng)當(dāng)直接將密鑰打上MODE_PRIVATE的標(biāo)識(shí)表記標(biāo)幟存起來，經(jīng)由過程系統(tǒng)的拜候節(jié)制機(jī)制包管密鑰的安然性。)
準(zhǔn)確的編制
一種加倍合理的解決方案很簡(jiǎn)單，就是當(dāng)利用法度第一次啟動(dòng)時(shí)產(chǎn)生一個(gè)隨機(jī)的AES算法的密鑰：
public static SecretKey generateKey() throws NoSuchAlgorithmException
{
// 生成一個(gè)256位密鑰
final int outputKeyLength = 256;
SecureRandom secureRandom = new SecureRandom();
// Do *not* seed secureRandom! Automatically seeded from system entropy.
//不要給secureRandom一個(gè)固定的種子!經(jīng)由過程系統(tǒng)熵值產(chǎn)生隨機(jī)的種子
KeyGenerator keyGenerator = KeyGenerator.getInstance("AES");
keyGenerator.init(outputKeyLength, secureRandom);
SecretKey key = keyGenerator.generateKey();
return key;
}
寄望這類編制的安然性依托于若何包管密鑰的安然性，這可以依托于Android系統(tǒng)的內(nèi)部存儲(chǔ)的安然性。將密鑰直接存放在文件中，標(biāo)識(shí)表記標(biāo)幟為MODE_PRIVATE存在內(nèi)部存儲(chǔ)器。(【譯者注】我們良多人的Android手機(jī)都被Root過的，良多多少利用也會(huì)獲得Root權(quán)限，Root權(quán)限用戶是可以做任何工作的。。。這如何辦呢？)
加倍安然的編制
假定你的利用還需要額外的加密把持，那么一個(gè)保舉的編制是每次進(jìn)進(jìn)你的利用時(shí)需要輸進(jìn)一個(gè)口令或PIN碼。然后將這個(gè)口令傳給 PBKDF2(PBKDF2，基于口令的密鑰導(dǎo)出函數(shù)版本2，是RSA安然公司提出的密鑰導(dǎo)出算法，凡是常利用來按照口令獲得密鑰，經(jīng)由過程一種叫做密鑰拉伸的專業(yè)手藝)，Android在SecretKeyFactory類中供給了一個(gè)叫做PBKDF2WithHmacSHA1的實(shí)現(xiàn)：
public static SecretKey generateKey(char[] passphraseOrPin, byte[] salt) throws NoSuchAlgorithmException, InvalidKeySpecException
{
//PBKDF2算法履行輪數(shù)，這個(gè)數(shù)字越大年夜，計(jì)較時(shí)候越長(zhǎng)，你應(yīng)當(dāng)讓這個(gè)數(shù)字
//足夠大年夜，乃至于這個(gè)算法履行時(shí)候超越100毫秒以包管安然性
final int iterations = 1000;
// 產(chǎn)生一個(gè)256位的密鑰
final int outputKeyLength = 256;
SecretKeyFactory secretKeyFactory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
KeySpec keySpec = new PBEKeySpec(passphraseOrPin, salt, iterations, outputKeyLength);
SecretKey secretKey = secretKeyFactory.generateSecret(keySpec);
return secretKey;
}
加密鹽應(yīng)當(dāng)是一個(gè)經(jīng)由過程SecureRandom產(chǎn)生的隨機(jī)字符串，和加密密文一路存放在內(nèi)部存儲(chǔ)器中。利用加密鹽很首要，它可以有效避免字典報(bào)復(fù)打擊。
(【譯者注】看PBKDF2WithHmacSHA1這個(gè)名字也能夠知道該算法是基于SHA1算法的，常常報(bào)復(fù)打擊這類單向函數(shù)編制就是字典報(bào)復(fù)打擊，預(yù)先計(jì)較好大年夜量的明文對(duì)應(yīng)的密文，就像是明文對(duì)應(yīng)密文的字典，然后再進(jìn)行一一對(duì)比，假定明文字符串在加密前和一個(gè)隨機(jī)字符串做個(gè)連接把持，那么那些預(yù)先計(jì)較的字典救沒用了。)
查抄你的利用是不是是準(zhǔn)確的利用SecureRandom
如本文和Jelly Bean的新安然特點(diǎn)所述，Android4.2的SecureRandom默許實(shí)現(xiàn)產(chǎn)生了改變，用它產(chǎn)生固定密鑰已行不通了。
假定你也用了這類弊端編制的話，我們建議此刻就更新你的利用，避免當(dāng)用戶進(jìn)級(jí)到Android4.2或以上版本后產(chǎn)生一些莫名其妙的弊端。