"整合不就是加解密嘛!", 這麼想你就完了

有些人大概聽過一些TrustView的原理, 知道TrustView是以加/解密為基礎來保護檔案. 所以會很直接的以為Windchill與TrustView的整合, 不過就是把檔案加解密這麼回事. 看過第一篇文章的人從列出的主題大概很快會有個印象, 知道這個整合只怕不會這麼簡單. 而在我以往的經驗裡, 雖然也多少會碰到這樣的質疑, 但與客戶做需求訪談時, 都有機會在討論中, 逐步的讓客戶瞭解 DRM 與 Windchill 整合的原理, 範圍, 重點與選擇性, 並比較各項選擇之優劣, 最後與客戶達成共識.

不過今年景氣差, 有些找我合作的案子, 可能因為預算的壓力, 居然在還未與客戶需求訪談, 就把預算, 時程就先談妥了(有被強姦的感覺). 這些老兄在面對我提出的各項問題時, 卻茫然不知!!! 然後丟出這麼個問題 "整合不就是加解密嘛!". 客氣一點的, 會動之以情, 想辦法要我不要把事情搞的太複雜. 狠一點的幹脆要我配合演出, 編出一套說詞, 提出一個過得去, 可以在預算與期限內做出來的東西. 並且還要我想辦法催眠客戶(甚至背書)這是最佳的方案. 唉................. 五斗米令人折腰至此, 怎不令人感嘆. 本人無權要求他人和我持相同立場, 但我決定花些時間把我在整合方面的經驗寫出來, 一來為避免這類的麻煩事(或者是無聊事, 反正我不會答應)一再發生. 一來或許還能減少一些悲劇, 多積些陰德.

我們先假設真的以"不就是加解密嘛!"這樣的精神, 設計一個在文件審核的流程中, 把文件的主/副檔案(primary content & attachments)加密. 加密的時間點在文件進入發行狀態前, 聽起來符合上篇文章提到的重點.

以下是系統上線後通常會發生的幾個狀況:
1. 為什麼這個檔案我開不了(為什麼他打的開)?
2. 為什麼檔案沒加密 ?
3. 為什麼我不能修改?
4. 歷史紀錄裏的內容外流怎麼辦? 發行時才加密夠嗎?

**為什麼這個檔案我開不了(為什麼他打的開)?
如果沒有好好規劃整合, 那麼, 這個會讓使用者跑來抱怨, 跑到妳老闆那拍桌, 或是老闆叫你去立正...的問題, 可能會經常發生.
會造成 "為什麼我開不了(為什麼他打的開)?"的原因很多. 除去帳號整合的因素外, 通常大概就是 "Windchill上的文件政策與TrustView上的檔案政策不一致". 除去UAT時草率過關的可能性, 上線後還會發生這樣的狀況, 大概就是Windchill上的文件政策(可直接想成權限控管)換了, 然而TrustView上的"檔案政策" (TrustView上定義的權限控管)沒調整過來. 造成使用者可以找到Windchill文件, 下載主/副檔案, 但是卻打不開, 因為TrustView告訴他: "您沒權限!!!", 真是尷尬呀~

權限的整合是整個整合方案的重頭戲之一, 整合的方式不只一種. 當然各種權限整合的技術難度與成本自然是不同, 通常是要依客戶的實際應用來"量身定做"比較合理. 通常在"不就是加解密嘛!"這樣的精神下衍生出來的整合方案, 大概就是以"同步"(synchronization)的方式, 讓Windchill上的文件政策與TrustView上的檔案政策相符. 也就是檔案加密前, 根據預先約定好的規則, 依文件種類(或 加上"存放位置"... 等因素), 選擇某個TrustView系統上的事先做好的政策範本(Policy Template, 簡單來說 就是ACL(Access Control List)) 來保護加密後的檔案.

"同步"(synchronization)的弱點在於"兩次同步間的時間差". 例如Windchill上的文件政策剛剛才換了, 在TrustView系統上檔案政策還沒跟著調整過來之前, 就會存在權限控管不一致的時間差. 在某些公司, 文件政策不複雜, 也甚少更動. 因此, 簡單的同步基本上可符合需求. 但是若是文件種類繁多(例如超過十種), 文件政策也複雜, 變動可能頻繁(例如定期檢討與調整某些群組人員的權限), 若還是用簡單的"權限同步", 那這個"為什麼我開不了!!!"的抱怨, 怒吼或哀嚎, 只怕不定期的會聽到. 這很像吾友志凌的劇本:

於是客戶眼中發出了熊熊的怒火,如同火山爆發的熔岩般不斷的往外湧出,滾燙的岩漿把所有的一切全部吞噬,哀鴻遍野,寸草不留,卻只見無敵的天神冷冷的丟回一句話:我回去跟我們RD研究看看...

我負責過的整合案裏 我盡可能建議客戶採"真正的權限整合", 也就是說當使用者欲開啟一份加密過的檔案, TrustView會以加密檔案所屬的Windchill文件, 向Windchill取得"該使用者對此文件的使用權限", 進而約束使用行為. 採取這種"真正的權限整合", 可避免反覆進行同步的困擾. 有關這種進階的整合方式, 我將在"Authorization Integration"的主題時, 再做更多的介紹.

**為什麼檔案沒加密 ?
通常有幾個可能: 1. 檔案內容有問題. 2. 加密時 TrustServer有問題, 或是 Windchill與TrustServer間網路有問題.

先看看檔案內容有問題這種狀況. 排除不處理的格式(例如早期TrustView只處理MS Office與 Adobe PDF)這種狀況, 通常會發生在PDF格式的檔案. PDF支援加密格式, 幾乎所有DRM廠商對於PDF的保護都是呼叫Adobe原廠的API 將檔案加密. 但是若是使用者上傳一份已經被其他程式加密的PDF檔(例如從供應商那裏拿來的一份PTC檔), 理論上DRM的軟體是無法處理的. 因為底層呼叫的Adobe原廠API會丟出錯誤. 所以一般遇到這種情形, 簡單一點就是跳過這個錯誤, 也就是"放棄"這個加密的動作. 這種情形通常還好, 因為檔案其實原本就加密過了, 只是不屬於 trustview 管轄, 所以使用者不會被TrustView系統要求身分驗證(但是會被原本的保護機制要求輸入密碼或其他資訊). 這個問題或許向使用者解釋一下就OK了.

但是另外一種"digitally signed" PDF檔案, 就比較難搞! 也就是PDF中加入了數位簽章(Digital Signature). 這種檔案, Adobe原廠的API也一樣無法將它加密. 但是一般使用者是可以直接打開的, 只是沒辦法竄改內容罷了. 遇到這種檔案通常就比較麻煩, 因為一般使用者不會主動去注意有沒有數位簽章 (多數使用者可能也不知道甚麼是數位簽章). 所以遇到這種情況 一下子只怕還不好說明(除非你想扮演上面那個無敵(or 白目)天神).

另外, 天有不測風雲. TrustView server的硬體掛了, 或是有時不巧 Windchill 與 TrustServer 間網路有問題, 造成加密的失敗. 然而, 這類狀況下, 就可以平白無故的放過這些檔案? 說不定就是這些檔案造成您的"旦夕禍福"也難說得很? 所以檔案的加密處理最好不要當作萬無一失, 永遠要有最壞打算. 謹慎的例外處理與通知機制, 絕對是保命良方(如果你夠"神", 那就另當別論).

