原標《P20 - 你有聽過密碼學嗎？》

文/資安解壓縮

Podcast 連結

• Apple Podcast
• Spotify Podcast
• Firstory Podcast

本集內容大綱

前情提要

密碼學所討論的密碼和 EP3 - 設定密碼好複雜！中提到的用來驗證身份的密碼不同。

• 驗證身份的密碼：Password，使用者在登入時輸入已證明身份的密碼，安全性主要依賴密碼本身的長度和複雜度
• 密碼學所討論的密碼：Key 金鑰，用來加密和解密用的，長度通常較長，安全性除了依賴密碼的長度外，也大大取決於加密演算法。

密碼學

概念： 把一些資訊透過特定方式隱藏，讓這些資訊無法輕易的被外人解讀。
歷史：

• 500BC：斯巴達在打仗時不希望作戰計劃暴露給敵人，就在一條很長的紙上寫了一串字母，如果想讀取訊息，就要把紙條纏在一個特定大小的棍子上，才能拼出有意義的句子。 如下圖

• 490BC：古希臘人會將機密訊息刺在奴隸頭上，頭髮長出來時機密的訊息就會被蓋住，如果要看訊息再把奴隸的頭髮剃掉。
• 15 世紀：李奧納多•達文西的部分手稿就是利用鏡像文字左右相反的特性書寫，解讀時也就需要透過鏡子才能解讀。下圖為達文西的手稿

現代：PTT 看到的藏頭詩

這些依靠物理工具來達成的加密方法，雖然只能算是密碼學的皮毛，只是將資料很簡單的隱藏起來而已，並沒有將資料變得無法辨識，破解上並不需要花費太多力氣。

加密演算法

過一個金鑰和一些數學公式，讓原本的資料變得無法辨識，這樣即使資料被駭客取得了，也無法知道原本的內容是什麼，要復原的話就只能使用加密時使用的金鑰配合對應的數學公式解密。 元素：

• 明文：想保護而還沒加密的資料
• 密文：加密後無法辨識的資料
• 演算法：將資料加密或解密的方法
• 金鑰：與演算法配合，讓密文無法被他人解密的關鍵

混淆 Confusion ＆ 擴散 Diffusion

加密演算法主要會希望達到這兩個目的，做到這兩底才能確保密文在公開的情況下，攻擊者也無法知道我們使用的金鑰和明文。

• 混淆 Confusion：減少密文和金鑰間的關聯性，讓別人無法直接或間接地從密文中推敲出使用的金鑰、破解密文。
• 擴散 Diffusion：減少明文和密文間的關聯性，也就是說當明文中一個字母被更改，密文也應該要大幅度的改變，而不是也跟著只改變一個字母，才能避免攻擊者透過分析密文的變化進而找出規律推敲出明文。

替換式密碼 Substitution Cipher

加密演算法的兩種基礎加密方式的其中之一。
將明文中的每個字母替換成其他東西，讓明文看起來像是無意義的亂碼

• Ａ換成Ｂ，Ｂ換成Ｃ ⋯ Ｚ換成Ａ（金鑰為 1）

  • APPLE → BQQMF

• Ａ換成Ｃ，Ｂ換成Ｄ ⋯ Ｚ換成Ｂ（金鑰為 2）

  • APPLE → CRRNG

• Ａ換成Ｚ，Ｂ換成Ａ ⋯ Ｚ換成Ｙ（金鑰為 25）

  • APPLE → ZOOKD

豬圈密碼/共季會密碼 Pigpen Cipher

破解方式

分析每個字母出現的次數
在英文中，雖然有 26 個字母，但不是每個字母都會很平均的出現在句子和文章中，像母音的ＡＥＩＯＵ出現的機率就很高，相對的Ｘ、Ｚ等字母出現機率就很低。
出現的機率是最高的是Ｅ(13%)，遠高於平均的 3%。出現機率最低的則是Ｚ(0.074%)。 Wikipedia - Alphabet Frequency

透過這種特性，只要去統計加密後的密文中各個字母或符號出現的機率，再拿他去比對英文中各個字母出現的機率，就可以推敲出加密前的明文了。

換位式密碼 Transposition Cipher

加密演算法的兩種基礎加密方式的其中之二。
這個做法不會更改資料本身，但會依照規律改變資料的排列順序。

