加密原則：

1   App代碼安全，包括代碼混淆，加密或者app加殼。
2   App數據存儲安全，主要指在磁盤做數據持久化的時候所做的加密。
3   App網絡傳輸安全，指對數據從客戶端傳輸到Server中間過程的加密，防止網絡世界當中其他節點對數據的竊聽。

一：對稱加密的話用AES最好，蘋果系統（鑰匙串也是用的AES加密），美國安全局，RSA中的對稱加密用的都是AES加密。

• 1 用戶密碼本地化的話，建議使用鑰匙串加密。使用第三方SSkeychain.
  //SSkeychain第三方加密 采用AES（）對本地化用戶名 密碼進行加密 對稱加密

    NSString *userName = @"cerastes";
    NSString *password = @"新浪科技訊 北京時間5月25日早間消息，美國超級高鐵公司Hyperloop Transportation Technologies(HTT)周二公布了一種智能材料。這種材料集成了傳感器，將被用于制造超級高鐵的車輛。HTT表示，這種材料主要由輕量級的碳纖維構成，強度超過任何鋼材料10倍，而且比鋁合金還輕，被稱作“Vibranium”(汎合金，注：與漫畫人物“美國隊長”盾牌的材料同名)。利用這種材料可以降低車輛長途行駛所需的能耗。此外，材料內集成的傳感器可以測量車輛的信息，并將其回傳給運營中心。這些傳感器可以實時讀取車輛的溫度、穩定度和完整度，確保安全和性能。Hyperloop超級高鐵的時速最高可以達到700英里(約合1127公里)，最先由特斯拉CEO伊隆·馬斯克(Elon Musk)提出。目前，有兩家公司試圖將馬斯克的設想變為現實，而HTT是其中之一。另一家名為Hyperloop One的公司本月早些時候在內華達州的沙漠中展示了測試軌道的初步工作。HTT尚未公布類似的磁力推進系統。該公司目前專注于安全性方面的創新。該公司計劃利用兩層智能材料去建造車輛，因此即使外層材料損毀，車輛仍可以安全運行。　HTT CEO德科·阿爾伯恩(Derk Ahlborn)表示：“安全性是我們系統最重要的一個方面。”(維金)";
    NSString *bundleID = [NSBundle mainBundle].bundleIdentifier;
    [SSKeychain setPassword:@"111" forService:bundleID account:@"ni"];
    [SSKeychain setPassword:password forService:bundleID account:@"wo"];
    [SSKeychain setPassword:@"333" forService:bundleID account:@"ta"];
    [SSKeychain deletePasswordForService:bundleID account:@"ni"];
    NSString *passwords = [SSKeychain passwordForService:bundleID account:@"wo"];
    NSLog(@"SSkeychain解密=====%@",passwords);

• 2 一些簡單又機密的數據可以AES加密
  Objective-c的AES加密和解密算法的具體實現代碼如下：

 1.拓展NSData，增加AES256加密方法
//NSData+AES256.h
#import <Foundation/Foundation.h>
#import <CommonCrypto/CommonDigest.h>
#import <CommonCrypto/CommonCryptor.h>
@interface NSData(AES256)
-(NSData *) aes256_encrypt:(NSString *)key;
-(NSData *) aes256_decrypt:(NSString *)key;
@end
 
//
//NSData+AES256.m
//
#import "NSData+AES256.h"
 
@implementation NSData(AES256)
 
- (NSData *)aes256_encrypt:(NSString *)key   //加密
{
    char keyPtr[kCCKeySizeAES256+1];
    bzero(keyPtr, sizeof(keyPtr));
    [key getCString:keyPtr maxLength:sizeof(keyPtr) encoding:NSUTF8StringEncoding];
    NSUInteger dataLength = [self length];
    size_t bufferSize = dataLength + kCCBlockSizeAES128;
    void *buffer = malloc(bufferSize);
    size_t numBytesEncrypted = 0;
    CCCryptorStatus cryptStatus = CCCrypt(kCCEncrypt, kCCAlgorithmAES128,
                                          kCCOptionPKCS7Padding | kCCOptionECBMode,
                                          keyPtr, kCCBlockSizeAES128,
                                          NULL,
                                          [self bytes], dataLength,
                                          buffer, bufferSize,
                                          &numBytesEncrypted);
    if (cryptStatus == kCCSuccess) {
        return [NSData dataWithBytesNoCopy:buffer length:numBytesEncrypted];
    }
    free(buffer);
    return nil;
}
 
