網路安全與加密 1.數據安全 2.Base64 3.常見的加密演算法和其它 4.單向散列函數 5.對稱加密 6.非對稱加密 7.數字簽名 1.數字簽名的應用場景 需要嚴格驗證發送方身份信息情況 2.數字簽名原理 1)客戶端處理 ①對"消息"進行 HASH 得到 "消息摘要" ②發送方使用自己的私鑰對" ...
網路安全與加密
1.數據安全
01 攻城利器:Charles(公司中一般都使用該工具來抓包,並做網路測試)
註意:Charles在使用中的亂碼問題,可以顯示包內容,然後打開info.plist文件,找到java目錄下麵的VMOptions,在後面添加一項:-Dfile.encoding=UTF-8
02 MD5消息摘要演算法是不可逆的。
03 數據安全的原則
1)在網路上"不允許"傳輸用戶隱私數據的"明文"
2)在本地"不允許"保存用戶隱私數據的"明文"
04 數據加密的方式和規範一般公司會有具體的規定,不必多花時間。
2.Base64
1.Base64簡單說明
描述:Base64可以成為密碼學的基石,非常重要。
特點:可以將任意的二進位數據進行Base64編碼
結果:所有的數據都能被編碼為並只用65個字元就能表示的文本文件。
65字元:A~Z a~z 0~9 + / =
對文件進行base64編碼後文件數據的變化:編碼後的數據~=編碼前數據的4/3,會大1/3左右。
2.命令行進行Base64編碼和解碼
編碼:base64 123.png -o 123.txt
解碼:base64 123.txt -o test.png -D
2.Base64編碼原理
1)將所有字元轉化為ASCII碼;
2)將ASCII碼轉化為8位二進位;
3)將二進位3個歸成一組(不足3個在後邊補0)共24位,再拆分成4組,每組6位;
4)統一在6位二進位前補兩個0湊足8位;
5)將補0後的二進位轉為十進位;
6)從Base64編碼表獲取十進位對應的Base64編碼;
處理過程說明:
a.轉換的時候,將三個byte的數據,先後放入一個24bit的緩衝區中,先來的byte占高位。
b.數據不足3byte的話,於緩衝區中剩下的bit用0補足。然後,每次取出6個bit,按照其值選擇查表選擇對應的字元作為編碼後的輸出。
c.不斷進行,直到全部輸入數據轉換完成。
d.如果最後剩下兩個輸入數據,在編碼結果後加1個“=”;
e.如果最後剩下一個輸入數據,編碼結果後加2個“=”;
f.如果沒有剩下任何數據,就什麼都不要加,這樣才可以保證資料還原的正確性。
3.實現
a.說明:
1)從iOS7.0 開始,蘋果就提供了base64的編碼和解碼支持
2)如果是老項目,則還能看到base64編碼和解碼的第三方框架,如果當前不再支持iOS7.0以下版本,則建議替換。
b.相關代碼:
//給定一個字元串,對該字元串進行Base64編碼,然後返回編碼後的結果
-(NSString *)base64EncodeString:(NSString *)string
{
//1.先把字元串轉換為二進位數據
NSData *data = [string dataUsingEncoding:NSUTF8StringEncoding];
//2.對二進位數據進行base64編碼,返回編碼後的字元串
return [data base64EncodedStringWithOptions:0];
}
//對base64編碼後的字元串進行解碼
-(NSString *)base64DecodeString:(NSString *)string
{
//1.將base64編碼後的字元串『解碼』為二進位數據
NSData *data = [[NSData alloc]initWithBase64EncodedString:string options:0];
//2.把二進位數據轉換為字元串返回
return [[NSString alloc]initWithData:data encoding:NSUTF8StringEncoding];
}
c.終端測試命令
$ echo -n A | base64
$ echo -n QQ== |base64 -D
3.常見的加密演算法和其它
1. base64 編碼格式
2. 密碼學演化 "秘密本"-->RSA
3. 常見的加密演算法
1)消息摘要(單向散列函數)
2)對稱加密
3)非對稱加密
4)證書等
4.單向散列函數
1.單向散列函數的特點:
①加密後密文的長度是定長的
②如果明文不一樣,那麼散列後的結果一定不一樣
③如果明文一樣,那麼加密後的密文一定一樣(對相同數據加密,加密後的密文一樣)
④所有的加密演算法是公開的
⑤不可以逆推反算
2.經典加密演算法
1)MD5加密
2)SHA1
3)SHA512
3.MD5加密演算法簡單說明
1)對字元串進行MD5加密可以得到一個32個字元的密文
2)加密之後不能根據密文逆推出明文
3)MD5已經被破解(暴力破解|碰撞檢測)
4.MD5加密進階
1)先加鹽,然後再進行MD5
2)先亂序,再進行MD5加密
3)亂序|加鹽,多次MD5加密等
4)使用消息認證機制,即HMAC-MD5-先對密鑰進行加密,加密之後進行兩次MD5散列
5)加密命令行
MD5加密-字元串 $ echo -n "520it" |md5
MD5加密-文件1 $ md5 abc.png
SHA1加密: $ echo -n "520it" |openssl sha -sha1
SHA256 $ echo -n "520it" |openssl sha -sha256
SHA512 $ echo -n "520it" |openssl sha -sha512
hmacMD5加密 $ echo -n "520it" |openssl dgst -md5 -hmac "123"
5.散列函數應用領域
1)搜索 多個關鍵字,先對每個關鍵字進行散列,然後多個關鍵字進行或運算,如果值一致則搜索結果一致
2)版權 對文件進行散列判斷該文件是否是正版或原版的
3)文件完整性驗證 對整個文件進行散列,比較散列值判斷文件是否完整或被篡改
6.消息認證機制(HMAC)簡單說明
1)原理
①消息的發送者和接收者有一個共用密鑰
②發送者使用共用密鑰對消息加密計算得到MAC值(消息認證碼)
③消息接收者使用共用密鑰對消息加密計算得到MAC值
④比較兩個MAC值是否一致
2)使用
①客戶端需要在發送的時候把(消息)+(消息·HMAC)一起發送給伺服器
②伺服器接收到數據後,對拿到的消息用共用的KEY進行HMAC,比較是否一致,如果一致則信任
5.對稱加密
1.對稱加密的特點
1)加密/解密使用相同的密鑰
2)加密和解密的過程是可逆的(明文-》明文-》明文)
2.經典演算法
1)DES 數據加密標準
2)3DES 使用3個密鑰,對消息進行(密鑰1·加密)+(密鑰2·解密)+(密鑰3·加密)
3)AES 高級加密標準
3.分組密碼簡單說明
密碼演算法可以分為分組密碼和流密碼兩種。
分組密碼:每次只能處理特定長度的一zu數據的一類密碼演算法。一個分組的比特數量就稱之為分組長度。
ex:DES和3DES的分組長度都是64比特。即每次只能加密64比特的明文,並生成64比特的密文。AES的分組長度有128比特、192比特和256比特可以選擇。
流密碼:對數據流進行連續處理的一類演算法。流密碼中一般以1比特、8比特或者是32比特等作為單位倆進行加密和解密。
4.ECB分組模式
ECB模式的全稱為Electronic CodeBook模式。又成為電子密碼本模式。
特點:
1)使用ECB模式加密的時候,相同的明文分組會被轉換為相同的密文分組。
2)類似於一個巨大的明文分組-》密文分組的對照表。
終端測試命令:
加密 $ openssl enc -des-ecb -K 616263 -nosalt -in 123.txt -out 123.bin
解密 $ openssl enc -des-ecb -K 616263 -nosalt -in 123.bin -out 1231.txt -d
5.CBC分組模式
CBC模式全稱為Cipher Block Chainning模式(密文分組鏈接模式|電子密碼鏈條)
特點:在CBC模式中,首先將明文分組與前一個密文分組進行XOR運算,然後再進行加密。
終端命令:
加密 $ openssl enc -des-cbc -K 616263 -iv 0102030405060708 -nosalt -in a.txt -out a.bin
解密 $ openssl enc -des-cbc -K 616263 -iv 0102030405060708 -nosalt -in a.bin -out a1.txt -d
6.非對稱加密
1.非對稱加密的特點
1)使用公鑰加密,使用私鑰解密
2)公鑰是公開的,私鑰保密
3)加密處理安全,但是性能極差
2.經典演算法---RSA
1)RSA 原理
(1)求N,準備兩個質數p和q,N = p x q
(2)求L,L是p-1和q-1的最小公倍數。L = lcm(p-1,q-1)
(3)求E,E和L的最大公約數為1(E和L互質)
(4)求D,E x D mode L = 1
2)RSA加密小實踐
(1)p = 17,q = 19 =>N = 323
(2)lcm(p-1,q-1)=>lcm(16,18)=>L= 144
(3)gcd(E,L)=1 =>E=5
(4)E乘以幾可以mode L =1? D=29可以滿足
(5)得到公鑰為:E=5,N=323
(6)得到私鑰為:D=29,N=323
(7)加密 明文的E次方 mod N = 123的5次方 mod 323 = 225(密文)
(8)解密 密文的D次方 mod N = 225的29次方 mod 323 = 123(明文)
----------------
3)openssl生成密鑰命令
生成強度是 512 的 RSA 私鑰:$ openssl genrsa -out private.pem 512
以明文輸出私鑰內容:$ openssl rsa -in private.pem -text -out private.txt
校驗私鑰文件:$ openssl rsa -in private.pem -check
從私鑰中提取公鑰:$ openssl rsa -in private.pem -out public.pem -outform PEM -pubout
以明文輸出公鑰內容:$ openssl rsa -in public.pem -out public.txt -pubin -pubout -text
使用公鑰加密小文件:$ openssl rsautl -encrypt -pubin -inkey public.pem -in msg.txt -out msg.bin
使用私鑰解密小文件:$ openssl rsautl -decrypt -inkey private.pem -in msg.bin -out a.txt
將私鑰轉換成 DER 格式:$ openssl rsa -in private.pem -out private.der -outform der
將公鑰轉換成 DER 格式:$ openssl rsa -in public.pem -out public.der -pubin -outform der
-----------------
7.數字簽名
1.數字簽名的應用場景
需要嚴格驗證發送方身份信息情況
2.數字簽名原理
1)客戶端處理
①對"消息"進行 HASH 得到 "消息摘要"
②發送方使用自己的私鑰對"消息摘要" 加密(數字簽名)
③把數字簽名附著在"報文"的末尾一起發送給接收方
2)服務端處理
①對"消息" HASH 得到 "報文摘要"
②使用公鑰對"數字簽名" 解密
③對結果進行匹配
8.數字證書
1.簡單說明
證書和駕照很相似,裡面記有姓名、組織、地址等個人信息,以及屬於此人的公鑰,並有認證機構施加數字簽名,只要看到公鑰證書,我們就可以知道認證機構認證該公鑰的確屬於此人
2.數字證書的內容
1)公鑰
2)認證機構的數字簽名
3.證書的生成步驟
1)生成私鑰 openssl genrsa -out private.pem 1024
2)創建證書請求 openssl req -new -key private.pem -out rsacert.csr
3)生成證書並簽名,有效期10年 openssl x509 -req -days 3650 -in rsacert.csr -signkey private.pem -out rsacert.crt
4)將 PEM 格式文件轉換成 DER 格式 openssl x509 -outform der -in rsacert.crt -out rsacert.der
5)導出P12文件 openssl pkcs12 -export -out p.p12 -inkey private.pem -in rsacert.crt
4.iOS開發中的註意點
1)在iOS開發中,不能直接使用 PEM 格式的證書,因為其內部進行了Base64編碼,應該使用的是DER的證書,是二進位格式的
2)OpenSSL預設生成的都是PEM格式的證書
9.HTTPS的基本使用
1.https簡單說明
HTTPS(全稱:Hyper Text Transfer Protocol over Secure Socket Layer),是以安全為目標的HTTP通道,簡單講是HTTP的安全版。
即HTTP下加入SSL層,HTTPS的安全基礎是SSL,因此加密的詳細內容就需要SSL。 它是一個URI scheme(抽象標識符體系),句法類同http:體系。用於安全的HTTP數據傳輸。
https:URL表明它使用了HTTP,但HTTPS存在不同於HTTP的預設埠及一個加密/身份驗證層(在HTTP與TCP之間)。
2.HTTPS和HTTP的區別主要為以下四點:
一、https協議需要到ca申請證書,一般免費證書很少,需要交費。
二、http是超文本傳輸協議,信息是明文傳輸,https 則是具有安全性的ssl加密傳輸協議。
三、http和https使用的是完全不同的連接方式,用的埠也不一樣,前者是80,後者是443。
四、http的連接很簡單,是無狀態的;HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議,比http協議安全。
3.簡單說明
1)HTTPS的主要思想是在不安全的網路上創建一安全通道,並可在使用適當的加密包和伺服器證書可被驗證且可被信任時,對竊聽和中間人攻擊提供合理的保護。
2)HTTPS的信任繼承基於預先安裝在瀏覽器中的證書頒發機構(如VeriSign、Microsoft等)(意即“我信任證書頒發機構告訴我應該信任的”)。
3)因此,一個到某網站的HTTPS連接可被信任,如果伺服器搭建自己的https 也就是說採用自認證的方式來建立https通道,這樣一般在客戶端是不被信任的。
4)所以我們一般在瀏覽器訪問一些https站點的時候會有一個提示,問你是否繼續。
4.對開發的影響。
4.1 如果是自己使用NSURLSession來封裝網路請求,涉及代碼如下。
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
NSURLSession *session = [NSURLSession sessionWithConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration] delegate:self delegateQueue:[NSOperationQueue mainQueue]];
NSURLSessionDataTask *task = [session dataTaskWithURL:[NSURL URLWithString:@"https://www.apple.com"] completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
NSLog(@"%@", [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding]);
}];
[task resume];
}
/*
只要請求的地址是HTTPS的, 就會調用這個代理方法
我們需要在該方法中告訴系統, 是否信任伺服器返回的證書
Challenge: 挑戰 質問 (包含了受保護的區域)
protectionSpace : 受保護區域
NSURLAuthenticationMethodServerTrust : 證書的類型是 伺服器信任
*/
- (void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, NSURLCredential *))completionHandler
{
// NSLog(@"didReceiveChallenge %@", challenge.protectionSpace);
NSLog(@"調用了最外層");
// 1.判斷伺服器返回的證書類型, 是否是伺服器信任
if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) {
NSLog(@"調用了裡面這一層是伺服器信任的證書");
/*
NSURLSessionAuthChallengeUseCredential = 0, 使用證書
NSURLSessionAuthChallengePerformDefaultHandling = 1, 忽略證書(預設的處理方式)
NSURLSessionAuthChallengeCancelAuthenticationChallenge = 2, 忽略書證, 並取消這次請求
NSURLSessionAuthChallengeRejectProtectionSpace = 3, 拒絕當前這一次, 下一次再詢問
*/
// NSURLCredential *credential = [NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust];
NSURLCredential *card = [[NSURLCredential alloc]initWithTrust:challenge.protectionSpace.serverTrust];
completionHandler(NSURLSessionAuthChallengeUseCredential , card);
}
}
// 如果是使用AFN框架,那麼我們不需要做任何額外的操作,AFN內部已經做了處理。
5.ATS
1)iOS9中新增App Transport Security(簡稱ATS)特性, 讓原來請求時候用到的HTTP,全部都轉向TLS1.2協議進行傳輸。
2)這意味著所有的HTTP協議都強制使用了HTTPS協議進行傳輸。
3)如果我們在iOS9下直接進行HTTP請求是會報錯。系統會告訴我們不能直接使用HTTP進行請求,需要在Info.plist中控制ATS的配置。
"NSAppTransportSecurity"是ATS配置的根節點,配置了節點表示告訴系統要走自定義的ATS設置。
"NSAllowsAritraryLoads"節點控制是否禁用ATS特性,設置YES就是禁用ATS功能。
4)有兩種解決方法,一種是修改配置信息繼續使用以前的設置。
另一種解決方法是所有的請求都基於基於"TLS 1.2"版本協議。(該方法需要嚴格遵守官方的規定,如選用的加密演算法、證書等)
/*
ATS預設的條件
1)伺服器TLS版本至少是1.2版本
2)連接加密只允許幾種先進的加密
3)證書必須使用SHA256或者更好的哈希演算法進行簽名,要麼是2048位或者更長的RSA密鑰,要麼就是256位或更長的ECC密鑰。
*/
AFSecurityPolicy,內部有三個重要的屬性,如下:
AFSSLPinningMode SSLPinningMode; //該屬性標明瞭AFSecurityPolicy是以何種方式來驗證
BOOL allowInvalidCertificates; //是否允許不信任的證書通過驗證,預設為NO
BOOL validatesDomainName; //是否驗證主機名,預設為YES
"AFSSLPinningMode"枚舉類型有三個值,分別是AFSSLPinningModeNone、AFSSLPinningModePublicKey、AFSSLPinningModeCertificate。
"AFSSLPinningModeNone"代表了AFSecurityPolicy不做更嚴格的驗證,"只要是系統信任的證書"就可以通過驗證,不過,它受到allowInvalidCertificates和validatesDomainName的影響;
"AFSSLPinningModePublicKey"是通過"比較證書當中公鑰(PublicKey)部分"來進行驗證,通過SecTrustCopyPublicKey方法獲取本地證書和伺服器證書,然後進行比較,如果有一個相同,則通過驗證,此方式主要適用於自建證書搭建的HTTPS伺服器和需要較高安全要求的驗證;
"AFSSLPinningModeCertificate"則是直接將本地的證書設置為信任的根證書,然後來進行判斷,並且比較本地證書的內容和伺服器證書內容是否相同,來進行二次判斷,此方式適用於較高安全要求的驗證。
如果HTTPS伺服器滿足ATS預設的條件,而且SSL證書是通過權威的CA機構認證過的,那麼什麼都不用做。如果上面的條件中有任何一個不成立,那麼都只能修改ATS配置。