ios簽名ios開發源碼

1. iOS中的簽名機制

說到簽名機制，首先要了解一下 加密解密 ,簽名文件就是 加密解密 的過程。

加密 是將明文信息改變為難以讀取的密文內容，使之不可讀的過程。

解密 是通過特殊的對象，將密文還原為正常可讀的內容的過程。而在這個過程中，我們所使用的方法，就是加密解密演算法。

加密分為 對稱加密 與 非對稱加密（公開密鑰加密） 。

對稱加密就是加密和解密使用的都是同一套密鑰

常見的對稱密碼演算法有：

如下圖，在使用對稱密碼時，一定會遇到密鑰配送問題， 假設，Alice將使用對稱密碼加密過的消息發給了Bob， 只有將密鑰發送給Bob，Bob才能完成解密， 在發送密鑰過程中，可能會被Eve竊取密鑰，最後Eve也能完成解密。

加密和解密使用的不是同一個密鑰，即為非對稱加密演算法，也稱公開密鑰加密；

公鑰密碼中，密鑰分為加密密鑰、解密密鑰2種，它們並不是同一個密鑰， 公鑰密碼也被稱為非對稱密碼銀虧（Asymmetric Cryptography）

在公鑰密碼中：

加密密鑰 ，一般是公開的，因此該密鑰稱為 公鑰 （public key）

解密密鑰 ，由消息接收者自己保管的，不能公開，因此也稱為 私鑰 （private key） 公鑰和私鑰是一 一對應的，是不能單獨生成的，一對公鑰和密鑰統稱為密鑰對（key pair）

這樣就能 解決秘鑰配送的問題 了，如下圖：

上圖解析：

這其中如果有第三者竊聽，只有第2步和第4步能夠監聽數據，由於Bob公鑰是公開的誰都可以獲取，那麼第二步也不用擔心被誰獲取，第4步如果數據被第三者截獲，那麼他看到的也是加密後的數據，由於他沒有Bob的私鑰，那麼他也無法知道消息的真實內容。而且他即使篡改密文消息也無任何意義。

雖然非對稱加密解決了密鑰配送問題，但是它的加解密速度較慢，下面我們總結一下對稱和非對稱加密的優缺點：

混合密碼 系統，是將對稱密碼和公鑰密碼的優勢相結合的方法:

為本次通信隨機生成的臨時密鑰； 作為對稱密碼的密鑰，用於加密消息，提高速度

首先，消息發送者要擁有消息接收者的公鑰； 生成會話密鑰，作為對稱密碼的密鑰，加密消息； 用消息接收者的公鑰，加密會話密鑰； 將前2步生成的加密結果，一並發給消息接收者。

發送出去的內容包括

用會話密鑰加密的消息（加密方法：對稱密碼）

用公鑰加密的謹搏吵會話密鑰（加密方法：公鑰密碼）

1 消息接收者用自己的私鑰解密出會話密鑰

2 再用第1步解密出來的會話密鑰，解密消息

發送過程，加密過程

接收過程，解密過程

1.Bob利用自己的私鑰解密會話密鑰（使用的是公鑰密碼解密，也就是非對稱密碼解密）

2.Bob利用會話密鑰解密發送過來的消息（使用的是對稱密碼解密）

上面的加密演算法解決了數據傳輸的安全問題，那麼 數據的完整性 是沒法驗證的，就是我這個數據有沒有被改過，因為公鑰大家都能獲取，如果有中間人攔截了消息，並改動了內容。那麼我們如何驗證這個 消息有沒有變動 呢?

單向散列函數 ，又稱單向 Hash函數 、 雜湊函數 ，就是把任意長的輸入消息串變化成 固定長的輸出串 且由輸出串難以得到輸入串的一種函數。這個輸出串稱為該消息的散列值。一般用於產生消息摘要，密鑰加密等

單向散列函數，可以根據根據消息內容計算出散列值 散列祥侍值的長度和消息的長度無關 ，無論消息是1bit、10M、100G，單向散列函數都會計算出 固定長度的散列值 。

單向散列函數 ，又被稱為 消息摘要函數 （message digest function），哈希函數輸出的散列值，也被稱為消息摘要（message digest）、指紋（fingerprint）