**為什麼我不能修改?
如果使用者把某份文件作版本修訂, 例如從A版產生B版. 如無意外, 使用者會找你, 因為他無法把B版文件上的內容檔案修改成他要的. Why? Windchill在版本修定(Revision)時, 會把上一版(A版)的一切(屬性與內容), 移交到新版本(B版). 而上一版(A版)發行前, 檔案已經被加密了!!! 而且配合一般在Windchill上對"已發行"文件的政策, 是不允許任何人再修改的. 所以真相就是使用者試著要修改從"A版"那兒繼承過來的加密檔. 這可不是調整權限這麼簡單的事, 應該說, 從根本上就是件錯誤!

對Windchill文件管理而言, "版本管理" (Version control) 是一個重要的基礎. 提供一份文件在初次發行並大量使用後, 藉由衍生(Revise)出的新版本, 重新定義內容與屬性, 以符合當下的需要. 在Windchill裏每一個版本的文件, 基本上都是"獨立個體", 擁有自己的屬性與內容, 生命週期, 審核流程... 所以在權限控管上, 不同版本文件的權限是彼此獨立的. 例如, 對一份狀態為"已發行"的A版文件, 與剛"revised", 還處於"In Work"的B版, 在權限上本來就不能混在一起.

所以當要整合Windchill與DRM時, 就必須得以"Windchill文件管理的方向"來思考. 因此, 版本管理是不能不考慮的. 對這個問題, 根本解法在於 A版裡的加密檔案與B版裏的加密檔案, 以TrustView的角度來看, 根本就該是兩份不同的檔案! 只不過 一開始時, 兩份檔案的內容恰好一樣罷了. 由於不是同一份檔案, 才有機會套用不同的文件政策.

因此在版本修訂時, 我們必須對"新版本裡繼承而來的檔案"做些額外的處理. 例如: "解密成原始檔" 或 "先解密再加密". 以上述在流程中加密的整合方式, 採用"解密成原始檔"比較好. 因為新版文件的流程會在文件發行之前把檔案加密.

**歷史紀錄裏的內容外流怎麼辦? 發行時加密夠嗎?
某個版本的文件, 從初始狀態(例如 IN WORK)到"已發行" 通常會經過數次修改(updated). 每次修改都會產生新的版序(Iteration). 最新的版序代表該版本文件, 其它過程中產生的版序稱為"歷史紀錄"(History). 如果只是在發行前把檔案加密, 而 歷史紀錄裏的檔案偏偏又包含了敏感的資料, 那這個從"不就是加解密嘛!"這樣的精神衍生出來的"在流程進入發行前加密"的方案, 似乎就不通了? 或是, 需要補強. 例如有個案子, 因為審核流程較精簡, 審核週期短, 因此決定在文件發行前, 再把歷史紀錄裡的內容"清除"或"一次加密". 但是, 對於其他案子而言, 這樣的假設就不一定成立. 所以在某些案子, 加密的時間點會提前到檔案上傳到Windchill的時刻, 或甚至檔案才剛在使用者的電腦產生時就先加密, 以系統預設的政策保護起來. 一但上傳到Windchill時再套用符合Windchill文件政策的權限設定.

以上我只是稍微讓大家嚐嚐味道, 體會一下, 為何整合不能只是以兒戲的態度將整合視為加解密的小東西而已. 我認為, Windchill與DRM的整合, 基本上必須回歸Windchill的文件管理. 以Windchill文管的特性去思考如何在把內容檔案在TrustView的掌控之下, 依然符合Windchill文管的精神. 並達到安全的要求.

為什麼Windchill上需要DRM之整合方案

Windchill(含PDMLink) 上的"權限控管"(Access Control)是敝人目前為止見過最有彈性也最複雜的(我想有空我會為此也寫一篇與大家分享). 不過因為歷史背景, 從前DRM並非顯學(悲... 到目前也還不是), 所以Windchill一直沒有真正把DRM的精神融入它的安全機制.

ContentHolder vs. Content
基本上, 一般使用者概念上習慣稱呼為"文件"的電子檔案, 如MS Office的Word, Excel, ..或其它格式如PDF.., 在Windchill上並不是被真正被當作一份份的"文件" (Document). "Windchill的文件"可以把它想像成舊式"裝公文用的牛皮紙袋", 裡面可以放"一個或多個檔案". 但是從外面或整體來看, 就是一份文件. 而一般使用者習慣上稱為文件的檔案, 對於Windchill的文件來說只是一個個 "內容物"(Contents), 而文件叫做 "含有內容"的東西 (ContentHolder).

閒話: Windchill把"Document"擴大為比較複雜的概念, 是一個具有多種層面(facets) 的複合體. 每一種層面都有它在實際使用上的意義. 例如一份Windchill文件可擁有"屬性"(片段的資訊欄位, 例如名稱 編號 種類 部門 作者 建立日期)以利使用者快速瀏覽重要資訊或搜尋, 而不需把實際內容檔案一個一個打開, 一頁頁閱讀 . 這種"擁有屬性"的能力就是一種"物件(Object, or Object Oriented)層面" . 而文件有生命週期, 能展現文件從開始建立 審核 發行 最終下線 成熟度所以又是另一種層面...

在Windchill裏, 一個使用者要能接觸(找到 )或使用(如閱讀屬性(如名稱, 註解), 內容檔, 修改屬性, 修改內容, 增加附件...)須經過 "身分驗證"(Authentication)與 "權限控管" (Authorization), 並且使用行為也會被記錄下來 (Accountability). 但是一旦使用者有權閱讀文件內容, 就表示使用者可以把檔案從Windchill上下載下來. 若使用者直接把這個下載下來的檔案透過USB裝置, 郵件, 網路...傳遞給公司內"無權閱讀"含有此檔案之Windchill文件的人員, 或甚至是流傳到公司外, 不明人士之手, 基本上又回到"淺論DRM (Digital Right Management)"所提到之傳統安全系統的問題.

Windchill 8之前的版本, 對Windchill文件具"閱讀"(Read)權限的人, 除了允許進入物件屬性頁(Object Properties)查閱基本資訊外, 也同時賦與其下載內容檔案的權力.

從Windchill 8開始, 原本的"閱讀權"僅僅管控"物件屬性"之查閱. 內容檔不管是"主要檔案"(Primary Content)或"附件"(Attachment)的下載則由另一種叫作"下載"(Download)的權限來負責.

但是, 不管是Windchill8之前, 還是之後, 對 "有權從Windchill上下載檔案的人把檔案外流" 這件事基本上一樣是無解. 所以這也是本文主題 "為什麼Windchill上需要DRM之整合方案"的由來.

Content Holder's Security + Content's Security
整合方案主要的重點就是 Windchill文件資訊的管控, 仍然由Windchill的權限控管機制負責, 應為Windchill做的真的很好. 但是一旦涉及檔案使用, 就由DRM系統接手. 簡言之, 如果存放在Windchill裡的這些檔案是已經被DRM保護的檔案, 就有機會達到這樣的效果.

