簽名相關的命令：
十余年的桑日網(wǎng)站建設經(jīng)驗，針對設計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。成都全網(wǎng)營銷的優(yōu)勢是能夠根據(jù)用戶設備顯示端的尺寸不同，自動調整桑日建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)公司從事“桑日網(wǎng)站設計”,“桑日網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。
?$security find-identity -v -p codesigning -- 列出鑰匙串里可簽名的證書
?$security cms -D -i embedded.mobileprovision -- 查看描述文件
?$codesign–fs “證書串” 文件名 -- 強制替換簽名
重簽步驟:
1.刪除插件和帶有插件的.app包（比如Watch）
2.對Frameworks里面的庫進行重簽名
3.給可執(zhí)行文件 +x（可執(zhí)行）權限
4.替換描述文件
5.替換BundleID
6.通過授權文件（Entilements）重簽.app包
實際操作：
獲取破殼的ipa包
獲取第三方ipa包
查看ipa包是否已經(jīng)破殼 》 非上架的都沒加殼，無需關注
解壓ipa包，進入playload文件夾，找到MachO文件
在終端使用命令otool -l DingTalk | grep crypt，0是已脫殼，大于0是未脫殼（一
般為1）
終端查看本地有效證書
$security find-identity -v -p codesigning
刪除無法簽名的插件文件
刪除Plugins文件夾和Watch文件夾
對.app文件夾內的Frameworks文件夾中的每一個framework強制重簽名
命令：$ codesign -fs "iPhone Developer: xxx " xxx.framework
找到framework文件夾下所有.framework，分別使用上面的命令對其簽名。
建議通過腳本命令執(zhí)行：
將要簽名的描述文件該成 embedded.mobileprovision 替換 來的 embedded.mobileprovision
創(chuàng)建entitlements.plist文件
查看描述文件內容，使用命令security cms -D -I embedded.mobileprovision，找到Entitlements節(jié)點，接著創(chuàng)建entitlements.plist文件，內容拷貝過去，最后把entitlements.plist文件拷貝到playload文件夾內（與xx.app同級）。
!]( )
修改xx.app包里面的info.plist中的bundleId為上面項目的bundleId
對xx.app開始簽名
使用的命令： zip –ry 輸出文件 輸入文件 命令。也可以手動壓縮。
將上述操作 通過shell命令 寫個腳本文件。然后一鍵操作。
shell腳本語言命令
地址：
蒲公英平臺重簽名
本文章主要介紹iOS 版本發(fā)布的兩個相關功能。
一 : iOS 開發(fā)出的版本發(fā)布安裝 用兩種方式 ：
軟件環(huán)境
Mac: v10.12.6 (16G29)
ruby: v2.3.4
rvm: v1.29.3
sigh: v2.71.1
Xcode: v9.2
使用sigh腳本
使用之前先安裝一下腳本環(huán)境
應用場景：
主要解決因重復打包導致測試同學回歸測試的包和上傳App Store的包不一致的問題。以及 合作方之間 證書不一致，需要重新簽名問題。
App開發(fā)測試流程
對回歸測試通過的ipa包進行重新簽名，然后上傳 App Store
輸入的 Signing Identity 如果和 .mobileprovision文件 不一致，那么終端上仍會提示resign成功，但是，安裝時會報錯！
codesign -vv -d xxx.app
本文主要講述sigh命令的安裝和使用。
首先確保你安裝了Xcode的命令行工具。
然后通過gem安裝sigh，gem的安裝請自行谷歌。
在終端執(zhí)行
依次執(zhí)行下列步驟：
關于更多sigh用法請訪問 sigh使用
簽名成功的應用就可以順利在我們的設備中安裝了并使用了，用這個方法可以進行非越獄平臺安裝在正版基礎移植的越獄應用。
工具：
借鑒：
iOS APP簽名機制詳解
保證安裝到用戶手機上的APP都是經(jīng)過 Apple官方允許的。
Mac設備有自己的公鑰和私鑰，Apple后臺充當CA機構，有自己的Apple私鑰，每一個iOS設備都有對應的App公鑰。
1.編譯項目，利用Mac的私鑰進行簽名，生成一個ipa包。
2.利用鑰匙串-證書助理-請求證書，生成Mac的公鑰，也就是Certificatesigningrequest.certsigningrequest文件，在蘋果官網(wǎng)，選擇創(chuàng)建相應的證書，將Mac的公鑰上傳，蘋果后臺會用私鑰進行簽名，生成證書，也就是ios_XXXX.cer文件。
3.將證書和app id，設備信息，權限等，用蘋果私鑰再次簽名，生成配置文件，也就是XXX.moblleprovision文件。
4.在安裝到手機的過程中，手機上的蘋果公鑰對XXX.mobileprovision進行驗證簽名。
5.XXX.mobileprovision驗證通過后會繼續(xù)對證書進行驗證簽名，獲取到Mac的公鑰。
6.利用Mac的公鑰，驗證ipa安裝包的簽名。
7.以上流程走完，就可以確定安裝到用戶手機上的APP都是經(jīng)過 Apple官方允許的。
1.簽名都是對散列值進行加密。
2.App Store的流程更簡單，蘋果對項目用蘋果私鑰簽名，手機用蘋果公鑰驗證簽名。
3.本文如有侵犯隱私或其他請聯(lián)系我，我將在第一時間整改或刪除。
iOS 應用的證書選擇
對于一個未上線 App Store 的應用，一般來說，開發(fā)者如果需要將應用安裝到某些用戶的設備上，就需要將應用導出為這些設備可以直接安裝的安裝包（.ipa文件），安裝包能否正確導出，是決定了應用能否被正確安裝到設備上的關鍵因素。其中，最關鍵的一個因素是，導出安裝包時，應用所使用的證書（即：簽名方式）。
開發(fā)者可以選擇如下兩種方式的證書簽名方式，來導出應用安裝包：
其中，具體使用哪種方式，取決于開發(fā)者擁有蘋果開發(fā)者賬號的類型。例如，如果開發(fā)者擁有的是蘋果個人開發(fā)者賬號，則可以使用 Ad-hoc 方式；如果擁有的是蘋果企業(yè)開發(fā)者賬號，則可以使用 In-house 方式。關于蘋果開發(fā)者賬號支持的證書類型，請見下表：
到目前為止，蘋果為 iOS 應用共提供了三種類型的證書簽名方式，每一種都有獨特的用途。這三種分別是：
蒲公英會根據(jù)打包證書的不同，分別顯示為 內測版 、 企業(yè)版 、 App-Store版 。
關于這三種類型的證書，區(qū)別如下表所示：
說到簽名機制，首先要了解一下 加密解密 ,簽名文件就是 加密解密 的過程。
加密 是將明文信息改變?yōu)殡y以讀取的密文內容，使之不可讀的過程。
解密 是通過特殊的對象，將密文還原為正?？勺x的內容的過程。而在這個過程中，我們所使用的方法，就是加密解密算法。
加密分為 對稱加密 與 非對稱加密（公開密鑰加密） 。
對稱加密就是加密和解密使用的都是同一套密鑰
常見的對稱密碼算法有：
如下圖，在使用對稱密碼時，一定會遇到密鑰配送問題， 假設，Alice將使用對稱密碼加密過的消息發(fā)給了Bob， 只有將密鑰發(fā)送給Bob，Bob才能完成解密， 在發(fā)送密鑰過程中，可能會被Eve竊取密鑰，最后Eve也能完成解密。
加密和解密使用的不是同一個密鑰，即為非對稱加密算法，也稱公開密鑰加密；
公鑰密碼中，密鑰分為加密密鑰、解密密鑰2種，它們并不是同一個密鑰， 公鑰密碼也被稱為非對稱密碼（Asymmetric Cryptography）
在公鑰密碼中：
加密密鑰 ，一般是公開的，因此該密鑰稱為 公鑰 （public key）
解密密鑰 ，由消息接收者自己保管的，不能公開，因此也稱為 私鑰 （private key） 公鑰和私鑰是一 一對應的，是不能單獨生成的，一對公鑰和密鑰統(tǒng)稱為密鑰對（key pair）
這樣就能 解決秘鑰配送的問題 了，如下圖：
上圖解析：
這其中如果有第三者竊聽，只有第2步和第4步能夠監(jiān)聽數(shù)據(jù)，由于Bob公鑰是公開的誰都可以獲取，那么第二步也不用擔心被誰獲取，第4步如果數(shù)據(jù)被第三者截獲，那么他看到的也是加密后的數(shù)據(jù)，由于他沒有Bob的私鑰，那么他也無法知道消息的真實內容。而且他即使篡改密文消息也無任何意義。
雖然非對稱加密解決了密鑰配送問題，但是它的加解密速度較慢，下面我們總結一下對稱和非對稱加密的優(yōu)缺點：
混合密碼 系統(tǒng)，是將對稱密碼和公鑰密碼的優(yōu)勢相結合的方法:
為本次通信隨機生成的臨時密鑰； 作為對稱密碼的密鑰，用于加密消息，提高速度
首先，消息發(fā)送者要擁有消息接收者的公鑰； 生成會話密鑰，作為對稱密碼的密鑰，加密消息； 用消息接收者的公鑰，加密會話密鑰； 將前2步生成的加密結果，一并發(fā)給消息接收者。
發(fā)送出去的內容包括
用會話密鑰加密的消息（加密方法：對稱密碼）
用公鑰加密的會話密鑰（加密方法：公鑰密碼）
1 消息接收者用自己的私鑰解密出會話密鑰
2 再用第1步解密出來的會話密鑰，解密消息
發(fā)送過程，加密過程
接收過程，解密過程
1.Bob利用自己的私鑰解密會話密鑰（使用的是公鑰密碼解密，也就是非對稱密碼解密）
2.Bob利用會話密鑰解密發(fā)送過來的消息（使用的是對稱密碼解密）
上面的加密算法解決了數(shù)據(jù)傳輸?shù)陌踩珕栴}，那么 數(shù)據(jù)的完整性 是沒法驗證的，就是我這個數(shù)據(jù)有沒有被改過，因為公鑰大家都能獲取，如果有中間人攔截了消息，并改動了內容。那么我們如何驗證這個 消息有沒有變動 呢?
單向散列函數(shù) ，又稱單向 Hash函數(shù) 、 雜湊函數(shù) ，就是把任意長的輸入消息串變化成 固定長的輸出串 且由輸出串難以得到輸入串的一種函數(shù)。這個輸出串稱為該消息的散列值。一般用于產生消息摘要，密鑰加密等
單向散列函數(shù)，可以根據(jù)根據(jù)消息內容計算出散列值 散列值的長度和消息的長度無關 ，無論消息是1bit、10M、100G，單向散列函數(shù)都會計算出 固定長度的散列值 。
單向散列函數(shù) ，又被稱為 消息摘要函數(shù) （message digest function），哈希函數(shù)輸出的散列值，也被稱為消息摘要（message digest）、指紋（fingerprint）
MD4、MD5 產生128bit的散列值，MD就是Message Digest的縮寫，目前已經(jīng)不安全 Mac終端上默認可以使用md5命令
SHA-1 產生160bit的散列值，目前已經(jīng)不安全
SHA-2 SHA-256、SHA-384、SHA-512，散列值長度分別是256bit、384bit、512bit
SHA-3 全新標準
不同的數(shù)據(jù)生成的散列值是不一樣的，只要你對一個文件改動過，那么它的散列值就會發(fā)生變化，要想確定我們的數(shù)據(jù)有沒有發(fā)生變化，只要對比兩次散列值相不相同就可以了，我們常常做的登錄功能，在保存用戶密碼的時候就采用單項散列函數(shù)生成的值來進行保存，防止第三方人員串改密碼。
數(shù)據(jù)防篡改的技術我們知道了，在數(shù)據(jù)傳輸?shù)倪^程中，我們對數(shù)據(jù)生成一個散列值，和發(fā)送的數(shù)據(jù)一并發(fā)給接收者，當接收者收到這個數(shù)據(jù)的時候，它拿接收到的數(shù)據(jù)重新生成散列值，然后跟接收到的散列值進行比較，就可以判斷這個數(shù)據(jù)有沒有被人改過。
到此我們通過混合密碼技術解決的傳輸數(shù)據(jù)的保密性，通過單項散列函數(shù)確定數(shù)據(jù)的一致性，但是還是沒有解決 中間人截獲篡改 的問題，因為散列函數(shù)中間人也可以重新生成一次，接下來我們就要講數(shù)字簽名了，他可以對消息發(fā)送者的真實性進行認證。
數(shù)字簽名 （又稱公鑰數(shù)字簽名）是只有信息的發(fā)送者才能產生的別人無法偽造的一段數(shù)字串，這段數(shù)字串同時也是對信息的發(fā)送者發(fā)送信息真實性的一個有效證明。
它是一種類似寫在紙上的普通的物理簽名，但是使用了公鑰加密領域的技術來實現(xiàn)的，用于鑒別數(shù)字信息的方法。一套數(shù)字簽名通常定義兩種互補的運算，一個用于簽名，另一個用于驗證。數(shù)字簽名是非對稱密鑰加密技術與數(shù)字摘要技術的應用。
說白了就是用用消息發(fā)送者的私鑰進行簽名就是數(shù)字簽名
在數(shù)字簽名中，任何人都可以使用公鑰驗證簽名
在數(shù)字簽名技術中，有以下2種行為:
生成簽名 由消息的發(fā)送者完成，通過“簽名密鑰”生成
驗證簽名 由消息的接收者完成，通過“驗證密鑰”驗證
數(shù)字簽名由于是消息發(fā)送者的私鑰進行簽名，消息發(fā)送者的私鑰只有他自己擁有，別人是沒有的，從而我們通過私鑰進行簽名，別人通過消息發(fā)送者的公鑰就能確定消息發(fā)送者的真實身份。
接下來我們看一下數(shù)字簽名和公鑰密碼的對比:
上圖Alice將要發(fā)送的消息用自己的私鑰加密，發(fā)送給Bob,Bob用Alice的公鑰解密消息，這里其實有一個不好的點，就是如果Alice如果發(fā)送的消息比較大，比如發(fā)1GB的視頻文件，那這個簽名過程就太慢了，本身非對稱加密的速度就是比較慢的，
下面我們來看一個改進版的:
這里我們將要發(fā)送的消息先生成固定大小的散列值，然后再簽名，這樣簽名文件就小的多了，然后我們將消息和簽名一同發(fā)送該Bob,然后Bob再用公鑰解密 對比等。
下面有關數(shù)字簽名的一些點進行一下說明：
1 如果有人篡改了文件內容或者簽名內容，會是什么結果？ 結果是：簽名驗證失敗，證明內容會篡改
2 數(shù)字簽名不能保證機密性？ 數(shù)字簽名的作用不是為了保證機密性，僅僅是為了能夠識別內容有沒有被篡改
3 數(shù)字簽名的作用
數(shù)字簽名是能確定消息發(fā)送者，前提是你要確定你獲取的公鑰是確定是消息發(fā)送者的，如果你拿到的公鑰是中間人偽造的，那么你就無法驗證消息發(fā)送者的真實性了，就如下圖：
[圖片上傳中...(image-b6d6e1-1614756605461-3)]
A問B要公鑰，M從監(jiān)聽到了中間，B給A發(fā)的公鑰被M攔截了并保存，M把他自己的公鑰給了A，A以為這個公鑰是B的，A用公鑰加密發(fā)消息給B，M攔截然后用自己的私鑰解密，修改消息內容后，然后用保存的公鑰加密把消息發(fā)送給B，B解密消息。A,和B都以為是正常通信的，但消息確實不是那個消息了，那么如何確定公鑰合法？也就是如何確定這個公鑰就是B的呢？
接下來就是我們要講的證書了，我們引入一個第三方權威機構來認正，說這個公鑰就是B的。接下來我們來看一下。
CA是證書的簽發(fā)機構，它是公鑰基礎設施（Public Key Infrastructure，PKI）的核心。CA是負責簽發(fā)證書、認證證書、管理已頒發(fā)證書的機關。
CA 擁有一個證書（內含公鑰和私鑰）。網(wǎng)上的公眾用戶通過驗證 CA 的簽字從而信任 CA ，任何人都可以得到 CA 的證書（含公鑰），用以驗證它所簽發(fā)的證書,密碼學中的證書，全稱叫公鑰證書（Public-key Certificate，PKC），跟駕駛證類似 里面有姓名、郵箱等個人信息，以及此人的公鑰； 并由認證機構（Certificate Authority，CA）施加數(shù)字簽名。
圖已經(jīng)表示的很清楚了，消息發(fā)送者先向CA機構 注冊自己的證書，那么任何拿到消息發(fā)送者的公鑰都可以向CA進行驗證公鑰的真實性。
首先我們要知道iOS簽名機制的作用是什么？
保證安裝到用戶手機上的APP都是經(jīng)過Apple官方允許的
不管是真機調試，還是發(fā)布APP，開發(fā)者都需要經(jīng)過一系列復雜的步驟：
大致如下圖：
[圖片上傳中...(image-169a4f-1614756605461-0)]
總結：
1、.cerSigningRequest文件 ： Mac公鑰
2、.cer文件：利用Apple私鑰（CA）,對Mac公鑰生成了數(shù)字簽名
3、.mobileprovision : 利用Apple私鑰，對【.cer證書 + devices + AppID + entitlements】進行數(shù)字簽名
蘋果簽名目前可以分為企業(yè)簽名、超級簽名、tf簽名。
企業(yè)簽名是使用蘋果企業(yè)證書，生成描述文件對應用進行簽名，用戶在安裝時只需要在【設置】-【描述文件】信任企業(yè)證書就可以安裝了，無需上架App Store。亥著五一活動，企業(yè)簽名500起。
超級簽名是使用個人開發(fā)者賬號，通過注冊蘋果設備的udid，來實現(xiàn)真機測試，用戶安裝時非常簡單，無需信任證書，直接安裝即可，無需上架App Store。
tf上架，在簽名商口中一般會稱呼為tf簽名，其實它全稱是testflight，是一種蘋果認可的分發(fā)模式，是蘋果官方的內測應用分發(fā)渠道。它是目前最穩(wěn)定的簽名方式，一經(jīng)上架基本不會掉簽，用戶可以一直使用。風險極小。
重慶分公司
重慶分公司