- (NSData *)aes256_decrypt:(NSString *)key   //解密
{
    char keyPtr[kCCKeySizeAES256+1];
    bzero(keyPtr, sizeof(keyPtr));
    [key getCString:keyPtr maxLength:sizeof(keyPtr) encoding:NSUTF8StringEncoding];
    NSUInteger dataLength = [self length];
    size_t bufferSize = dataLength + kCCBlockSizeAES128;
    void *buffer = malloc(bufferSize);
    size_t numBytesDecrypted = 0;
    CCCryptorStatus cryptStatus = CCCrypt(kCCDecrypt, kCCAlgorithmAES128,
                                          kCCOptionPKCS7Padding | kCCOptionECBMode,
                                          keyPtr, kCCBlockSizeAES128,
                                          NULL,
                                          [self bytes], dataLength,
                                          buffer, bufferSize,
                                          &numBytesDecrypted);
    if (cryptStatus == kCCSuccess) {
        return [NSData dataWithBytesNoCopy:buffer length:numBytesDecrypted];
 
    }
    free(buffer);
    return nil;
}
@end
2.拓展NSString，增加AES256加密方法，需要導入NSData+AES256.h
//
//NSString +AES256.h
//
 
#import <Foundation/Foundation.h>
#import <CommonCrypto/CommonDigest.h>
#import <CommonCrypto/CommonCryptor.h>
 
#import "NSData+AES256.h"
 
@interface NSString(AES256)
 
-(NSString *) aes256_encrypt:(NSString *)key;
-(NSString *) aes256_decrypt:(NSString *)key;
 
@end
 
 
//
//NSString +AES256.h
//
 
@implementation NSString(AES256)
 
-(NSString *) aes256_encrypt:(NSString *)key
{
    const char *cstr = [self cStringUsingEncoding:NSUTF8StringEncoding];
    NSData *data = [NSData dataWithBytes:cstr length:self.length];
    //對數據進行加密
    NSData *result = [data aes256_encrypt:key];
 
    //轉換為2進制字符串
    if (result && result.length > 0) {
 
        Byte *datas = (Byte*)[result bytes];
        NSMutableString *output = [NSMutableString stringWithCapacity:result.length * 2];
        for(int i = 0; i < result.length; i++){
            [output appendFormat:@"%02x", datas[i]];
        }
        return output;
    }
    return nil;
}
 
-(NSString *) aes256_decrypt:(NSString *)key
{   
    //轉換為2進制Data
    NSMutableData *data = [NSMutableData dataWithCapacity:self.length / 2];
    unsigned char whole_byte;
    char byte_chars[3] = {'\0','\0','\0'};
    int i;
    for (i=0; i < [self length] / 2; i++) {
        byte_chars[0] = [self characterAtIndex:i*2];
        byte_chars[1] = [self characterAtIndex:i*2+1];
        whole_byte = strtol(byte_chars, NULL, 16);
        [data appendBytes:&whole_byte length:1];
    }
 
    //對數據進行解密
    NSData* result = [data aes256_decrypt:key];
    if (result && result.length > 0) {
        return [[NSString alloc] initWithData:result encoding:NSUTF8StringEncoding]autorelease];
    }
    return nil;
}
@end

二:mac加密：key值得來由。

網絡登錄注冊傳送密碼建議使用hmac加密。

• 官方模型分析：
  甲乙雙方進行數據交換可以采取如下流程完成
  1、甲方向乙方公布摘要算法（就是指定要使用的摘要算法名）
  2、甲乙雙方按照約定構造密鑰，雙方擁有相同的密鑰（一般是一方構造密鑰后通知另外一方，此過程不需要通過程序實現，就是雙方約定個字符串，但是這個字符串可不是隨便設定的，也是通過相關算法獲取的）
  3、甲方使用密鑰對消息做摘要處理，然后將消息和生成的摘要消息一同發送給乙方
  4、乙方收到消息后，使用甲方已經公布的摘要算法+約定好的密鑰 對收到的消息進行摘要處理。然后比對自己的摘要消息和甲方發過來的摘要消息。甄別消息是否是甲方發送過來的。