以下為Windchill 7與TrustView整合後 文件使用之範例圖示, 若對TrustView的操作介面或原理不熟悉者 可先參考 "以TrustView為例介紹DRM之基本概念".

首先, 因為內容檔案已經被轉換成TrustView的檔案格式, 所以沒有TrustView前端程式(Client Program)的人即使取得此檔案也無法讀取真正內容

若已安裝TrustView Client, 開啟這個被TrustView保護的檔案時, 就必須先經過身分驗證, 然後TrustView系統會進一步查出你是是否有權使用此檔案.

如下例, 系統查知此人僅有"讀取"之權限, 因而將"檔案內容"呈現, 並封鎖其它修改, 列印..之功能.

至於 "怎麼做?", "要注意些什麼?", 與其它種種問題就留待其它的文章一樣一樣來說.

Windchill Performance Tuning

積非成是: "Multiple Background servers"

Joseph's "Configure Economical Clustering with 'balance'"(欠稿, 追緝中...)

Windchill Report Solutions

ChihLing 's Jasper Integration Demo

Windchill與報表系統整合之效益簡介: 章節預覽

David's Jasper Integration Demo 1 (InfoEngine Data Source)

David's Jasper Integration Demo 2 (RMI Data Source)

David's Jasper Integration Demo 3 (A New Document-in-Process Report)

DRM文章導引

淺論DRM (Digital Right Management)

以TrustView為例介紹DRM之基本概念

PKI相關文章導引

好書推薦: PKI: Implementing and Managing E-Security

PKI 妙喻 & "向左, 向右, 向前看"

公/私鑰(Public/Private Key)的原始用途

密碼學閒話

數位信封: 改良版的悄悄話

數位簽章(Digital Signature)簡介

憑證, 漫遊網路世界的駕照

憑證與公/私鑰之實例應用一: SSL

PKI是什麼? PKI裡有什麼?

新主題: Windchill與DRM之整合方案

有不少朋友知道我之前的經歷, 也知道我主導過幾個 Windchill 與 TrustView 整合的成功案例. 最近, 因為"個人資料保護法"三讀的新聞, 適逢有消息說景氣有好轉跡象, 應兄弟們的要求, 除了分享過去研讀資訊安全方面的心得外, 也順便聊一聊 Windchill 與 DRM 整合的一些經驗. 順便也可與資訊安全的一些理論相互應證. 當然, 接下來相關的主題, 基本上會以TrustView作為DRM的代表. 對此, 其他的DRM廠商也別不高興, 一來, DRM方案裏, 嚴格來說我對TrustView最熟, 而TrustView投入與Windchill的系統整合時間最久. 二來, 我相信許多不同的DRM產品觀念是相通的, 若您認同我在Windchill與DRM整合上的想法或論點, 理論上也可把其他DRM產品套用進來. 因此, 並非獨厚 TrustView一家.

如本站其他文章, 在這個主題上, 我們還是著重設計理念的分享與經驗的交流, 不會有實際的程式碼放上來. 所以, 喜歡自己DIY的朋友先抱歉了.

以下是目前我預計要發表的幾篇文章. 因為這個主題涵蓋範圍還蠻廣的, 所以採取多個 "次主題" 方式. 一來, 每次分享一點, 比較容易消化. 並且以各種不同角度來思考這個主題, 效果也應該會好些.

1. 為什麼Windchill上需要DRM之整合方案? (一切都應該由此開始吧, 如果最後發現不需要, 底下就不用看了...)

2. "整合不就是加解密嘛!" --> 這麼想你就完了 (如題, 希望還來得及拯救一些人)
2.1下載時加密(Encryption on download)是個好主意? (有些人好像不了解問題的嚴重性, 再加一篇)

3. 以資訊安全的角度去思考Windchill與DRM之整合 : Thinking in 3 big "A"s (不是討論"A"片, 有期待者請轉台)

4. 以Windchill之 "文件管理"來思考DRM之整合 (通常, 這裡就是所謂的 Business Logic, 應該是專案最主要的目的)

5. 文件內容(檔案)加密的時間點 (想清楚! 免得白忙一場...)

6. 身分驗證(Authentication)整合之經驗分享 (必要! 如果你不想被罵死...)

7. 權限整合(Authorization)整合之經驗分享 (重要! 如果你不想被累死...)

8. 例外處理 (絕對必要!! 如果你不想被罵死或累死...)

9. 災難復原 (絕對必要!!! 如果你不想提早退休...)

10. 系統架構設計 (理論上是遙遙無期, 除非大家看到最後不嫌煩, 又真的很想DIY, 或者我找不到事做...)

數位簽章(Digital Signature)簡介

此篇假設您對密碼學的一些術語已有基本的認識, 若您時間有限急於進入主題, 不妨閱讀上篇"密碼學閒話 ".

簽章, "簽名/蓋章", 基本上就是早期用來"證明某人身分", 進而認定某些東西的"有效性". 舉例來說, 文件/信件的署名, 合約上的簽名/蓋章 ... 但以簽章方式來證明文件或合約的有效性通常會衍生另一個問題, 也就是"完整性"或是文件或合約內容是否會遭到"竄改"的問題. 例如通常簽章都在"最後一頁", 前幾頁的內容有可能遭有心人士抽換以獲取不當利益. 所以我們常會看到有所謂的"騎縫章",用來蓋在夾頁上, 以確保內容的完整性.

所以, 用"數位方式"做成的"簽名蓋章", 當然要能達到證明某人身分與確保資料的完整性.
在討論實際做法之前, 我們來看看一個非對稱密碼學裏一個重要的部分 "Hash", 也就是有些朋友在修資料結構課時碰到的Hash.

Hash基本上是一種方法, 把大量資料內容消化然後產生一個"固定長度"的結果資料. 固定長度的結果資料比起原始資料通常小的多. 好的Hash演算法基本上可確保不同內容的資料會產生不同的Hash結果. 所以這個固定長度的結果資料又稱為 "fingerprint" 或 "digest". 也就是說, 對於兩分數百頁的文件(當然是頁數一樣, 或看起來一樣), 要確認兩份文件是否真正相同, 一種方式就是逐頁逐字比對, 另一種更有效的方式就是比對這兩份文件的fingerprints(Hash結果).

在製作數位簽章時就用到了Hash. MD5與SHA-1是比較常見用於數位簽章的Hash演算法. 製作數位簽章的步驟為: 1. 將欲被簽署之資料(如文件或合約)以選定之Hash演算法產生fingerprint. 2. 將產生之fingerpint用簽屬人之私鑰加密 (由於fingerprint很小, 用非對稱演算法加密沒問題) 3. 將以私鑰加密後的fingerprint加上其他輔助資訊, 如演算法名稱, 合成所謂的數位簽章.

因此簽署人可以把資料(文件或合約)以明碼的方式傳給其他人. 其他人可用簽署人之"公鑰", 先把數位簽章裏頭那一個用簽署人"私鑰"加密的fingerprint還原. 再用數位簽章內指定的Hash演算法, 為資料(文件或合約)重新產生fingerprint. 將兩個fingerprints比對, 即可知道文件被竄改與否.
聽起來前輩們的心血終於為我們建立了完美世界! 但是我們很快就發現, 人心之邪惡遠非科技所能敵. 試想一個狀況, 當你拿到一把公鑰(例如接到自稱為某個你熟知人士的電子郵件, 附上一把他的公鑰), 你怎麼知道哪把私鑰是真正在誰手裡? 公私鑰機制的假設就是持有公鑰的人可以確定那一把唯一的私鑰 一定是在那個人手裏. 但是現實生活, 網路世界, 我們真能或很容易證明這個假設嗎? 假設一旦不成立, 數位信封與數位簽章就只是白忙一場罷了..