MD4、MD5 產生128bit的散列值，MD就是Message Digest的縮寫，目前已經不安全 Mac終端上默認可以使用md5命令

SHA-1 產生160bit的散列值，目前已經不安全

SHA-2 SHA-256、SHA-384、SHA-512，散列值長度分別是256bit、384bit、512bit

SHA-3 全新標准

不同的數據生成的散列值是不一樣的，只要你對一個文件改動過，那麼它的散列值就會發生變化，要想確定我們的數據有沒有發生變化，只要對比兩次散列值相不相同就可以了，我們常常做的登錄功能，在保存用戶密碼的時候就採用單項散列函數生成的值來進行保存，防止第三方人員串改密碼。

數據防篡改的技術我們知道了，在數據傳輸的過程中，我們對數據生成一個散列值，和發送的數據一並發給接收者，當接收者收到這個數據的時候，它拿接收到的數據重新生成散列值，然後跟接收到的散列值進行比較，就可以判斷這個數據有沒有被人改過。

到此我們通過混合密碼技術解決的傳輸數據的保密性，通過單項散列函數確定數據的一致性，但是還是沒有解決 中間人截獲篡改 的問題，因為散列函數中間人也可以重新生成一次，接下來我們就要講數字簽名了，他可以對消息發送者的真實性進行認證。

數字簽名 （又稱公鑰數字簽名）是只有信息的發送者才能產生的別人無法偽造的一段數字串，這段數字串同時也是對信息的發送者發送信息真實性的一個有效證明。

它是一種類似寫在紙上的普通的物理簽名，但是使用了公鑰加密領域的技術來實現的，用於鑒別數字信息的方法。一套數字簽名通常定義兩種互補的運算，一個用於簽名，另一個用於驗證。數字簽名是非對稱密鑰加密技術與數字摘要技術的應用。

說白了就是用用消息發送者的私鑰進行簽名就是數字簽名

在數字簽名中，任何人都可以使用公鑰驗證簽名

在數字簽名技術中，有以下2種行為:

生成簽名 由消息的發送者完成，通過「簽名密鑰」生成

驗證簽名 由消息的接收者完成，通過「驗證密鑰」驗證

數字簽名由於是消息發送者的私鑰進行簽名，消息發送者的私鑰只有他自己擁有，別人是沒有的，從而我們通過私鑰進行簽名，別人通過消息發送者的公鑰就能確定消息發送者的真實身份。

接下來我們看一下數字簽名和公鑰密碼的對比:

上圖Alice將要發送的消息用自己的私鑰加密，發送給Bob,Bob用Alice的公鑰解密消息，這里其實有一個不好的點，就是如果Alice如果發送的消息比較大，比如發1GB的視頻文件，那這個簽名過程就太慢了，本身非對稱加密的速度就是比較慢的，

下面我們來看一個改進版的:

這里我們將要發送的消息先生成固定大小的散列值，然後再簽名，這樣簽名文件就小的多了，然後我們將消息和簽名一同發送該Bob,然後Bob再用公鑰解密 對比等。

下面有關數字簽名的一些點進行一下說明：

1 如果有人篡改了文件內容或者簽名內容，會是什麼結果？ 結果是：簽名驗證失敗，證明內容會篡改

2 數字簽名不能保證機密性？ 數字簽名的作用不是為了保證機密性，僅僅是為了能夠識別內容有沒有被篡改

3 數字簽名的作用

數字簽名是能確定消息發送者，前提是你要確定你獲取的公鑰是確定是消息發送者的，如果你拿到的公鑰是中間人偽造的，那麼你就無法驗證消息發送者的真實性了，就如下圖：

[圖片上傳中...(image-b6d6e1-1614756605461-3)]

A問B要公鑰，M從監聽到了中間，B給A發的公鑰被M攔截了並保存，M把他自己的公鑰給了A，A以為這個公鑰是B的，A用公鑰加密發消息給B，M攔截然後用自己的私鑰解密，修改消息內容後，然後用保存的公鑰加密把消息發送給B，B解密消息。A,和B都以為是正常通信的，但消息確實不是那個消息了，那麼如何確定公鑰合法？也就是如何確定這個公鑰就是B的呢？

接下來就是我們要講的證書了，我們引入一個第三方權威機構來認正，說這個公鑰就是B的。接下來我們來看一下。

