AWS IoT Core, the certificate and how it works.
目錄
1. PKI
2. 信任鏈
3. 驗證機制
4. .pem
4-1 Arduino
5. 非對稱加密
5-1 加密 / 解密
5-2 簽名 / 驗證
⦿ PKI
⦿ 信任鏈
⦿ 驗證機制
⦿ .pem
⦿ Arduino
⦿ 非對稱加密
⦿ 加密 / 解密
⦿ 簽名 / 驗證PKI
PKI，Public Key Infrastructure，公鑰基礎架構，是一種用於創建、管理、分發、使用、儲存和撤銷數位證書的安全框架，將公鑰加密和數位簽名等技術與應用流程整合在一起。
包括兩個主要的部份：CA、RA。CA，Certificate Authority，證書授予機構；RA，Registration Authority，註冊機構。
在 AWS 上，當一個設備欲與 AWS IoT Core 藉 MQTT 協定溝通時，需滿足三項條件：root CA certificate、device certificate、private key。頂多再加一個 public key。
root certificate 與 device certificate 是兩個必備的憑證（證書），而 private key 及 public key 分別用來簽名與驗證。
certificate（憑證；證書）就是由 CA 頒發的，那為什麼一個設備還有分 root certificate 與 device certificate 呢？
下面我們來講講信任鏈。
繼續閱讀｜回目錄信任鏈
在非對稱加密（如 RSA）的應用，數位簽名中，公鑰（Public Key）是用來驗證簽名（Sign），而私鑰（Private Key）是用來簽名。
比方說，Alice 用他的私鑰來為欲傳遞的訊息加上簽名，有拿到 Alice 的公鑰的 Bob，用公鑰來驗證簽名，得到這是 Alice 傳遞出來的訊息的訊息，並確定訊息沒有遭到篡改。流程如下：
Alice、Alice’s private key => 發出簽名 => Bob、Alice’s public key => 驗證簽名
任何人持有公鑰都可用來驗證簽名，所以公鑰的傳遞就變得相當重要。假設今天有一個中間人 Charles 知道 Alice 的公鑰，那他可以驗證 Alice 的簽名，Charles 將自己的公鑰給 Bob，並讓 Bob 以為這是 Alice 的公鑰，這時 Charles 就可藉此發出與本來無關的簽名給 Bob，並讓 Bob 以為與他通話的是 Alice，流程如下：
A、A’s private key => 發出簽名 => C、A’s public key、C’s private key => 驗證簽名、發出假簽名 => B、C’s public key => 驗證假簽名
雖然都是發出簽名與驗證簽名，但這樣一來，Bob 拿到的卻是第三人傳遞出的無關或有害訊息，是謂中間人攻擊。為了避免在公鑰傳遞時發生此類狀況，可靠第三方機構因應而生，這個可靠第三方機構就是前述的 CA 了，你總不會找 Charles 幫你背書吧？我們可以直接看流程：
A、A’s private key => 發出簽名 => B、A’s public key => 驗證簽名
與本來並無不同，差別僅在於 private key、public key 是由 CA 幫忙產生，甚至傳遞。在 AWS 中，當你為 device 產生憑證，private key 跟 public key 都只能下載一次，接著保存就是你自己的事了。
在 certificate 裡面有什麼呢？我們看到如下：
- 憑證頒發者：是上層 CA，如果是 root CA，就是自己本身。
- 憑證持有者：ID 或名稱，如果是 root CA，就是自己本身。
- 憑證有效期限：有效期限通常會
小於等於上層證書的有效期限。 - 序號：證書的唯一標示符。
- 證書政策：該證書的操作權限。
- 公鑰
- 簽名：由上層 CA 的私鑰產生，如果是 root CA，就會用自己的私鑰產生，用以驗證憑證的完整性。
如果最上層的 CA 授權給下一層的 CA 去頒發憑證，最上層的 CA 我們叫 root CA，設備必須有 root CA 憑證（根憑證），而下一層 CA 頒發憑證給設備，這個憑證叫做 Intermediate 憑證（中間憑證）。
網路溝通時，會先去檢查設備的中間憑證，再往上檢查直到根憑證，如此才能確定是由對的設備發出的訊息。
這種證書驗證的機制就叫做信任鏈。
在 AWS IoT Core 中，若你沒有做其他操作，僅由 AWS 頒發憑證，這個 root CA certificate 的內容其實長一樣。
繼續閱讀｜回目錄驗證機制
device certificate 是如何產生的？當 AWS IoT Core 做為 root CA，它幫 device 產生的 public key 跟一些其他資訊使用自己（root CA）的 private key 來簽名，這些東西加在一起就成了憑證，即是 device certificate。
這時若 Alice 要傳遞公鑰給 Bob，就會將 device certificate 傳給 Bob，由於這個憑證是由 AWS IoT Core 用自己的 private key 產生的，在有 AWS IoT Core 的 public key 的情況下就可以用來驗證，但 Bob 有嗎？
有！因為這是 root CA certificate 中可得到的訊息！接下來，Bob 就確定了 Alice 的 public key。從此，Alice 跟 Bob 就可進行溝通。
但在 AWS IoT Core 裡，其實機制並不是這樣的⋯⋯。
Alice 傳遞訊息時，會將 Alice’s certificate、經 hash 運算的訊息用自己（Alice）的 private key 形成簽名一起傳出去，以 MQTT 協定與 AWS 溝通，AWS 收到後，使用 root public key（因當初是用 root private key 去形成 Alice’s certificate）驗證 Alice’s certificate，確定了裡面的 Alice’s public key，接著用 Alice’s public key 驗證簽名，再確定了這個訊息未經篡改且是由 Alice 發出的。
接著，AWS 再將訊息轉傳給 Bob，因為 MQTT 是雙向的，所以可以假定此時 Bob 已確認連接，便接收到原來自 Alice 的訊息了。
當然，你也可以這麼理解，AWS 將經 hash 運算的訊息用自己（root）的 private key 形成簽名傳給 Bob，Bob 用 root public key 驗證這個簽名，確定是由 AWS 傳來的。
繼續閱讀｜回目錄.pem
前面說過，設備在 AWS IoT Core 產生憑證後，需要下載的主要有三項：root CA certificate、device certificate 跟 private key。
這三個檔案的副檔名是 .pem，pem 檔是用來儲存金鑰或憑證的一種檔案格式，在 AWS 你可以看到檔案長成如下：
-----BEGIN RSA PRIVATE KEY-----
你的 private key 經 Base64 處理後的固定字串大小
-----END RSA PRIVATE KEY-----或是
-----BEGIN CERTIFICATE-----
你的憑證經 Base64 處理後的固定字串大小
-----END CERTIFICATE-----Arduino
而你在 Arduino 檔案中分別要放入的 root CA certificate、device certificate、private key，是以字串型別放入變數中，將會變得相當麻煩，參考如下：
const char* certificate_pem_crt = \
"-----BEGIN CERTIFICATE-----\n" \
"......\n" \
"glD0W5N+FUUrk4RxXbS6OWVLYYU1Nr0lK4+NnsTEPfjhvDEpnbTl3MhcLz9z0vZs\n" \
"......\n" \
"-----END RSA PRIVATE KEY-----\n";但其實還有一種較簡單的方式處理，如下：
const char certificate_pem_crt[] PROGMEM = R"KEY(
-----BEGIN CERTIFICATE-----
你的憑證經 Base64 處理後的固定字串大小
-----END CERTIFICATE-----繼續閱讀｜回目錄非對稱加密
這邊需要再提一下非對稱加密，非對稱加密是相對於對稱加密的，在對稱加密中，Alice 與 Bob 是使用相同金鑰來做加解密。
而非對稱加密的應用中，有兩種形式，一種是用做加密 / 解密，一種是用做簽名 / 驗證。
加密 / 解密：使用 public key 加密，使用 private key 解密。
簽名 / 驗證：使用 private key 簽名，使用 public key 驗證。
加密 / 解密
Alice 用 Bob 的 public key 加密訊息傳給 Bob，Bob 收到後，只有他有 private key 可以解開。
所以在這個應用場景中，適用於重要訊息的傳遞。但因為 Bob 的 public key 是公開的，所以 Bob 若想要知道是來自 Alice 的訊息就變得困難。
簽名 / 驗證
Alice 用自己的 private key 將訊息加上簽名傳給 Bob，Bob 收到後，用 Alice 的 public key 可以驗證是來自 Alice 的訊息，這即是這篇文章中說的機制。
所以在這個應用場景中，適用於訊息來源的確立。但因為訊息沒有加密，所以大家都可以知道訊息內容。
實際在使用上也可能會這麼做：
Alice 與 Bob 都有各自的 private key，且 Alice 與 Bob 都有對方的 public key。
Alice 用 Bob 的 public key 加密要傳出去的訊息，並以自己的 private key 加上簽名，最後傳給 Bob，Bob 用 Alice 的 public key 驗證訊息來源，再用自己的 private key 進行解密，得到既確認來源，又隱密的重要訊息。
是不是很有趣呢？
而我們也可以想想看，有了 root CA certificate 等於有了 root public key，在這種情況下，設備跟 AWS 溝通時也可加密訊息，保障訊息隱密性呢！
反過來，AWS 傳訊息給設備時也可用設備的 public key 加密訊息，設備拿到後再用自己的 private key 去解密。
這次就分享到這，感謝您的閱讀。
繼續閱讀｜回目錄