似乎人惹出來的問題還需要人來解. 下篇主題就來討論怎樣把人,尤其是有錢, 有權, 有勢或有公信力的人拖下水的解決方案: "憑證" (Certificate).

數位信封: 改良版的悄悄話

此篇假設您對密碼學的一些術語已有基本的認識, 若您時間有限急於進入主題, 不妨閱讀上篇"密碼學閒話 ".

數位信封. 顧名思義就是想把信放到信封裡, 沒打開信封就看不見信的內容. 而誰能拆信封? 以道德觀點而言, 自然是信封的收信人, 但是數位的世界, 靠道德大概是不太夠.

簡單來說, 數位信封運作方式是: 1. 以隨機方式產生一對稱性鑰匙(symmetric key). 2. 以此對稱性鑰匙加密資訊主體(文件 信件..). 3. 以收信人之公鑰(非對稱性)加密這把加密文件或信件的鑰匙(對稱性). 4. 將加密的信件與鑰匙寄給收信人.

所以收信人只需用自己的私鑰即可還原那一把用來解密文件的鑰匙, 進而把文件解密. 而這個動作是其他人無法做到的.

簡言之, 數位信封以"對稱性"(symmetric)密碼學來解決公/私鑰機制在加密資料時長度的限制與加密後的資料長度會爆增的問題.

密碼學閒話

在上篇"公/私鑰(Public/Private Key)的原始用途"中提到了"悄悄話"與"以個人身分發布訊息"兩大類應用, 也提到了一點公/私鑰的先天限制, 現在就讓我們分享前輩們如何解決這些限制.

在進入解決方法之前, 我們先來看看(或回憶)一些密碼學基本的觀念與術語.

密碼學(cryptography), 簡單來說是種數學, 而且是很難的數學. 目的是把 "明碼"(Clear text, 原始資料)轉換成 "密碼"(cipher, 無法辨識的資料) 或是把密碼轉換成明碼. 明碼轉換成密碼的過程叫 "加密"(encrypt). 密碼轉換成明碼的過程叫 "解密"(decrypt).

加解密(encrypt/decrypt)是一套設計出來的數學運算, 基本上利用一個或一組"數字"(number) 把明碼轉換成密碼, 或是把密碼轉換成明碼. 這個或這組"數字", 通稱鑰匙 (Key). 原始的想法大概就是把加密想像成把東西"鎖起來"(lock), 而解密想像成把鎖住的東西"解開"(unlock). 以早期或現實社會常見的鎖來看, 鎖住與解開這兩個動作, 自然是要靠鑰匙.

密碼學裏的鑰匙 (Key)猶如雄性社會裏的雄性象徵: 長度很重要 (如武俠小說裡常說: "一寸長, 一寸強"), 與安全的程度成正比. 這裡的長度指的是位元數(number of bits) 越長 (例如 32bits), 就表示當作鑰匙數字的選擇性越多(0~2^32 - 1), 相對被猜中的機率就越小. 所以就不難理解很多公司會很驕傲的強調他們的安全方案比別人的長 (TrustView當初就宣稱自己是業界最長: AES 256 bits, 比Authentica長一倍, Donald: 嘿嘿嘿....).

密碼學可分為兩大類: "對稱性"(symmetric)與"非對稱性"(asymmetric).

對稱性密碼學, 簡單來說就是開鎖(加密)與解鎖(解密)都用同一把鑰匙, 故稱對稱(symmetric).

而非對稱性密碼學之前在PKI 妙喻 & "向左, 向右, 向前看" 提過了, 就是公鑰/私鑰的機制. 因為加解密用不同的鑰匙, 故稱非對稱.

對稱性密碼學起源很早, 常見的 DES, 3-DES都屬此類. 以技術的角度而言, 比起非對稱性密碼學這個後起之秀, 其實是有很多優勢. 但是對於電子交易時所需要的兩大特性: "悄悄話"(私密的資料傳輸)與 "以個人身分發布訊息"(確認資料之來源), 就面臨了實際上困難.

首先是Key的數量. 為達到悄悄話的效果, N個人需要有N*(N-1) / 2 把鑰匙. 比起非對公鑰/私鑰的機制僅需 N* 2把, 如何分發和保管鑰匙(確定每個人只能拿到他可以用的鑰匙)相形麻煩.

另外, 對於以鑰匙來證明持有人身分而言, 因為加解密都是同一把鑰匙, 更是無解. 且不說要以個人名義發布訊息須要加密N-1 次這麼麻煩, 更要命的, 同一把鑰匙由兩個人持有, 如何能證明唯一性?

然而對稱性的優點恰巧可彌補公鑰/私鑰的缺點: 1. 加密的資料有長度限制 2. 加密後的資料長度會超越線性成長(爆增). 所以前輩們就巧妙的將這兩種加密截長補短, 因此有了下兩個主題: "數位信封(Digital Envelop)" 與 "數位簽章(Digital Signature)"

公/私鑰(Public/Private Key)的原始用途

之前在PKI 妙喻 & "向左, 向右, 向前看"一文用一個簡單的比喻介紹了PKI的重要特性, 並以一知名電影作Use Case, 演練了一下公/私鑰(Public/Private Key)的使用. 不過那個Use Case只是以笑謔的方式讓初次接觸PKI的朋友加深印象, 不要太當真 (尤其那些支持金先生的影迷不要因此來找我麻煩).

總之先記住: 1. 公/私鑰為密碼學之一支, 且為PKI(Public Key Infrastructure) 之基礎. 2. 公鑰與私鑰必為"成對產生", 私鑰顧名思義為個人私有的鑰匙, 所以僅能由一人持有, 或可想像為證明某人身分之信物. 公鑰則有公開, 公物之意, 用以廣為散佈. 3. 公私鑰皆可用於加解密, 但是私鑰加密的僅有成對的公鑰可解, 公鑰加密的也僅有成對的私鑰可解.

公/私鑰的用途很廣泛, 例如購物網站常使用之"https"(SSL)通訊協定即為常見之應用實例. 如果我們略去應用的領域, 對象, 行業...等等因素, 回歸本質面, 我們其實可以將公/私鑰的主要用途區分為二: 1. 悄悄話 2. 以個人身分發布訊息.

所謂悄悄話的意思, 就是不希望別人聽到. 回想一下公/私鑰的特性: "公鑰加密過的資訊, 只有私鑰才解的開". 而誰擁有私鑰呢? 所以, 如果你希望某人給你的訊息不被他人知道, 你只須要要求那人將訊息用你的公鑰加密, 即使其他人也擁有你的公鑰也沒用. 因為公鑰加密的東西僅有成對的私鑰可解, 而只有你擁有這把私鑰.