• 將奇數為字母拿到最前面，偶數為字母拿到後面

  • HELLO → HLOEL （順序從 12345 → 13524）

• 用金鑰的字母順序作為每列換位的順序

進階的加密演算法

替換式密碼和換位密碼單獨來看都很基本，實際應用上在安全性也不是很足夠，但兩者都是密碼學上很重要的基礎，很多安全的加密演算法都是由不同種類的替換式密碼和換位密碼組合而成。
美國聯邦政府在 1976 年列為資料處理標準的加密演算法 DES（資料加密標準 Data Encryption Standard）就是結合了好幾種替換式密碼和換位密碼所組成的。
DES 中使用了一組 56 位元的金鑰將資料進行 16 輪的替換和換位來讓演算法夠安全。
DES 已經在 1997 年被破解了，現在取代 DES 的是進階加密標準 AES。

DES 的筆記會放在本篇文章的最後供大家參考。

加密演算法的安全性

考慮不同的情境

• 攻擊者只知道密文
• 攻擊者知道明文
• 攻擊者猜的到明文
• 攻擊者可以自由選擇明文
• 攻擊者可以自由選擇密文

如果攻擊者都已經知道明文了，加密方法安全性還需要考慮嗎？

加密演算法跟金鑰通常都不會只使用一次，當我們跟同一個對象在傳遞訊息時往往會重複使用同一組金鑰。 攻擊者知道明文的情況，可能就會發生在攻擊者獲取了對話中某些未加密的片段，如果攻擊者在這種情況下可以破解所使用的加密演算法和金鑰的話，就能破解過去和未來所傳遞的所有訊息。
所以最理想的情況是不管攻擊者知道多少訊息，只要不知道金鑰，都不能破解訊息，這樣才會認定這個加密方法是夠安全的。

抵禦暴力破解法

複習：什麼是暴力破解法？

以破解 DES 為例

DES 使用的是 56 位元的金鑰，每一位元可能是 1 或是 0 ，因此金鑰的可能性有 2 的 56 次方，也就是 7 千兆。
理論上如果我們使用一台蘋果的 Macbook Pro 來進行破解的話只要花 185 天就可以破解了，同時使用多台電腦或是用一些專門設計來破解用的電腦的話時間就會大幅縮短。 假設的條件和計算式：

• 假設在 500MHz 的情況下，每個時脈週期可以進行一次解密
• 確認一組金鑰所需要的時間：1/(500 x 10^6)秒
• Macbook Pro 處理器最高可達 4.5GHz
• 要確認 2^56 組密碼鎖需要花的時間：2^56/(4500 x 10^6)秒 = 185 天 (計算)

但如果是在相同的情況下要破解取代 DES，使用標準 256 位元金鑰的進階加密標準 AES 的話，需要的時間就會是 8x10^59 年（計算），簡單來說就是不可能被暴力破解。

在 DES 被發明的 1976 年，那時個人電腦還沒普及，每台電腦的效能也很差，因此在當時 DES 是一個安全的選擇，但拿到 44 年後的現在，因為科技的進步，電腦效能已經比以前好太多了，因此在現今科技底下 DES 是不夠安全的。

相同的道理也適用其他所有的加密演算法上，現在是安全的加密方法也會因為未來科技的進步，而變得能在短時間內被暴力破解法破解。

加密法是否被正確實踐

加密演算法安不安全還有一個很重要的點就是，我們是不是有正確的將他透過程式實現出來。
很多時候一個加密演算法本身以及他背後的數學原理是十分安全的，但程式設計師在將這個演算法轉換為軟體中可以運行的程式時會有邏輯上的瑕疵或是漏洞，導致這個加密方法無法被安全的實現。
我研究所時的密碼學教授就告訴我們永遠不要自己寫自己的加密演算法，因為自己寫的加密演算法一定都會多少有一點問題或是漏洞。
現在主流使用的加密演算法函式庫都是經過許多密碼學博士或是專家的測試和檢驗才確保安全的。

密碼學是一個很重要的工具，但密碼學也不是萬靈丹，在資安領域中除了有密碼學來幫我們加密資料以外也需要很多其他的工具的輔助。

加密解密小測驗

題目一： 找出下圖透過豬圈密碼所加密的訊息