• iOS版，注冊的時候傳輸一個MD5加密的密碼（避免明文傳輸）過去，服務器返回一個隨機數key，客服端key存本地。然后每次登錄的時候用這個隨機數key加密密碼（加鹽）。客服端存密碼的MD5和key。這樣客服端可以同樣用key 加密密碼。若賬號異地登錄（即手機里沒有注冊的key），則通過傳輸密碼加鹽（最好用當前時間加點其他文字，這樣可以做權限保護，防止抓包獲得key）獲得key。

三：MD5加密

• 加時間戳
• 折疊追加字符串。

NSString *subString1 =[string substringToIndex:string.length -2];
    NSString *subString2 =[string substringFromIndex:string.length -2];
    NSString *newString = [NSString stringWithFormat:@"%@%@",subString2,subString1];

• 多次MD5加密

四：RSA非對稱加密。

• 原理：http://blog.csdn.net/sean_cd/article/details/6966130
• 購買了證書的話先傳送公鑰到客戶端，再用AES傳輸數據。防止中間人攻擊，證書startssl就是個不錯的選擇，有1年的免費服務。
• 自制證書（蘋果審核不一定通過），客服端存本地公鑰，且每次使用時都要提示是否使用該不安全證書，有可能被中間人攻擊。

五：token

• 一般的登陸：
  客戶端第一次發出登錄請求時， 用戶密碼以明文的方式傳輸， 一旦被截獲， 后果嚴重。因此密碼需要加密，例如可采用RSA非對稱加密。具體流程如下：
  客戶端向服務器第一次發起登錄請求（不傳輸用戶名和密碼）。
  服務器利用RSA算法產生一對公鑰和私鑰。并保留私鑰， 將公鑰發送給客戶端。
  客戶端收到公鑰后， 加密用戶密碼， 向服務器發起第二次登錄請求（傳輸用戶名和加密后的密碼）。
  服務器利用保留的私鑰對密文進行解密，得到真正的密碼。

• token加密：
  再仔細核對上述登錄流程， 我們發現服務器判斷用戶是否登錄， 完全依賴于sessionId, 一旦其被截獲， 黑客就能夠模擬出用戶的請求。于是我們需要引入token的概念： 用戶登錄成功后， 服務器不但為其分配了sessionId, 還分配了token， token是維持登錄狀態的關鍵秘密數據。在服務器向客戶端發送的token數據，也需要加密。于是一次登錄的細節再次擴展。
  客戶端向服務器第一次發起登錄請求（不傳輸用戶名和密碼）。服務器利用RSA算法產生一對公鑰和私鑰。并保留私鑰， 將公鑰發送給客戶端。
  客戶端收到公鑰后， 加密用戶密碼，向服務器發送用戶名和加密后的用戶密碼； 同時另外產生一對公鑰和私鑰，自己保留私鑰, 向服務器發送公鑰； 于是第二次登錄請求傳輸了用戶名和加密后的密碼以及客戶端生成的公鑰。
  服務器利用保留的私鑰對密文進行解密，得到真正的密碼。 經過判斷， 確定用戶可以登錄后，生成sessionId和token， 同時利用客戶端發送的公鑰，對token進行加密。最后將sessionId和加密后的token返還給客戶端。
  客戶端利用自己生成的私鑰對token密文解密， 得到真正的token。圖示如下：

  
  

  login-300x181.png

登錄保持（也就是http數據請求階段）
引入token后，http請求被獲取問題便可得到解決。 服務器將token和其它的一些變量， 利用散列加密算法得到簽名后，連同sessionId一并發送給服務器； 服務器取出保存于服務器端的token,利用相同的法則生成校驗簽名， 如果客戶端簽名與服務器的校驗簽名一致， 就認為請求來自登錄的客戶端。（支付寶一樣的機制）結構圖如下：

keep_login.png

注：token失效的兩種情況：

     用戶登錄出系統
     token在后臺的規定時間內失效（每個token都是有時間效應的）

失效原理：在服務器端的redis中刪除相應key為session的鍵值對。

token+散列算法

散列是信息的提煉，通常其長度要比信息小得多，且為一個固定長度。加密性強的散列一定是不可逆的，這就意味著通過散列結果，無法推出任何部分的原始信息。任何輸入信息的變化，哪怕僅一位，都將導致散列結果的明顯變化，這稱之為雪崩效應。散列還應該是防沖突的，即找不出具有相同散列結果的兩條信息。具有這些特性的散列結果就可以用于驗證信息是否被修改。
散列算法可以用來加密token生成簽名， 以便token信息不暴露在網絡同時還能驗證登錄的有效性。

補充：