悄悄話的相反, 大概就是像"大聲公"或"廣播電台"--> 唯恐天下不知! 而更重要的是要讓大家知道是"誰說的". 如果你想以個人身分發布訊息, 而且讓大家知道那是你發的, 最簡單的方法就是把你要發布的訊息, 用你自己的的私鑰加密起來, 再廣為傳遞. 那些擁有你公鑰的人自然解的開, 若解不開那就一定不是你用私鑰加密的東西. 我們也可藉此體會私鑰 --> "見鑰如見人"的設計理念.

在我們把PKI, 公私鑰..背後複雜的演算法理論與實做先撇開後, 試著從設計的源頭或目的去了解, 其實這些東西還是有和藹可親, 很生活化的一面. 不過看倌也先別太爽, 以為PKI或公私鑰就這麼點料, 其實故事來多著呢!

首先比起早期密碼學加密解密都用同一把鑰匙, 公私鑰看來很完美了, 但是它也有先天上的缺陷, 其中有兩個蠻要命的. 首先, 公私鑰的演算法通常在加密的資料有長度限制. 也就是說,一旦超過限制, 加密可能會失敗. 另外, 原始資料長度越大 ,加密後的資料長度會超越線性成長. 簡單來說, 假設原始資料長度為a, 加密後長度為b. 當原始資料長度為2a, 加密後長度可能會暴升為4b, 也就是一個上揚的曲線. 在實際應用上這兩點絕對不是好消息. 因此我們可以想像, 不管是悄悄話也好, 發布消息也好, 一定得解決這些問題.

下一篇會談到公私鑰在實際應用時如何克服先天的弱點, 並同時帶出兩個主題: 數位信封 (Digital Evelope) 與 數位簽章 ("Digital Signature").

以TrustView為例介紹DRM之基本概念

選擇TrustView來介紹DRM (Digital Right Management)的重要觀念原因很無它, 只因本人曾在TrustView服務. 加上其他家的產品我不夠熟, 倒不是獨厚TrustView. 至於此篇文章是否有所偏頗 或刻意為TrustView宣傳, 就留給讀者判斷.

我在上篇"淺論DRM (Digital Right Management)"中提到DRM強調兩個重點 ,而且是傳統系統安全上忽略的部份:

更細緻的權限種類 (如閱讀期限, 次數, 列印, 複製...).

數位內容的使用權限控管, 不因所在位置(如企業內部系統 或企業之外某競爭對手的個人電腦)而有所不同.

首先用一份被TrustView系統保護的 MS Word 的檔案"dav1.doc" 來說明第一個概念. 此檔案是在作者以MS Word編寫完成後, 再存成TrustView的格式. 作者並為此檔案制定了 "所有合法使用者皆可讀取但僅能讀取"的規則. 所以當此檔案由一般合法使用者的使用時, 自然就如下圖所示, 其他行為如修改, 複製, 列印.. 皆不允許.

至於TrustView怎麼解決此份檔案"被帶出系統之外"後仍能確保"所有合法使用者皆可讀取但僅能讀取"的規則? 這個問題稍微複雜點, 但不難懂.

首先當使用者把檔案交由TrustView管控時, 此檔案即被TrustView系統"加密". 此加密過的檔案必須由加裝 "TrustView前端程式"(TrustView Client) 的MS Word才能讀取. 若沒裝TrustView前端程式, 看到的檔案基本上就成了這副德性:

如果裝好TrustView前端程式, 也不表示任何人都可閱讀此加密檔. 因為條件為"合法使用者", 也就是能在TrustView系統有帳號的使用者. TrustView前端程式會要求使用者出具證明(例如 ID 與password) 然後將此證明資訊交由後端的 "TrustServer" 驗證此資訊是否正確. 如圖, 經過身分認證後 MS Word上會顯示使用者身份.

TrustServer除了回傳使用者身分是否確認之外, 還告知TrustView前端程式此使用者對此文件的使用權. 如上例, 合法使用者在通過身分驗證後, 馬上可閱讀該檔案. 但是如果另一份檔案僅允許少數人閱讀, 那沒有閱讀權利的使用者 還是無法閱讀此文件.

此文主要是借用TrustView系統的畫面, 先讓使用者能迅速進入DRM這個主題. 至於哪一家廠商的方案較好, 架構比較優... 這裡並不討論. 後續的文章, 會開始討論一些較為細節的部份: 如一般DRM系統架構, 導入DRM系統需要考慮的事項... 當然如無意外, 我還是會以TrustView來做對照說明.

淺論DRM (Digital Right Management)

關於DRM (Digital Rights Management), 讓我們試著撇開學術上囉嗦的定義或各廠商璀璨的商業語言. 我試著用我看過,經歷過...最後消化過的: "平民式"或是"口語化的" 語言來介紹這個東西.

何謂Digital Rights? 我們先從 "Digital Content" 來看: 例如我們每天工作接觸到的各種格式(formats) 的電子檔案. 對許多人而言, 紙本形式的檔案可能只是一個回憶了. 一提到"檔案" 只怕大部分人聯想到的都是一個個像商業文書用的 MS-Office Word, Excel, Powerpoint, 娛樂用的 MPegJPeg..等等, 也就是所謂的 "電子檔". 有人質疑"電子檔"(Electrical file) 從一開始就把觀念侷限於既有的材料與技術, 所以有人重新用 "Digital Content" 來代表任何以數位形式(0/1)把"含有內容的東西"(例如紙本的書, 古早時音樂膠片,錄音帶 Beta/VHS..)記錄下來的部分. 所以 "Digital Rights" 其實就是強調 "rights on digital content".

"Digital Right" 讓我聯想到一個笑話. 以前有一個卡通叫"Bevis & Butthead". 有一回"Butthead"看到女權運動者身上T-Shirt印的標語 "Woman's Right Now!". 這老兄直接理解為 "Woman Right-now", 結果當然是被海扁.

至於 "DRM" 呢? 有人說現在是強調管理的時代, 什麼話題都有人扯上管理. 所以搞個Digital Right Management 也不用太奇怪.

DRM真的是新觀念嗎? 見仁見智吧? 至少, 我不這麼認為. 例如任何數位系統上針對哪些使用者可以閱讀或修該哪些檔案, 我覺得這就叫DRM了! 因為,三個字都包含到了... 問題只是做得 "好不好" 或 "夠不夠" 的問題.

早期的前輩們覺得對於像檔案這類的數位內容, 能約束使用者 "讀取" 或 "修改"就差不多了, 了不起再從"修改"這項上衍生出建立與刪除大概就很夠了. 但是以現今世界步調之速, 商業模式之複雜, 從前的想法拿到現在就不一定合適. 例如, 光是 "閱讀" 這一項, 就有人希望要能加上 "閱讀期限" 或是 "閱讀次數". 或者是僅能在"某些地方"(例如某些特定的電腦或裝置上). 至於能 "看" 是不是就代表能 "印" (包含螢幕列印與擷取) ? 另外, 許多人可能僅對部分章節有興趣. 那麼, 是否准許他用 "選取-複製-貼上"(select-copy-paste)將部分內容帶走? 以上所列, 皆凸顯了從前定義數位權限的方式 過於狹隘, 無法滿足現今多元的商業模式與需求.

另外, 在網路與各儲存裝置不發達的年代, 作業系統對於檔案提供之權限管理或許堪用. 但是當一個檔案 "離開"(當然是被帶走囉...)那個約束他的系統, 而到了另一個系統. 原先系統對它是否仍有約束力? 答案絕對是"否".

