想問兩個問題:
1.遭遇Rootkit透過Ring0~3 hook方式竊取streaming串流未加密的明文
嘗試還原加密檔案有可否得逞(其對抗的方式為何)?

2.遭遇Rootkit利用虛擬或欺騙技術來模擬解密軟體的行為對機密檔進行取得與解密
嘗試還原加密檔案有可否得逞(其對抗的方式為何)?

To 21F,
採用週邊、網路實體隔離圍堵的措施，造成如下的問題：
1. 因為會「改變使用者的習慣」，與「犧牲電腦的使用功能」，是造成研發人員怨聲載道的主要原因。
2. 研發人員也無法帶回家加班。
3. 暫時需要於內網以外的研發資料仍舊造成資料外洩的漏洞。
實體隔離圍堵是過度期的措施，勢所難免終將被淘汰。

這個議題的最經濟解還是實體隔離吧？
這就是citrix、jetro cockpit、vnc或thin client很難賣但還是不會消滅的原因吧？
跟你細軟想放在保險箱裡一樣，外人看看可以，拿走不行。

To 19F,
>> 有什麼機制防止專門針對此系統的木馬假冒人類操作者來設定木馬本身為「受保護」的應用軟體？這個質疑是合理的，因為系統是在明處，木馬在暗處，真要保護珍貴資料，就要做此假設（會有有心人花合理代價來偷）。當木馬可以進入執行電腦，就已經變成了基本的 No physical security, no security。即使真實人類的操者者要輸入密碼才可以設定，木馬也可能常駐竊取鍵盤 keystroke，是否也要像網銀一樣用隨機畫面鍵盤？

=> 資料外洩防護系統的伺服器負責設定那些為「受保護」的應用軟體,而用戶端電腦才有受保護的加密檔案, 若要設計針對此系統的木馬需要於伺服器與用戶端同時植入木馬, 且需要對伺服器的規劃設定十分熟悉, 這是非常困難的, 除非是負責規劃設定伺服器的人才有辦法, 負責規劃伺服器的人要偷東西只要自己於伺服器設定一下就可以了, 不需要大費周章設計木馬程式, 就像管保險箱鑰匙的人, 是不好防範的.
另外資料外洩防護系統, 我們也提供了需要插一個 USB key 才能解密的保護功能, 這對木馬程式而言, 難度更高.
因此破解的機會, 是非常低的.

我從您的回應的理解是這個系統用設定來讓安全軟體辨識哪些軟體可以放行。可是您仍然沒有回答我的疑問，有什麼機制防止專門針對此系統的木馬假冒人類操作者來設定木馬本身為「受保護」的應用軟體？這個質疑是合理的，因為系統是在明處，木馬在暗處，真要保護珍貴資料，就要做此假設（會有有心人花合理代價來偷）。當木馬可以進入執行電腦，就已經變成了基本的 No physical security, no security。即使真實人類的操者者要輸入密碼才可以設定，木馬也可能常駐竊取鍵盤 keystroke，是否也要像網銀一樣用隨機畫面鍵盤？事實上，針對有價值資料所設計的木馬，要做 mouse event/screen capture 都不是不可能。這一切都如同銀行保險箱室一樣，要設計到多銅牆鐵壁，端視要保護的寶藏有多珍貴。內外網加USB 禁用說實在的除了有心內部人不能防之外，所有上述問題都不用擔心，除了方便性之外，我覺得還是需要更明確的理論來證明機制的安全。我用一個極端抽象例子來說明我的疑問，有個特制木馬，一進入系統，就負責把整個硬碟 image 往駭客傳遞，供駭客重製整個操作環境，然後駭客就可以如正常使用者一樣登入（登入密碼的 keystroke 已被側錄，連破解都免了）。請問有什麼理論可以證明此系統仍防止這個情境？

看來這個文章點到大家資料外洩防護的「痛處」，感謝大家熱烈的討論。