題目二： 找出以下透過換位式密碼加密的訊息
金鑰：INFOSEC
密文：NRPPOCO NEICHCK

答案會在本文的最後

DES 資料加密標準 Data Encryption Standard 原理

加密解密小測驗 - 解答

題目一解答：Security is Important

題目二解答：Popcorn Chicken （PS. Popcorn Chicken 是鹽酥雞的英文）

※本文由 資安解壓縮 授權勿任意轉載，原文《EP20 - 你有聽過密碼學嗎？》

[elementor-template id="118812"]

這篇文章 【學長姊帶路】你有聽過密碼學嗎？ 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

原標《密碼學與資訊安全 — 學習筆記之一》

文/Brady Huang

開發者是不是資訊安全的敵人？

最近在旁聽台大密碼學與資訊安全的課程，課程規定要看 10 篇指定文獻並撰寫心得，以此當作修課成績的其中一個評分指標，但是因為我是旁聽生，我沒辦法交作業，於是我決定把自己作業的報告寫在 Medium，一方面是統整上課重點，另一方面這週讀的文獻分享出來，因為讀完一篇以後覺得其實內容還蠻實用也不會太艱澀難懂，其實當作故事聽一聽還蠻有趣的，但如果要直接看文獻，用字有些還是蠻艱澀的，所以很多小細節我都會刪除。

The Developer is the Enemy

要解決的問題

一直以來，資安一直都是軟體開發 (Application Development) 相當重要的一環，之前，我們會對顧客行為做分析，這是因為他們把使用者 (user) 當作是資安問題的始作俑者，但是，我們覺得開發者 (developer) 才是資安問題需要解決的對象。

軟體使用流程可以分成三個角色，API (Application Programming Interface)開發者、App 開發者和使用者，現在的 App 開發者主要的任務就是把 API 提供的功能組裝起來，但是開發者不一定有資安相關的知識，因此，在使用 API 的同時，卻沒有辦法判別要選擇哪一種 API 會是比較安全的 (像是 AES 的加密模式)，而且有些 API 文件並沒有寫得很清楚，所以我們想，如果把資安這份功能，移到 API 開發者上，是不是就解決了這個問題？

這問題有很重要嗎？

安全性的問題是一定要解決的，但是 App 開發者通常不了解資安的問題，這邊舉 4 個例子。

1. 要求新的 API 功能但是卻降低了安全性
   有些開發者會要求取消 same-origin policy*，以用來跨網域存取資源，但卻降低了安全性。
2. 選擇易用的套件和語言
   常常在開發需求下，選擇好懂的或快速使用的套件跟語言，卻忽略安全性這一塊。
3. 工作優先
   在編譯的時候，通常為了把事情做完，而忽略或取消編譯工具提供的安全警告訊息。
4. 不做弱點分析
   花時間開發新功能跟花時間做弱點分析，App 開發者會直接忽略弱點分析這塊。

*same-origin policy 是指如果我想要跟後端要取資源，如果我們不是同個網域的話是不能存取的，也就是說，如果我的網域是 www.brady.com 是不能存取 www.paul.com 的資源，但是 www.brady.com/users 或是 www.brady.com/posts 是可以的。

提供的兩個稻草人*想法

1. 資料標記(Data Tagging)
   通常一個套件的 API 如果要考量到所有的情況，這個 API 可能會太過肥大，而且使用者可能不需要這麼多功能，所有如果我們把資料處理的時候，會附帶一些 tag 來註記這些資料需要的處理，舉例來說，有一些 template engine 會處理後端傳出來的資料，如果這個資料是需要自動轉譯 (autoescape )的，就會帶一個 escapehtml 的 tag。
2. 不可壓制的警告訊息(Unsuppressible Warnings)
   有些編譯器的安全警告訊息不應該要被壓制，我們建議可以把他改成 error 或者讓編譯器不會讓他執行來嚴格建立安全性機制。

*稻草人(straw-man)解法是指我把問題簡化或轉變成另一個問題，讓回答者更好回答或是反駁，有正面或負面的使用方式，這邊是正面的提出可能可以的解法。

結論