網絡訪問常用加密：

• post請求那是必須的。抓包可以的到。
• 加請求頭，抓包可以得到。
• 用key值做權限保護，key值的有效時間不宜過長。抓包可以的到。
• 如果要做到相對安全的傳送可以用時間戳MD5加密密碼來過得key。
• 要想非常安全的傳輸數據，建議使用https。抓包不可以，但是中間人攻擊則有可能。防止中間人攻擊：http://blog.csdn.net/u010731949/article/details/50538280

六：https加密：

• 信任機構頒發的CA證書：如阿里云：https://www.aliyun.com/product/cas?spm=5176.7742214.416540.129.5amrlf

AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager];
AFSecurityPolicy *securityPolicy = [[AFSecurityPolicy alloc] init];
[securityPolicy setAllowInvalidCertificates:NO];
[securityPolicy setSSLPinningMode:AFSSLPinningModeCertificate];
[securityPolicy setValidatesDomainName:YES];
[securityPolicy setValidatesCertificateChain:NO];
manager.securityPolicy = securityPolicy;

 
 * 自簽名證書：沒有那么安全。

# 七：參考文檔（純copy）

安全相關的基礎概念

網絡安全相關的概念非常之多，要在廣度和深度上都有所造詣很困難。但如果只是站在保障App通信基本安全這個維度上，做到合理使用安全算法，比大部分人所預期的都要簡單很多。以下這些基礎概念是必備知識：

   ?   對稱加密算法，代表算法AES
   ?   非對稱加密算法，代表算法RSA，ECC
   ?   電子簽名，用于確認消息發送方的身份
   ?   消息摘要生成算法，MD5，SHA，用于檢測消息是否被第三方修改過

怎么樣算安全？

安全問題說白了是信任問題，談到信任一定要有一個可被信任的實體。假設某天A收到了一條“Message”，如果這個消息確實是來自B，消息就可以被信任，那么B就這安全問題當中可被信任的實體。

對于A來說只要滿足三點就說明收到“Message”是安全的：

   ?   Message有B的電子簽名，表明消息確實是來自B。
   ?   Message沒有被篡改過。
   ?   Message被某種加密算法加密過，只有A和B知道如何解密。

A和B的交談如果放到網絡世界當中，就是典型的Client－Server模式。和現實世界當中聊天不同的是，A和B所說的任何話都可以輕而易舉的被其他人聽到，隔墻隨處有耳。

怎么去保證App網絡傳輸的安全？

為了保證傳輸數據的安全，需要使用加密算法。在決定什么樣的業務場景使用什么樣的加密算法之前，先要了解我們的工具箱里有哪些可用工具。加密算法的工具箱里其實就兩種工具：“對稱”加密算法和“非對稱”加密算法。清楚這兩個分類是合理設計加密算法使用場景的大前提，兩個分類里我們各挑選一個代表算法來研究，“對稱”加密挑選AES，“非對稱”加密選擇RSA。了解AES和RSA之后我們再針對一些特定業務場景設計安全模型。

App網絡安全實戰

在App安全上的投入再多也不會過，不過安全問題上所投入的開發資源應該根據開發團隊技術積累，產品發布deadline，用戶規模及產品關注度等綜合因素考量。結合這些因素我把App分為三類，各類App對安全級別的要求不同，投入產出也不同。

## 第一類，作坊式創業App

這些年伴隨著移動互聯網的創業潮，各式各樣的app出現在用戶的手機端。對于創業初期的團隊來說，能把業務模型盡快實現上線當然是重中之重。但很多創業團隊在安全上的投入幾乎為零，所導致的安全問題比想象中的要嚴重。我見過不少使用http明文傳輸用戶名密碼的app，其中甚至包括一些知名傳統企業。其實只要照顧到一些基礎方面就能過濾掉大部分的安全漏洞了。這里提供一些小tip供創業初期團隊參考：

Tip 1:盡量使用https

https可以過濾掉大部分的安全問題。https在證書申請，服務器配置，性能優化，客戶端配置上都需要投入精力，所以缺乏安全意識的開發人員容易跳過https，或者拖到以后遇到問題再優化。https除了性能優化麻煩一些以外其他都比想象中的簡單，如果沒精力優化性能，至少在注冊登錄模塊需要啟用https，這部分業務對性能要求比較低。

Tip 2:不要傳輸密碼