首先說明一下，防止「copy and paste」的機制是「單向」的：
1.「受保護」的應用軟體（譬如 Visual Studio、AutoCAD 等）之檔案開啟後，不能複製到其他「未保護」應用軟體（譬如 Outlook、Notepad 等）。
2. 所有其他應用軟體的資料都可以複製到保護應用軟體所開啟的檔案。

「保護」的機制是這樣子的：
1.「受保護」的應用軟體，於儲存所有格式的檔案時會自動被加密保護。
2.「受保護」的應用軟體，於開啟所有格式的加密檔案時會自動被解密。
一個「受保護」應用軟體的「檔案格式」也可設定。

請容筆者一併回覆所有的問題。

To 6F：
>> 如果user想從其它的地方copy資料進來，該段被copy的資料必定暫存於clip board。而在該特制軟體中進行copy，則被copy的資料將暫存於內部的記憶體。
當clip board與內部記憶體都有資料時，怎麼知道user想要pastes是clip board的資料，或是內部記憶體的資料?

=> 依照是「受保護」或者是「未保護」的應用軟體來判斷是否允許「copy and paste」的行為，與「clip board/內部記憶體」無關。

To 7F，15F：
>> 病毒（或木馬）開啟檔案時，是否也會自動解密？
>> 我的疑問就在病毒木馬也是上層 AP，它們也讀得到真實資料。

=> 病毒（或木馬）不是「受保護」的應用軟體，無法對已經被加密的檔案進行自動解密的動作，因此採用「即時讀寫加解密」技術所開發出來的資料外洩防護產品，可以解決病毒（或木馬）偷機密資料的問題。

To 8F：
>> 我認為要做到高度的防堵很困難，要花很多的資源，所以我們公司只做簡單的防堵。只有內外網切開，主要防范外來的侵入，資料外漏是非常難制止的。

=> 採用「即時讀寫加解密」技術所開發出來的資料外洩防護產品，可以做到高度的防堵。
將內外網切開會產生文章所說的問題：首先是員工因該種作法會改變其的電腦使用習慣，以及犧牲電腦的部分使用功能，因而產生怨聲載道、甚至是開始鑽小漏洞、或者是罷用。員工無法在內網電腦以外的地方處理工作，且不可能將內網電腦帶回家。

To 9F，12F：
>> A軟體會使用A，B，C三個軟體的公鑰進行加密運算。而這個加過密的檔案除了使用A，B或C的私鑰，否則無法解密。假如D軟體意圖開啟該檔案，因為它沒有A，B，或C的私鑰，而無法順利還原該檔。
>> 軟體需要配合提供私鑰，那是否客戶所有的套裝軟體都要 patch？沒有 source code 的怎麼做？

=> 這個方法很好，但是不好管理個別的私鑰（一般是放到檔案的檔頭位置），或者第一次解密要連線到 Server。我的經驗是使用上述的「保護」的機制，加解密都可以「離線作業」的，即可防止病毒或木馬假冒其它軟體來盜取機密檔案，與個別的私鑰無關。

To 10F、17F：
>> 我是用java，所以工程師習慣用notepad 或其他簡單的text editors。在不同editors間 Copy and paste 是非常普遍的動作。所以請問'即時讀寫加解密'可以把copy and paste在notepad 或其他editor disable 嗎? 否則，如果'即時讀寫加解密'要求工程師用特定的editor，我害怕會遇到滿大的抗拒…
>> 但軟體工程師用的工具都是如notepad等普通文字editor哦。怎麼可以禁止他們用呢。反彈會很大的，也影響了使用者工作習慣。還是如14樓說的，要用特定的工具或修改工具source code配合? 但這樣導入的瓶頸就很大了。

=> 若是使用程式開發工具的話，就把程式開發工具指定為「受保護」的應用軟體。
程式開發工具為 editor，那解決方法是只好將常用的 editor 都指定為「受保護」的應用軟體了。