CA是證書的簽發機構，它是公鑰基礎設施（Public Key Infrastructure，PKI）的核心。CA是負責簽發證書、認證證書、管理已頒發證書的機關。

CA 擁有一個證書（內含公鑰和私鑰）。網上的公眾用戶通過驗證 CA 的簽字從而信任 CA ，任何人都可以得到 CA 的證書（含公鑰），用以驗證它所簽發的證書,密碼學中的證書，全稱叫公鑰證書（Public-key Certificate，PKC），跟駕駛證類似 裡面有姓名、郵箱等個人信息，以及此人的公鑰； 並由認證機構（Certificate Authority，CA）施加數字簽名。

圖已經表示的很清楚了，消息發送者先向CA機構 注冊自己的證書，那麼任何拿到消息發送者的公鑰都可以向CA進行驗證公鑰的真實性。

首先我們要知道iOS簽名機制的作用是什麼？

保證安裝到用戶手機上的APP都是經過Apple官方允許的

不管是真機調試，還是發布APP，開發者都需要經過一系列復雜的步驟：

大致如下圖：

[圖片上傳中...(image-169a4f-1614756605461-0)]

總結：

1、.cerSigningRequest文件 ： Mac公鑰

2、.cer文件：利用Apple私鑰（CA）,對Mac公鑰生成了數字簽名

3、.mobileprovision : 利用Apple私鑰，對【.cer證書 + devices + AppID + entitlements】進行數字簽名

2. ios簽名怎麼弄

ios簽名其實是對蘋果安裝包用企業號進行打包的一個過程，可以只提供IPA格式的安裝包進行簽名操作，也可以直接通過Xcode源碼進行打包，最後實現第三方應用的下載。

所有的人，都祝你快樂
廣告

可能有很多人會問了，蘋果簽名怎麼簽？可以自己簽名嗎？

蘋果簽名怎麼簽？

其實在iOS出來之前，在主流操作系統(Mac/Windows/Linux)上開發和運行軟體是不需要簽名的，因為軟體隨便從哪裡下載都能運行，導致平台對第三方軟體難以控制，盜版流行。蘋果希望解決這樣的問題，因此在iOS平台對第三方APP有絕對的控制權，一定要保證每一個安裝到iOS上的APP都是經過蘋果官方允許的。

而蘋果簽名的出現就是稍微打破了一下這種現狀：簡單的來說就是沒有上架appstore或者難以通過appstore審核的app，就會需要蘋果簽名這種形式，來讓用戶可以直接下載。

蘋果企業賬號(Apple Developer Enterprise Program)是蘋果公司提供給 iOS 開發者的一種高級別的開發者賬號，區別於個人開發者賬號和公司開發者賬號，企業賬號具有其他兩個賬號都無法比擬的優勢：可以將簽名後的應用在任何 iOS 設備上安裝，且沒有安裝數量的限制其中。

ios簽名可以自己簽嗎？

據了解ios簽名是不能自己簽，因為經過ios簽名的軟體是不能上架到App Store的，因此我們需要找專業的簽名服務商進行購買。

對於ios簽名很多公司或者個人很難區分什麼樣的蘋果簽名穩定，現在蘋果審核很嚴格，一般企業是不具備資格申請的，所以ios簽名證書很稀缺。

如果想要找到穩定的ios簽名， 首先需要擁有自己賬號的公司，這樣能保證使用證書是自己的，不是和別人共享，市場上很多人簽名證書都不是自己的，是朋友或者租來的，這時候如果你找這些人簽名，證書是無法保證會不會被刪除的。

3. 蘋果超級簽名源碼和蘋果企業簽名有什麼區別

首先來簡單介紹一下這兩種簽名方式的原理：

超級簽名是使用個人開發者賬號，自動化添加蘋果設備的udid，實現真機測試。

而企業簽名是使用企業開發者賬號，通過生成的p12證書，對應用進行簽名。

超級簽名與企業簽名的區別：

1、是否需要越獄？

這兩種簽名方式都無需越獄。

2、是否需要提供UDID？

對於用戶來說，這兩種簽名方式都不需要主動提供udid，超級簽名將獲取、注冊udid實現了全自動化，用戶直接安裝即可。

3、安裝之後是否需要信任