所以我認為DRM不是新觀念, 也應該還是電腦安全領域的一部分(甚至只是一小部分). 但改名換姓後主要是要強調兩個重點: 1. 更細緻的權限種類 (如閱讀期限, 次數, 列印, 複製...). 2. 數位內容的使用權限控管, 不因所在位置(如企業內部系統 或企業之外某競爭對手的個人電腦)而有所不同.

好書推薦: PKI: Implementing and Managing E-Security

對於PKI(Public Key Infrastructure)這個主題, 個人非常喜歡一本書: PKI: Implementing and Managing E-Security (McGraw-Hill出版). 本人之前在TrustView服務時曾擷取前三章內容製作 "PKI簡介" 作為新人與合作夥伴(中科院某單位)的入門教材. 蒙中科院的朋友謬讚認為這是他們聽過最好的一次PKI的課程. 唉... 借花獻佛, 有騙吃騙喝之嫌.
"PKI: Implementing and Managing E-Security" 這本書講的東西不算少. 可惜即使以前在TrustView 時也沒全看完. 但是我非常推薦大家有空至少看看前三章. 以作者深入淺出的風格, 相信不會花你太多時間, 即能獲得對 PKI 相當深度的了解. 尤其是前一陣子聽說"個人資料保護法"即將通過三讀, 相信各資安廠商現必摩拳擦掌中. 各位從事IT的朋友, 或許過一陣子就會開始被老闆要求評估資安方案, 或甚至被資安廠商包圍, 競相說服您他家的方案有多優... 所以這本書相信在工作上是個不錯的投資.

有關"只能有一個Background Server"的疑點

Background真的只能有一個嗎? 查過幾份文件與菜鳥時上過的Performance Tuning講義, 這個問題的確解釋不清楚, 甚至答案是衝突的. 但是當我試著從"什麼是Background Server?" 與 "為什麼需要Background Server?" 這個兩點先探索起. 我開始覺得Background server應該是可以多個. Why? 我們可透過Performance Tuning中提到透過設定多個Method Server 以善用硬體效能的章節來探究.

首先, 對測試或開發環境而言, 一個Method Server是最常見的, 因為資源通常不如Production來的充足. 例如, 測試或開發環境的RAM通常有個4G可能就偷笑了, 上面又要裝一個更兇的Oracle, 能分給一個Method Server 1.5G的RAM通常就不錯了. 但是, Production則不然! 一來, RAM可能更多. 二來, 通常Production至少由二台機器組成: 一台負責Application, 一台負責Database. 如此一來, 只有一個Method server 是否太可惜了? 更何況, 就Albert手上的資料顯示, 好像某版本之前, Sun的Java Virtual Machine在MS Windows上, 一個JVM Process只能用到1.5G, 超過的部分就用不到. 我想, 這個血淋淋的事實大概能包含PTC在台灣九成的各戶. 所以要養頭猛虎是不可能了, 試試猴群吧...

正巧, Windchill本來就考慮了猴園的架構, ServerManager就是那個耍猴的.

Windchill 裏就有這麼個property: "wt.manager.monitor.start.MethodServer" 用以告知系統要啟動幾個MethodServer, 預設值是1. 所以我們想要2個Method Server, 自然就設成2, 依此類推. 但是有實際維護Windchill系統經驗的人早就知道不能這麼幹. 正確的說, 不能只是設這個Property.

再繼續討論之前, 我們得先了解MethodServer做些什麼? Method server 可以想成是一堆"Method"(Java Method)的集合, 以Java RMI實作, 可供遠端呼叫 , 例如透過Apache與Tomcat, 來自瀏覽器端使用者的指令. 另外, Method server還有一個重要的功能, 也就是處理Queue裡面排隊的工作: 例如工作流程的Robot, Activity裡的Transistions... 都是Method server 先將它們加到 Queue裏, 再一個個拿出來執行.

設定多個Method Servers後, 當系統處理大量來自使用者端的需求時, 效益較明顯. 但是Queue裏的工作呢? 當只有一個Method Server時, 問題不大(這是風涼話...), 因為..嘿嘿嘿...什麼都歸他! 但是, 當有兩個? 那Queue裏的工作怎麼分? 不然同一個工作都執行兩次, 那絕對不是恐怖可以形容的... 所以, 就有了Background Server這個東西. 以程式碼的角度, 它就是Method Server(一樣是由wt.method.MethodServerMain 啟動). 但是它只處理Queue, 不處理 RMI requests. 另外, 還有一個property "wt.queue.executeQueues" 用來告訴所有Method server 要不要碰Queue. 所以, 為了解決爭搶Queue裏工作的問題, 只要超過一個Method Server, wt.queue.executeQueues就須設為 "false". 這表示Queue不干MethodServer的事, 通通交給 Background Server吧!

但是Background server的設定很詭異, 首先, 要設定這個玩意兒: "wt.manager.monitor.start.BackgroundMethodServer". 與wt.manager.monitor.start.MethodServer類似, 一樣是用來表示數量, 也就是要啟動幾個Background server. 大多時候, 我們看到是 "1" 或 "0". 但是, 如果只是"有"與"沒有", "true/false"不是更妥當嗎? 兩個BackgroundServer難道就不會爭搶Queue裏的工作?

所以1或0聽來是合理的數值. 但是, 難道所有的流程與所有Queue裏的工作都須要靠一個最多不超過1.5G的JVM來拖嗎? 所以, 我們可以很合理的懷疑wt.manager.monitor.start.BackgroundMethodServer 定義成">=0"的數字是有道理的. 多個Background Servers的需求有其正當性.

在System Admin Guide 中 提到了Queue-Group的概念. 也就是說系統所有的Queues可以分成幾個群組. 系統安裝之初 所有的Queues都屬於一個叫"default"的群組. 管理員可利用定義在wt.properties中的"wt.queue.queueGroup"這個property來新增群組, 並利用設定Property: "wt.queue.(property name)=" 的方式重新分組. 但是為什麼要分組呢? 從 System Admin Guide 中有關Queue-Group語焉不詳的描述, 似乎暗示一種可能: BackgroundServer可以指定負責的Queue-Group.

但 是, 翻遍System Admin Guide 8.0 只得到一個在cluster環境的應用範例. 這cluster環境包含 "appsvr1, appsvr2, 與 appsvr3"三台主機. 若我們希望三台主機可以分擔部分的Queue: 例如 queue "xxx"和 "yyy"由appsvr2負責, zzz由appsvr3負責, 剩下的全由appsvr1搞定. 那我們可以利用以下的設定:
wt.manager.monitor.start.BackgroundMethodServer=1
wt.queue.queueGroup.default=appsvr1
wt.queue.queueGroup=localhost
wt.queue.xxx=appsvr2
wt.queue.yyy=appsvr2
wt.queue.zzz=appsvr3

上 述設定基本上在每一台主機的wt.properties裡都是一樣. "localhost"是合法的關鍵字, 而在各台主機上用"wt.queue.queueGroup=localhost"將會產生"appsvr1, appsvr2, 與appsvr3"三個Queue-Group. 但是, 由於此範例是用在Cluster的環境, 感覺上一台機器上只能設一個Background, 真是令人沮喪! 路似乎絕了?

