請問自然人憑證相關驅動程式是否能以開放授權釋出？

wiselike profile-audreyt
#1

https://www.inside.com.tw/2017/06/15/digital-signature-certificate 提到：

  1. 自然人憑證的 HiPKI Local Server 在本機傳輸資料時無加密，實在是有安全上的疑慮。比較起來，反而是利用雙因子認證後，下載加密後的數位憑證，整個過程比較安全。
  2. 中華電信所開發的自然憑證卡雖然號稱遵守國際標準，但是其實有用了幾個很特別的自訂指令，根據友人側錄的結果，一開始需要有四道特別的 APDU command ，之後才會進入標準的操作程序。
  3. 相關基礎軟體必須以開放原始碼釋出，以利相關廠商繼續發展。
1個讚
#2

  1. 在現行 HiSecure 的 http://localhost:61161 上，HTTP localhost loopback 其實不經過 PHY 層（若要攻擊，需要 local arbitrary code execution privilege）。但既然自然人憑證現在已經是 Combi Card，那 In-browser API (Web NFC 之類) 確實可能更安全一些。

  2. 新版的 HiPKI 在發包時，無論用什麼技術，會以開源釋出為前提規劃（這可能要一年左右）。

  3. 在過渡期間，可參考社群開發的開源實作： https://github.com/orsonwang/Taiwan_CDC_RI 。該實作中提到的 PIN verify 函數參數值，如果能提前釋出，也會一併在這裡更新。

1個讚
#3

關於提問中的「四道 APDU command」，謹附上 2017-07-14 逐字稿相關說明：

中華電信王文正：謝謝政委給我發言的機會，我是中華電信王文正，我們公司就是承做自然人憑證系統的系統，算是當事人之一，所以我想說藉這個場合做一點說明。

開放源碼的朋友們對於自然人憑證能夠讓他們鑽入到多深去下一些command，是有一些期望，其實我們也做過溝通。提問者說「不相容規範」我覺得要澄清，因為自然人憑證的格式是ITU-T ISO X.509標準，如果沒有照這個標準，不可能這些 browser 願意把我們放入他們信賴清單裡面。

第二點是說，在卡片的 interface 的國際標準上，他其實就等同於就像是要買一個裝置在電腦用，他的地位等同於像是一個驅動程式。

所以對一個 vendor 來講，他有義務提供一個符合業界標準的驅動程式。那目前自然人憑證提供的是在 Windows上、在 macOS 上、在 Linux 上都有驅動程式，之前在 Unix Workstation 也有提供。

那另外就是說，這個 API 其實每年內政部都舉辦相關的 training workshops，讓邀請各政府機關的或是有興趣開發自然人憑證的廠商來參與，那這些 API 其實是免費的，你不用拿任何費用出來就可以取得這個 API，所以他基本上是跟隨國際標準的。

至於開放源碼的朋友希望用更底層的例如說 APDU command，就是跟 IC 卡溝通的機器語言去做溝通。我們事實上也會盡量提供資訊，之前跟一些開放源碼的朋友，我們之前瞭解需求後，也給他們相關資訊。

至於早上柏鋒兄也有提到，某些指令是加密的。我要特別說明：因為設計上你要把這些 PIN code 送到 command，我們會覺得說這一段是要保護你 PIN 碼不會被 tapping、被側錄走，所以在電腦傳送到晶片的這一段，我們才會做加密處理。這是要保護用戶，絕對不是說故意讓你不能用開放的 APDU 去下這些指令。

不過，既然我們也瞭解說，開放社群的朋友希望能夠從更底層、有彈性的去運用自然人憑證的卡片，這部分其實我們也在納入考量。未來改版後，在安全的前提下，可以用更開放的程度去做一些考量。

我想有一些送的資料，這部分我們還是要做一些注意，提供廠商有責任要注意，我要確保這張卡片在使用是安全的。所以我很高興說這個朋友提出這個意見，讓我們在這個場合做一個澄清，謝謝。

唐鳳：這個是一個滿技術上的問題。但是技術背後也是有價值判斷的。像是最近 W3C 在吵要不要讓線上串流影音的東西在瀏覽器中間有一個機制，無法去側錄像 Netflix 在播的影片，這事實上雙方聲量都很大，論述都非常完整，有空可以看一看。

這個跟今天討論的自然人憑證能不能讓不同 driver、要不要有開放源碼的實作，有很多好的論點。要的話，我覺得有一個好論點，就是會讓大家更相信這套系統、可以看到他技術的細節。我相信我們所有論點都應該要考慮進去。

1個讚
#4