企業簽名的應用，用戶在安裝時需要先在【設置】-【描述文件】中信任證書。

而超級簽名無需信任證書，可以直接安裝。

4、穩定性如何，是否會掉簽？

超級簽名和企業簽名都有可能掉簽，不過企業簽名掉簽的頻率會多一點，尤其是共享企業簽名。

而超級簽名掉簽的幾率比較小，超級簽名更加穩定。

5、是否需要提供源碼？

兩種簽名方式都不要提供源碼。

6、能否在App Store上搜索到？

兩種簽名方式都不能在App Store上搜索到。

7、如何收費？

目前市面上的企業簽名一般按月收費，超級簽名是按照下載量收費。

8、兩種簽名方式分別適合什麼樣的APP？

超級簽名價格較貴，一般適合用戶數量不是很多的APP，而企業簽名一般對APP的類型和數量沒有限制。

超級簽名更加穩定，適合運營初期的APP，提高用戶體驗，提高用戶粘性，穩定忠實用戶。

微導流新版本正式上線，在線企業簽名

4. iOS 包簽名及重簽名

簽名相關的命令：
•$security find-identity -v -p codesigning -- 列出鑰匙串里可簽名的證書

•$security cms -D -i embedded.mobileprovision -- 查看描述文件

•$codesign–fs 「證書串」 文件名 -- 強制替換簽名

重簽步驟:
1.刪除插件和帶有插件的.app包（比如Watch）
2.對Frameworks裡面的庫進行重簽名
3.給可執行文件 +x（可執行）許可權
4.替換描述文件
5.替換BundleID
6.通過授權文件（Entilements）重簽.app包

實際操作：
獲取破殼的ipa包
獲取第三方ipa包
查看ipa包是否已經破殼 》 非上架的都沒加殼，無需關注
解壓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，分別使用上面的命令對其簽名。

建議通過腳本命令執行：

將要簽名的描述文件該成 embedded.mobileprovision 替換 來的 embedded.mobileprovision

創建entitlements.plist文件
查看描述文件內容，使用命令security cms -D -I embedded.mobileprovision，找到Entitlements節點，接著創建entitlements.plist文件，內容拷貝過去，最後把entitlements.plist文件拷貝到playload文件夾內（與xx.app同級）。
!]( https://upload-images.jianshu.io/upload_images/1502585-e1694c8e1e77a197.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240 )

修改xx.app包裡面的info.plist中的bundleId為上面項目的bundleId

對xx.app開始簽名
使用的命令： zip –ry 輸出文件 輸入文件 命令。也可以手動壓縮。

將上述操作 通過shell命令 寫個腳本文件。然後一鍵操作。
shell腳本語言命令

地址： https://github.com/InjoyDeng/ResignTool

蒲公英平台重簽名

本文章主要介紹iOS 版本發布的兩個相關功能。

一 : iOS 開發出的版本發布安裝 用兩種方式 ：

軟體環境
Mac: v10.12.6 (16G29)
ruby: v2.3.4
rvm: v1.29.3
sigh: v2.71.1
Xcode: v9.2

使用sigh腳本
使用之前先安裝一下腳本環境

應用場景：
主要解決因重復打包導致測試同學回歸測試的包和上傳App Store的包不一致的問題。以及 合作方之間 證書不一致，需要重新簽名問題。

App開發測試流程

對回歸測試通過的ipa包進行重新簽名，然後上傳 App Store

輸入的 Signing Identity 如果和 .mobileprovision文件 不一致，那麼終端上仍會提示resign成功，但是，安裝時會報錯！

codesign -vv -d xxx.app

本文主要講述sigh命令的安裝和使用。

首先確保你安裝了Xcode的命令行工具。

然後通過gem安裝sigh，gem的安裝請自行谷歌。

在終端執行

依次執行下列步驟：

關於更多sigh用法請訪問 sigh使用

簽名成功的應用就可以順利在我們的設備中安裝了並使用了，用這個方法可以進行非越獄平台安裝在正版基礎移植的越獄應用。

工具： https://github.com/InjoyDeng/ResignTool
借鑒： https://www.jianshu.com/p/d68924e1af25

https://www.jianshu.com/p/d68924e1af25
https://www.cnblogs.com/guohai-stronger/p/11781249.html

iOS APP簽名機制詳解