不知道現在還有多少app后臺是明文存儲密碼的。無論客戶端，server還是網絡傳輸都要避免明文密碼，要使用hash值。客戶端不要做任何密碼相關的存儲，hash值也不行。存儲token進行下一次的認證，而且token需要設置有效期，使用refresh token去申請新的token。

Tip 3:Post并不比Get安全

事實上，Post和Get一樣不安全，都是明文。參數放在QueryString或者Body沒任何安全上的差別。在Http的環境下，使用Post或者Get都需要做加密和簽名處理。

Tip 4:不要使用301跳轉

301跳轉很容易被Http劫持攻擊。移動端http使用301比桌面端更危險，用戶看不到瀏覽器地址，無法察覺到被重定向到了其他地址。如果一定要使用，確保跳轉發生在https的環境下，而且https做了證書綁定校驗。

Tip 5:http請求都帶上MAC

所有客戶端發出的請求，無論是查詢還是寫操作，都帶上MAC（Message Authentication Code）。MAC不但能保證請求沒有被篡改（Integrity），還能保證請求確實來自你的合法客戶端（Signing）。當然前提是你客戶端的key沒有被泄漏，如何保證客戶端key的安全是另一個話題。MAC值的計算可以簡單的處理為hash（request params＋key）。帶上MAC之后，服務器就可以過濾掉絕大部分的非法請求。MAC雖然帶有簽名的功能，和RSA證書的電子簽名方式卻不一樣，原因是MAC簽名和簽名驗證使用的是同一個key，而RSA是使用私鑰簽名，公鑰驗證，MAC的簽名并不具備法律效應。

Tip 6:http請求使用臨時密鑰

高延遲的網絡環境下，不經優化https的體驗確實會明顯不如http。在不具備https條件或對網絡性能要求較高且缺乏https優化經驗的場景下，http的流量也應該使用AES進行加密。AES的密鑰可以由客戶端來臨時生成，不過這個臨時的AES key需要使用服務器的公鑰進行加密，確保只有自己的服務器才能解開這個請求的信息，當然服務器的response也需要使用同樣的AES key進行加密。由于http的應用場景都是由客戶端發起，服務器響應，所以這種由客戶端單方生成密鑰的方式可以一定程度上便捷的保證通信安全。

Tip 7:AES使用CBC模式

不要使用ECB模式，原因前面已經分析過，記得設置初始化向量，每個block加密之前要和上個block的秘文進行運算。

## 第二類，正規軍App

All Traffic HTTPS

全站使用HTTPS，而且是強制使用。baidu到今天（2016.04.13）還沒有強制使用HTTPS。所有的流量都應該在HTTPS上產生，沒有人可以決定哪些流量是可以不用考慮安全問題的。如果自建長連接使用tcp，udp或者其他網絡協議，也應該實現類似HTTPS的密鑰協商流程。

Certificate Pinning

RSA的簽名機制雖然看著安全，一旦出現上游證書頒發機構私鑰泄漏，或者簽名流程發現漏洞等情況，中間人攻擊還是會導致數據被第三方破解甚至被釣魚。Certificate Pinning是一種與服務器證書強綁定的機制，要么綁定證書本身，需要證書更新機制配合加強安全性，要么使用私鑰綁定，這樣更新證書的時候只要保證私鑰不變即可。現在流行的HTTP framework，iOS端如AFNetworking，Android端如OKHttp都支持Certificate Pinning。

Perfect Forward Secrecy

很多人會覺得非對稱加密算法足夠安全，只要使用了RSA或者AES，加密過后的數據就認為安全。但沒有絕對的安全，無論是RSA或者AES算法本身都有可能在未來某一天被破解，正如當年的DES，甚至有傳言NSA正如當年掌握了differential cryptanalysis一樣，現在已經獲取了某種方法來破解當前互聯網當中的部分網絡流量，至于到底是RSA還是AES就不得而知了。

未來計算機的計算能力是個未知數，或許某一天brute force能夠暴力破解的密鑰長度會遠超128bits（現階段上限應該在80bits）。

2014年1月3日，美國國家安全局（NSA）正在研發一款用于破解加密技術的量子計算機，希望破解幾乎所有類型的加密技術。

即使算法本身沒有被破解，密鑰也有可能被泄漏，技術上的原因或者政策上的因素都可能導致RSA或者ECC的私鑰被泄漏。所以盡可能針對不同的session使用不同的key能夠使的我們的數據更佳安全。