To 11F：
如果他有辦法copy至notepad或習慣用的editor，除非在notepad 或text editor不容許copy and paste，否則他就可以在notepad 再copy 一次，以純文字方式paste去outlook。

=> 將常用的 editor 都指定為「受保護」的應用軟體，就無法 paste到 Outlook。

To 13F：
>> 如依作者所舉的例子，需要進行加解密的 AP 很有限，不是繪圖軟體，就是程式編輯器…如果只修改這一兩套軟體來 support 加解密的過程，我認為可行性其實不低…

=> 採用「即時讀寫加解密」技術所開發出來的資料外洩防護產品可以支援所有的應用軟體，不需要額外的專案開發。

To 14：
>> 如果是每個軟體都要修改 source code 來配合，那幾乎是無解，有多少軟體要請原廠配合修改，有可能嗎？光 Office 就有多少版本？不用提其他各領域專屬軟體。

=> 採用「即時讀寫加解密」技術就不需要修改任何的應用軟體，也不需為任何的應用軟體或任何版本設計任何專用的 plug-in。

To 16F：
>> 本文主旨在討論避免A員工洩漏自己的工作秘密，而非B員工竊取A員工的工作秘密。因此，我不認為這套系統使用針對人的加解密機制。

=> 採用「即時讀寫加解密」技術可以設定 A 員工，與 B 員工的權限是不一樣的。

一口氣回覆十幾個問題，若有遺漏之處，請見諒了。

>> To 11F:
>> 依作者在5F的回應, 被 copy 的資料並不會放入 clip board, 如此 notepad 將無法取得被
>> copy 的資料, 也就不會有貼到outlook的問題.

但軟體工程師用的工具都是如notepad等普通文字editor哦. 怎麼可以禁止他們用呢. 反彈會很大的, 也影響了使用者工作習慣. 還是如14樓說的, 要用特定的工具或修改工具source code配合? 但這樣導入的瓶頸就很大了.

iKey的概念是針對人, 是用來避免A員工的資料被B員工偷取, 因B員工沒有A員工的iKey (內含私鑰).
但這套機制, 完全無法防範A員工自己的洩密行為, 因為他擁有自己私鑰的控制權.

本文主旨在討論避免A員工洩漏自己的工作密秘, 而非B員工竊取A員工的工作密秘.
因此, 我不認為這套系統使用針對人的加解密機制.
我認為它要防範內賊, 則必然不是用以人為主體的加解密機制.
應是以AP為主體的加解密機制, 方能確實防止密秘資訊出現在不當的軟體(如 Outlook), 進而洩漏.

我推測本文所提系統，可能要先由使用者在登入時插入私有金鑰之類的 USB 隨身碟，然後作業系統會即時讀檔解密，寫檔加密。這個概念在分層系統很普遍，如 SSL 一樣，一般的上層 AP 可以完全不管有沒有 SSL 加密。SSL 作法是傳輪安全，不怕被監聽，而即時加解密不怕硬碟被拔走，或 row partition sector-by-sector 複製，但對 OS 內執行的上層 AP 提供透通性。但我的疑問就在病毒木馬也是上層 AP，它們也讀得到真實資料。就等原作者回答疑惑了。

如果是每個軟體都要修改 source code 來配合，那幾乎是無解，有多少軟體要請原廠配合修改，有可能嗎？光 Office 就有多少版本？不用提其他各領域專屬軟體。這還沒考慮到請人家改的經費。我覺得原作者提的系統應該不可能這樣設計。雖然你說〔再好的security機制, 一旦被破解, 就無技可施〕是沒錯，但有機率考量。駭客出在內部的機率較低，內外網分離加上禁用 USB，其實已堵掉絕大部分正常使用下的中毒中木馬以及機密外洩的機會。至於內部員工想盡辦法破解實體隔離盜取資料，那已到了最基本的 No physical security, no security. 所描述的禍起蕭牆。但無論如何，加了本文描述的系統，並不會減少內部員工搞鬼的機率，何必再加一個外部駭客來參一腳的可能機會？這個疑慮一定要澄清，不然企業怎麼可能花錢買風險？

