技術交流

跨瀏覽器電子憑證問題 交給 uPKI 資安安控元件

微軟旗下的 IE 瀏覽器已逐步被使用者淘汰,屆時在 IE 上所使用的 ActiveX 套件,將無法在其他新式瀏覽器上使用,如:Chrome、Firefox、Opera 或 EDGE,基於安全性考量,不再支援 ActiveX 等相關 NPAPI( Netscape Plugin Application Programming Interface;網景外掛模組應用程式介面)元件的呼叫。但如自然人憑證與金融憑證的相關 PKI(Public Key Infrastructure)資安應用,仍然有存在的必要性,uPKI(ubiquitous Public Key Infrastructure)將是 PKI 資安控管暢行各大瀏覽器的關鍵!

瀏覽器技術:從 NPAPI 過渡到 PPAPI

1995 年由網景公司提出了 NPAPI 標準,制訂了一連串瀏覽器的模組介面。NPAPI 的用意為可直接存取系統端 API (Application Programming Interface)的介面,來達到由網頁端來控制 Client(用戶端)如讀卡機的聯繫。然而在 Chrome 瀏覽器推出後,Google 重新制訂了一套名為 Pepper Plugin Application Programming Interface(簡稱 PPAPI)標準,將所有的系統呼叫都放進沙箱內執行以增進安全性,時至今日幾乎所有的新式瀏覽器皆支援 PPAPI 標準,然而,PPAPI 並不含讀卡機的相關介面制訂,Google 則是制訂了另一套名為 Native Messaging 的 plug-in(插件)技術來處理。

停止支援 NPAPI
Chrome 發佈停止支援 NPAPI 標準。(圖片來源:Chromium Blog

瀏覽器 Plug-in 方案 成為廠商維護資安夢魘

在各大新式瀏覽器的設計中,因安全考量在讀取 Client 端讀卡機設備技術上,各自制訂了 Native Messaging 技術,透過 JavaScript、HTML5 與 JSON,來驅動安裝在自身瀏覽器上的 Plug-in,藉此取得與 Client 端的硬體聯繫。

Firefox Native Messaging
Firefox Native Messaging 流程示意圖(圖片來源:Mozilla MDN)

Native Messaging 技術在 Chrome、Firefox 或 EDGE 都有各自的實做,但對開發廠商而言卻是個無止盡的維護夢魘,因為 Plug-in 並沒有統一的規範,也就代表每一套瀏覽器,都需要使用者另外安裝一套相對應的 Plug-in,才能實現在不同瀏覽器上都能使用安控元件的目的。

uPKI 讓資安控管在不同瀏覽器暢行無阻

為了實現跨瀏覽器的元件應用,我們嵌入了一塊輕量級獨立服務框架,用來與本機端硬體進行聯繫。只要在使用者端的系統平台上建立服務,並使用一個埠號來監聽請求,如此網頁端只要透過 HTTP(HyperText Transfer Protocol;超文本傳輸協定)呼叫,如 POST、GET、PUT、DELETE 等方法,就可與撰寫在獨立服務上的函式進行互動,可稱之為 Local Service 技術。透過 Local Service,可由本機端任何具備傳輸 HTTP 呼叫的載體來呼叫獨立服務,同理也可應用在所有瀏覽器上,如此一來,資安控管便能在不同瀏覽器暢行無阻。

uPKI Local Service
uPKI Local Service 技術示意圖
閱讀更多