關於「AES key 若在合理範圍內利用，應未違反著作權法之意旨」的主張，中華電信回應意見如下：

  1. HiCOS IC卡及其API皆是中華電信投入多年研發的智慧結晶，也感謝政府多年來的支持，政府GPKI各專案提供我國自主研發的產品舞台，中華電信願意支持外界對於開放自然人憑證IC卡之PKCS#11 API原始碼的以上訴求，惟本公司也堅持應在符合智慧財產權及著作權保護的原則下，才能進行對外的揭露。

  2.  目前政府GPKI各專案與中華電信的合約皆僅止於取得憑證IC卡PKCS#11 API之使用權，而本公司也克盡承包廠商之責任與義務，也協助解決開發者在使用API所遇到的問題，促使我國PKI-enabled應用系統得以蓬勃發展。若基於以上外界之訴求，政府進一步希望對外揭露自然人憑證IC卡之PKCS#11 API原始碼，建議應由政府於專案預算中編列適當的經費購買對外揭露自然人憑證IC卡PKCS#11 API原始碼的權力，始能對外進行揭露。至於取得原始碼的權利範圍(例如使用、重製、公開、散布、修改等)、預算等議題建議在採購前先溝通範圍。

  3. 至於，外界目前所稱以逆向工程還原之AES Key，應為本公司置入於HiCOS IC卡PKCS#11 API中，用來將用戶PIN碼亂碼化所使用之金鑰，其目的是為了避免PIN碼在經由應用程式傳送至IC卡晶片的過程中，被以明文的形式側錄。此AES Key為本公司HiCOS IC卡PKCS#11 API程式原始碼之一部分，建議由政府取得原始碼之適當是使用權及再授權的權利之後，再對外公開才是符合智慧財產權及著作權的正規做法。
1個讚
公部門智慧卡 GNU/Linux 作業系統支援抓蟲串
#5

如果 PIN 輸入在同一個機器上加密沒意義吧，直接在輸入端側錄就好了

#6

雖然以後晶片身分證出了之後自然人憑證的用處應該是會急速下降，但我還是有疑問。
中華電信回應的這三點簡單說就是中華電信不想免費釋出原始碼，但我好奇的是，卡片本身難道也是中華電信開發的? 政府只要釋出卡片APDU命令溝通方式，剩下大家自己開發就好了，不是嗎?

另外https://github.com/orsonwang/Taiwan_CDC_RI 的readme上面2016/12/09 Note的內容也讓人滿臉問號，pin碼用SHA256 Hash過，為什麼會成為無法釋出PIN verify function的原因?
…
更新
經過我詢問該repo作者，SHA256是誤植，是上面回覆的AES KEY 是屬於CHT的智慧產權的原因，
但這也太扯了，一個國家的卡片的溝通方式掌握在私人公司手上? 合理嗎 ?

保護PIN不被側錄這件事 上面那位也說了，這實在不是理由。
當安全性是建立在程式碼不可被反組譯上的時候，那就等於沒有安全性，因為沒有程式碼無法被反組譯，這個您一定非常了解的，真正的安全性應該是即使開放原始碼也有達到需求上安全要求才是。

#7

Sorry, that’s my bad(Typo for years). The password is not SHA256 hashed. It is AES encrypted.

#8

AES Key 能不能成為著作權標的這點可能要上法院才能確定，但據我所知單純數字型號是沒辦法申請商標的。

第 10-1 條
依本法取得之著作權，其保護僅及於該著作之表達，而不及於其所表達之
思想、程序、製程、系統、操作方法、概念、原理、發現。

因為我不曉得 Key 這種東西到底表達了什麼，所以我主觀認為他應該不受著作權法保護。

中華電信開發的原始碼如果政府在當初合約並沒有簽訂原始碼授權，只有簽訂使用和二進位檔的權利時確實不能要求中華電信開放原始碼，雖然這應該要檢討當初簽約者是不是有少考慮了什麼。

但是讀取自然人憑證內的資料的方式應該是國家標準，民間廠商依其標準實作，標準本身應視為命令，因此

第 9 條
下列各款不得為著作權之標的︰
一、憲法、法律、命令或公文。
... ... 
前項第一款所稱公文，包括公務員於職務上草擬之文告、講稿、新聞稿及
其他文書。

標準本身不應該被視為智慧財產權保護之標的，應該被公開。
中華電信自行研發之原始碼可能效能比較好或者是自己有其他加速用的演算法、架構、資料結構，可以不公開。

公開程度必須要讓一般有能力開發的廠商依循政府標準進行實作。

2個讚