Forward Secrecy就是為了避免某個私鑰的泄漏或者被破解而導致歷史數據一起泄漏。現在google的https配置所使用的是TLS_ECDHE_RSA算法，每次對稱密鑰的協商都是使用ECC生成臨時的公鑰私鑰對（之前提到過ECC在快速生成密鑰對上有優勢），身份驗證使用RSA算法進行簽名。

每天跟蹤信息安全動態

安全的攻防戰不會有窮盡的一天，算法的更替會伴隨著人類對知識的無盡渴望延綿至不可預知的未來。AES說不定哪天被破解了，openSSL可能又出現新的漏洞了，google又提倡新的安全模型了，NSA的量子計算機說不準已經在悄悄解密google的流量了，每天跟蹤八卦最新業界動態才是碼農避免因bug而背黑鍋的不二法寶。

## 第三類，帶節操正規軍App

現在互聯網早已滲入每個人的平常生活當中，當我們的行為越來越多的遷移到互聯網這個媒介當中之后，行為本身及所產生的關聯數據都將被滴水不漏的記錄起來，特別是在大數據研究興起的當下，服務提供商總是希望盡可能多的記錄用戶所有的行為數據。每個互聯網產品的使用者都成了樣本，你的購物記錄，商品瀏覽歷史，搜索引擎搜索記錄，打車記錄，租房記錄，股票記錄，甚至聊天記錄等等都是樣本，毫不夸張的說，如果將淘寶，微信，支付寶，快滴，美團等等高頻次產品數據統一分析，基本上可以將你的身高，性別，年齡，三維，家庭住址，戀愛史，家庭成員，甚至是個人喜好，性格等等完美的呈現出來，其后果遠不是一個騷擾電話帶來的隱私泄漏那么簡單。

移動互聯網的大部分使用者還不具備強烈的安全意識，當你用手機號作為登錄id方便記憶的同時，騷擾電話就可能隨時來臨，你在百度輸入租房關鍵字，下一秒中介就已經電話打上門。當你允許app上傳通訊錄匹配可能認識的好友同時，你認識哪些人就變得一清二楚，你p2p借貸未及時歸還時，你的親朋好友第二天就收到了催債電話。我們在享受移動互聯網的便利同時，付出的是個人隱私這種隱形成本。下一次，當我們感嘆新app好用便利的同時，靜思三分鐘，好好想想我們的哪些隱私又被當白菜賣了。

在互聯網受眾的安全意識普遍覺醒之前，只能靠app開發商，服務提供商的節操來保證用戶信息隱私安全。

帶節操的App在打算記錄用戶行為或者數據之前會考慮下是不是真的有需要，用戶的確會有需要查詢歷史購買記錄，但有多少人會在意自己幾年前花幾個小時瀏覽了杜蕾斯的產品。

服務器作為數據存儲或者轉發的媒介是不是真的需要了解真實的數據為何？現在WhatsApp，Telegram都已經支持端到端的加密聊天方式，服務器本身看到的都是秘文，只做秘文轉發處理，帶著這樣的節操設計產品，用戶才會覺得安全。

WhatsApp的端到端加密安全模型是怎么樣實現的呢？非常值得學習。

簡單來說是嚴格遵循forward secrecy。每個用戶在注冊成功之后會在服務器存一對永久的Identity Key，一對臨時的Signed Pre Key（Signed Pre Key由Identity Key簽名，每隔一段時間變化一次），n對臨時的One-Time Pre Key（每次建立session消耗一個）。

每次session開始建立的時候使用Identity Key，Signed Pre Key， One Time Key生成Master Secret。Master Secret再通過HKDF算法生成對稱加密使用的Root Key，Chain Key，Message Key。

Forward Secrecy體現在每次sender發送的消息被ack后，都會交換新的臨時ECC Key對，并更新Root Key，Chain Key，Message Key。這樣網絡中的流量即使被第三方緩存起來，而且某一天某個Key Pair的私鑰被破解，也不會對之前的流量產生安全影響。ECC Key對會隨著消息的發送不停的“Ratcheting”。這是屬于非對稱加密的Forward Secrecy。

在sender的消息被ack之前，也就是新的ECC Key對交換成功之前，Message Key也會通過HKDF算法不停的“Ratcheting”，確保每條消息所使用的對稱密鑰也不相同。這是屬于對稱加密的Forward Secrecy。

有興趣深入了解的同學可以自己google：WhatsApp Security WhitePaper。