因為 App 開發者是負責 API 的組裝和呈現，關於資安的問題我們應該從更高層面下手，因為 App 開發者大部分不是資安專家，也就是說如果我們從基礎核心的 API 層面下手去解決資安的問題的話，可以把資安責任從 App 開發者中抽除，這樣不只可以降低 App 開發者的資安教育成本，也可以讓他們更專一的解決自己工作上需要處理的事情。

心得

這篇文章不得不說到我的感觸，因為我本身是功能傾向的開發者，有時候資安的問題是一個長期的效應，沒有辦法馬上給予開發者短期回饋，而我也不是資安專家，對於每一個功能需求背後的安全性並沒有直覺的了解，因此很容易忽略了資安的重要性。其中有一個質疑的點就是有些 API 開發者其實是 App 開發者來做的，也就是說如果 API 開發者自己也沒有資安觀念的話，其實做出來的 API 也是沒什麼安全性，但是文章中有提到他只會對很核心很通用的 API 進行增強，我認為如果由資安專家做個套件讓 API 開發者可以直接插入的話，就可以省下 API 開發者的負擔。

G. Wurster and P. C. van Oorschot, “The developer is the enemy,” in workshop on New security paradigms, 2008. & M. Green and M. Smith

Developers Are Not The Enemy! The need for usable security APIs

這篇的立場跟 The Developer is the Enemy 的立場是一樣的，都是希望把資安的責任分層往 API 端放，只是上一篇是希望大家以資安實踐面心態上去想，把責任放在 API 端會比較好，畢竟開發者有可能就是破壞資安的人！而這篇的想法是以資安心態來說，其實開發者不想把損害系統，但是有時候因為粗心和缺乏相關知識而犯了跟使用者一樣的錯誤，是另外一篇文獻 Users are not the enemy 的延續。

要解決的問題

想要解決因為 App 開發者的資安知識缺乏而造成的系統漏洞，根據文獻發現，開發者在遇到一個資安問題的時候，其實跟使用者一樣不知所措或不明就裡，造成了資安問題的產生。

這問題有很重要嗎？

有很多發布的應用程式雖然有使用加密套件，但是並沒有正確使用，造成系統 DoS (Denial of Service)或資安漏洞，非正確使用的例子像是

1. 沒使用 TLS 認證
   正常的情況會使用 TLS (Transport Layer Security) 協定來確保網站和後端服務的網路連線安全，TLS 是藉由認證來確保對方程式安全，然而大部分的應用程式並沒有通過認證，或是自己產生 TLS 驗證。
2. 使用不安全的加密模式
   有些加密模式是已經知道不安全了，但是因為缺乏相關知識，造成資訊外洩。
3. 使用不安全的隨機數字產生器
   通常要產生安全協定的時候，都會需要產生隨機號碼產生器，然而不是經過資訊安全-隨機產生碼是可能會有問題的。

提供加密 (crypto) API 的 10 個想法

1. 直接整合加密 API 到標準 API，讓使用者不需要直接面對資安問題
2. 盡量滿足有安全需求和沒需要安全需求的兩種 API
3. 就算沒有資安背景也可以理解 API 的功用
4. 不要讓開發者覺得 API 參數跟之前矛盾
5. 就算沒有文件也可以很好理解
6. 如果錯誤使用 API 會有明顯的錯誤警告
7. 如果有預設值應該是安全的而且不能模稜兩可
8. 測試環境如果要發佈時應該要警告
9. 開發者的維護成本低
10. 要給開發者建議錯誤發生如何解決問題

結論

此篇文獻跟上一篇站在相同立場，並提出更多明確的 10 個方法希望資安領域的人應該要如果去解決和時間現在軟體領域遇到的問題。

心得

我覺得這篇比上一片容易看多了，用字比較淺顯易懂，他的想法也合理，把資安問題往更高層面去解決，然而怎麼去驗證或統一全部的 API 讓他們擁有資安相關的防範還是需要蠻多心力的。

Green and M. Smith, “Developers are Not the Enemy! The Need for Usable Security APIs,” IEEE Secur. Priv., vol. 14, no. 5, pp. 40–46, 2016.

※本文由 Brady Huang 授權勿任意轉載，原文《密碼學與資訊安全 — 學習筆記之一》

___________

你也有經驗想分享嗎？快來投稿賺稿費吧！

[elementor-template id="118812"]

這篇文章 【學長姊帶路】密碼學與資訊安全 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。