巧的是, 設定多個Method Server這個主題時還牽涉另一個選項: 就是為個別Method server與Background Server設定Log檔. 在尋找資料時意外發現下列屬性:
wt.manager.cmd.BackgroundMethodServer=$(wt.manager.cmd.MethodServer) wt.method.serviceName\=BackgroundMethodServer wt.queue.executeQueues\=true wt.queue.queueGroup\=default wt.adapter.enabled\=false wt.method.minPort\=3000

這個東西要讓我說, 怎麼看都像是指定Background Server負責處理"default"這個queue-group. 這彷彿是山窮水盡後的柳暗花明. 但是高興沒多久, 問題又來了!!! 當我有兩個Background Servers時, 我怎麼讓系統知道每個Background Server需要個別的啟動指令? 無法個別設定啟動指令, 我怎麼讓不同的Background Server處理不同的queue呢?

其實這是非常接近答案的一次探索. 但是萬萬沒想到會栽在一個看似無辜, 理所當然的設定: "wt.manager.monitor.services=MethodServer BackgroundMethodServer", 終究沒辦法再向前跨一步.

緣起--"Multiple Background servers"

Egg兄一直是我非常尊敬的一位前輩(不要懷疑, 名片上真的是這麼印的! 他們那還有一位"鳥"哥(Bird). 最先我還以為他們聯合起還耍我!!!). 因為他過去在軟體開發公司, 程式底子強. 而到User-Site服務後, 又開始摸索網管與Oracle. IT圈像他這種軟硬兼修的人物我猜是不多見. 當初要不是咱們"劫機"哥福至心靈, 獻計把Egg拗來PLM的專案, 然後憑借他深厚功力, 硬是把許多客製需求吸收下來. 不然, PTC當初這個案子收不收的掉, 恐怕很難說喲? 如果當初收不掉, 自然也沒有後續讓我去他那導入TrustView與Windchill整合方案. 還好有這個緣分, 敝人才可靠著TrustView與Windchill一些小伎倆騙吃騙喝, 並得Egg兄禮遇.

但是... 夜路走多總是會見鬼! Egg的恐怖, 不只在他的功力, 而在他追根究柢的研究精神. 大家很少聽說有user會去讀PTC官方的那些動輒數百頁的PDF檔吧? Egg就是那個例外!!!

剛認識的那幾個月, 勉強靠著過去幾個專案的經驗與PTC兄弟的無私分享, 對於Egg提出的問題還勉強達的上來. 誰想到某一天, 接到蛋兄電話, 內容大概是:

Egg: David啊? 我想設定多個Background Server, 那要怎麼弄?

David: 你是要設多個Method Server吧? 你可以參考..

Egg: 不是, Production已經設了2個Method Server 1個Background... 我是想看能不能把Background再多加一個, 看能不能讓Workflow跑快一點..

David: 不會吧? Background只能有一個呀(很有信心! 因為前輩信誓旦旦的這麼說...)!超過一個會出問題 (至於什麼問題 或許前輩有教 總之當時我也不知道會有什麼問題)!!

Egg: 可是你們"System Admin Guide"上有說可以多個?

David: 是嗎(驚嚇)!!! 大概...是新功能吧... 不過有可能PTC不建議這樣用??? (開始硬拗)

Egg:照Guide上說... 好像要分組, 把"Queue"分組(咦? 好像有點印象! 曾經瞄過...), 但是上面寫的看不太懂

David: 唉... 是這樣的! 既然有寫, 應該是有(放棄抵抗)...不過, 手冊通常都模模糊糊(引用某前輩的說法: 幹! 這才是正常的), 有時還有版本的問題... 這樣好了, 我找時間研究看看(見風轉舵中)...

總之, 這是我第一次感受Egg的可怕, 也是催生這個主題的真正原因.

積非成是: "Multiple Background servers"

故老相傳: "Background只能有一個". 我猜, 大部分的顧問都會這麼說. 要不是蛋兄(詳見緣起), 我現在一定還是這麼說. 去年就想寫這個主題, 但知道很花力氣, 所以一直逃避. 然而心裡一直有個疙瘩 . 最後想想畢竟這是個有意義的主題, 終究是寫了.

真相之路蠻曲折的! 至少第一次探索從Egg問起的"Queue-Group"與System Admin Guide裏語焉不詳的暗示多個Background的可能性, 演變到從頭反思Method Sever與Background Server的定義與目的... 幾乎是要發掘真相. 可惜忽略了一個重要線索, 追到後來還是失敗了. 儘管如此, 我覺得這個探詢的過程蠻有趣的, 或許也能延伸出一些討論. 所以把他記在另一篇"有關"只能有一個Background Server"的疑點".

直到去年準備PDMLink9.0 System Admin的教育訓練時, 順便研讀Advanced Deployment Guide. 那時才發現, 此文件裏居然對多個Background Servers的設定有詳細的解釋 (韋爵爺: ㄉ...ㄉ償所望..). 細讀之後. 更覺得其中的設定方法及可能也適用之前的版本. 因此以PDMLink8做測試, 終於證實多個Background Server是可能的.

進入此主題之前請先參閱設定多個Method Server的相關文件或是參考"有關"只能有一個Background Server"的疑點"也可.

Advanced Deployment Guide中有關設定多個Background Servers的介紹節錄如下:

首先是有關啟動Background Server的命令設定, 也就是上次探尋的終點. 簡單來說, 能針對個別Background Server設定啟動命令, 就能夠指定該Background Server負責的Queues. 如此就有機會避開重複執行Queue中工作的問題. 這次文件交代得很清楚: 每個Background Server須要有個自己的名字(Service Name), 啟動指令就是利用這個名字來定義. 格式為: "wt.manager.cmd.(service name)", 定義在wt.properties裡的Property. 所以如果我們要設定兩個Background servers且為它們取了名字: "BackgroundMethodServer_0" 與 "BackgroundMethodServer_1", 那我們就需要 "wt.manager.cmd.BackgroundMethodServer_0" 與 "wt.manager.cmd.BackgroundMethodServer_1"兩個Properties. 至於設定Property的設定值 之前我們見過了, 格式如下:
wt.manager.cmd.(service name)=(Method server's Java command) wt.method.serviceName=(service name) wt.queue.executeQueues=true wt.queue.queueGroup=(Queue-group names) wt.adapter.enabled=false wt.method.minPort=(port number)

上述的(Method server's Java command)基本上就是像 "java -classpath ... wt.method.MethodServerMain" 這樣的東西. 我們可以抄系統預留的Property "wt.manager.cmd.BackgroundMethodServer" 設定當範本, 用$(wt.manager.cmd.MethodServer)就行了. 至於 "wt.method.serviceName=(service name)", 基本上這裡的"(service name)"就是"wt.manager.cmd.(service name)"中的"(service name)". 而 "wt.queue.queueGroup=(Queue-group names)" 不難猜, 是用來指定該Background Server負責的queue groups, 並以","來區隔. 最後, "wt.method.minPort=(port number)", 用來指定該Background Server所使用的TCP/IP port.

以名為"BackgroundMethodServer_0"的Background server為例, 設定如下:

wt.manager.cmd.BackgroundMethodServer_0=$(wt.manager.cmd.MethodServer) wt.method.serviceName\=BackgroundMethodServer_0 wt.queue.executeQueues\=true wt.queue.queueGroup\=default wt.adapter.enabled\=false wt.method.minPort\=3000

看來很完美? 故事還沒完!

試想, 系統怎麼知道有兩個Background Server分別叫作"BackgroundMethodServer_0" 與" BackgroundMethodServer_1"? "wt.manager.monitor.start.BackgroundMethodServer=2" 僅僅讓系統知道需要啟動兩個Background Servers, 並沒有透露其他訊息. 從Advanced deployment guide 中的範例發現 他的"wt.manager.monitor.services"是這麼設的:

wt.manager.monitor.services=MethodServer BackgroundMethodServer_0 BackgroundMethodServer_1

原來如此, "MethodServer", "BackgroundMethodServer_0", "BackgroundMethodServer_1"都是"(service name)"啊! 以前習慣照抄 "wt.manager.monitor.services=MethodServer BackgroundMethodServer"這樣的設定. 從來沒想到系統居然用"wt.manager.monitor.services"裡面定的"service names", 如"MethodServer" 與 "BackgroundMethodServer", 來找到對應的 properties: "wt.manager.cmd.MethodServer" 與 "wt.manager.cmd.BackgroundMethodServer". 所以在這個範例, "BackgroundMethodServer"須以"BackgroundMethodServer_0 BackgroundMethodServer_1" 來取代 如此才能讓系統套用 "wt.manager.cmd.BackgroundMethodServer_0" 與 "wt.manager.cmd.BackgroundMethodServer_1".

以下是我在PDMLink 8上進行測試時的一些畫面:

wt.properties新增的設定


以下為開機後的畫面: 除了Method sever正常啟動外, 真的跑出兩個Background servers.

BackgroundMethodServer_0: Listening port: 3000

BackgroundMethodServer_1: Listening port: 4000

建立一個新的Queue名為"david_01", 隸屬於 "david"這個 queue-group. 另外寫了個小程式塞了個工作進去, 每隔十分鐘會印出"Hello!". 如上面的設定, 所有"david"群組的Queues都是由BackgroundMethodServer_1管的. 果然過一會 "Hello" 出現在這.

再拉一個簡單的流程, 用來證明他會被 "BackgroundMethodServer_0"處理

嘿... 真的耶!

PKI 妙喻 & "向左, 向右, 向前看"

有一回應朋友之邀介紹PKI (Public Key Infrastructure) 之前, 先上狐狗大仙(Google) 那兒晃晃, 看看有沒有善心人士分享, 先頂來用用... 當時找到了一份, 但是章節的結構與描述方式不是很喜歡, 真正採用的部分不多. 但是那份投影片對PKI中公鑰與私鑰(Public & Private Keys)的比喻一直讓我印象深刻, 甚至認為這是目前我聽過最淺顯易懂的比喻. 原文早沒了! 不過因為比喻的妙, 我相信我轉述之後效果也不會太差才是.

那個比喻大概是這麼說的: 既然大家已習慣把密碼學中用來加密解密的關鍵物"Key"具體的想像為日常生活中用來開鎖解鎖的"鑰匙", 所以我們不妨把PKI想像成是一種"特別的鎖". 這種鎖, 有兩把鑰匙: 一把永遠把鎖頭往左轉, 一把則往右轉. 因此用"向左轉"的鑰匙鎖定後, 只能靠"向右轉"的鑰匙把它解鎖. 同理, 向右轉"的鑰匙一樣可以鎖定, 但是得靠"向左轉"的鑰匙解鎖.

要是有人無聊到要研究這把鎖怎麼做的, 或許可想像這個鎖裡面有個拴子, 拴子可左右旋轉. 栓子在正中標示"解開"的狀態, 栓子在左或右都是"鎖定"狀態, 一把鑰匙插入僅可轉左, 另一把也可轉右...喂!!! 醒醒啊! 不要那麼仔細好嗎? 這左轉右轉只是個比喻....








這把鎖怎麼用呢? 一般來說是這麼用的. 鎖的"主人", 擁有其中一把鑰匙, 因為大部分的人是右撇, 所以"向右轉"那一把鑰匙由主人保管. 這就是"PR"的由來, "R" stands for "Right"(這一句是本人唬爛, 笑笑就算... 還蠻像那麼一回事的吧? PR其實是"Private Key(私鑰)"的簡稱) OK, 假設主人持有"向右轉"的鑰匙, 並將向"向左轉"的鑰匙打造"多個備份", 分送給"客人". 主人鎖上的(用"向右轉"的鑰匙), 客人打的開. 主人呢? 用自己那一把"向右轉"的鑰匙一定解不開, 但是一般沒有那麼笨的主人, 留一把給客人的備份不就得了嗎? 但是客人鎖住的只有主人才能開了, 任何客人都開不了!

所以各位發現兩把鑰匙的作用與鎖的功能其實不難了解, 但是要怎麼用呢? 整人... 不會吧? 但是, 現實生活中您看過這種門嗎?

前幾天聽見電視傳來孫燕姿的"遇見"("向左走向右走"), 突然讓我參透幾個PKI不錯的"Use Cases".

假設"金先生"為他的房間安裝了PKI鎖, 自己當然"左/右轉"兩把鑰匙都有囉! 對那位一直好事多磨的真命天女"梁小姐", 當然是要送一把"向左走", Sorry, 更正, "向左轉"的鑰匙囉? 沒事可以請她在金先生出差時去打掃房間, 澆澆花, 餵餵小動物...臨走在再把門鎖上. 所以金先生鎖門, 梁小姐可開. 梁小姐鎖門, 金先生也可開, 幸福吧?

至於"關小姐", 要嘛之前金先生就給了她一把"向左轉"(可能性極高...), 或者事後金先生覺得不好意思或是懷念關小姐的身材(後者可能性比較大...). 然後再打了一把給她.... 日後要是約關小姐到房間獨處時, 也不用怕梁小姐突然闖入... 只要用關小姐那一把, 或自己留的那一把"向左轉的鑰匙鎖門就好了唄? 關小姐鎖的, 梁小姐開不開, 反之亦然.

摩亞大人: 這就是"左右逢源"嗎?

其實, 本文只是為我接下來想寫的一些有關DRM與TrustView方面文章做做暖身, 讓大家對一些望之生畏的名詞減少一些恐懼感. 以上所提, 不過就是些比喻.. 千萬不要太當真, 例如, 不要問我ㄧ些: "梁小姐要是忘了關瓦斯就鎖門離開怎麼辦?" 或是,"梁小姐一進房間就把門反鎖, 等金先生一個月後出差回來剩乾屍一具"...等等奇怪的問題. 就算真正發生了, 我們也只能說誰叫金先生存心不良! 造成悲劇也只能說活該應得, 順便還有些警世的味道. 關PKI鳥事?

ChihLing 's Jasper Integration Demo

說真的, 本來我覺得在Windchill客製頁面, 放個Link指到Jasper Server去把內容秀出來就夠了! 沒想到ChihLing玩的那麼大, 搞起深度整合來了!!! 最重要的是, 整得太漂亮了!!! 連Windchill它媽看到大概都不會懷疑這是和Jasper偷生的...