To 11F:
依作者在5F的回應, 被 copy 的資料並不會放入 clip board, 如此 notepad 將無法取得被 copy 的資料, 也就不會有貼到outlook的問題.


To 12F:
我不是該廠商的人員, 我只是曾開發過security相關的AP.
我所說的僅是依據在下過去開發的經驗, 來猜測...
再好的security機制, 一旦被破解, 就無技可施.
再嚴謹的加解密系統, 一旦被人盜走金鑰, 也完全無法防護...
問題在於金鑰的保管, 而非加解密...

通常的狀況是, 憑證與金鑰是發給"人", 而非AP.
我在9F的說法只是將人換成 AP 而以...
如依作者所舉的例子, 需要進行加解密的 AP 很有限, 不是繪圖軟體, 就是程式編輯器...
如果只修改這一兩套軟體來 support 加解密的過程, 我認為可行性其實不低...
應可找特定廠商開發專屬軟體...

9F 是官方回答嗎？軟體需要配合提供私鑰，那是否客戶所有的套裝軟體都要 patch？沒有 source code 的怎麼做？先聲明不是踢館，而是 security 必須是理論上安全，而非是因為機制不為人知而安全，畢竟資料值錢時，專業駭客取得此套軟體開始破解是可能的。我的疑問相信只要客戶稍有security sense 一定會問的。

我剛剛樓上發言. 我的意思是, 如果他有辦法copy至notepad或習慣用的editor, 除非在notepad 或text editor不容許copy and paste, 否則他就可以在notepad 再copy 一次, 以純文字方式paste去outlook. 這是我困擾的地方, 覺得好像不可能防堵

>> copy and paste 程式碼方面也沒有漏洞，於同一個應用軟體 (程式開發工具) 是可以 copy
>> and paste 的，被 paste 的原始碼檔案一旦儲存時會被自動加密，因此沒有洩漏的問題。

>> 技術上會限制將開啟的原始碼複製到其他應用軟體這個動作，因此所複製資料不會到
>> clipboard。

我好奇的是, 我過去以為是應用軟體端控制可否copy and paste 的.

我是用java, 所以工程師習慣用notepad 或其他簡單的text editors. 在不同editors間 Copy and paste 是非常普遍的動作. 所以請問'即時讀寫加解密'可以把copy and paste在notepad 或其他editor disable 嗎? 否則, 如果'即時讀寫加解密'要求工程師用特定的editor, 我害怕會遇到滿大的抗拒...

我公司最近也在評估應否加強資料的保護, 但覺得困難很大. 希望可以與大家分享意見!

> 病毒（或木馬）開啟檔案時，是否也會自動解密...
基本上, 解密這件事是需要有金鑰的, 就在下以前撰寫加解密軟體的概念.
每支具有加解密功能的軟體各自擁有自己的私鑰, 也可能同實永有其它軟體的公鑰.
當A軟體要將檔案加密, 而且設定僅有A,B,C三個軟體可以開啟該檔案時.
則A軟體會使用A,B,C三個軟體的公鑰進行加密運算. 而這個加過密的檔案除了使用A,B或C的私鑰, 否則無法解密.
假如D軟體意圖開啟該檔案, 因為它沒有A,B,或C的私鑰, 而無法順利還原該檔.

換句話說, A,B,C三個軟體必需負責保管好自己的私鑰, 加解密系統只負責作加解密的運算, 不負責代管金鑰.
因此, 檔軟體發出解密需求的同時, 必需一併提供自己的私鑰, 否則必然會失敗.
如此的機制, 將可確切防止病毒或木馬假冒其它軟體來盜取機密檔案...