www.fisc.com.tw ■　17

淺談金融卡「雲支付」服務之安全思維〡本期企劃

淺談金融卡「雲支付」服務之安全思維

黃建隆 /財金資訊公司安控部資訊安全組副組長

一、 前言

金融科技 (FinTech) 的支付創新中，

無現金世界 (Cashless World) 與新興支付

(Emerging Payment Rails)的發展，皆與行動

支付有著密切關係。再者，發展普惠金融已是

全球各國關注的議題，同樣地，建構行動支付

基礎環境，讓社會大眾更便捷地享用各項支付

服務，亦為我國推展普惠金融的重要目標之

一。金融卡「雲支付」服務 (以下稱「雲支付」)

係應用「金融卡」既有規格，結合雲端支付

(Cloud-based Payment)技術所發展的行動支

付應用，對金融科技與普惠金融的推展，均具

相當助益。

二、 目前主要的行動支付概述

隨著全球金融科技發展浪潮來勢洶洶，行

動支付已是兵家必爭之地。目前，行動支付依

其性質，大致可區分為兩大類、3種支付應用

(如表 1)：

(一 ) 具 安 全 元 件 (Secure Element , SE)

類 型 ( 如 圖 1)： 諸 如 Apple Pay、

Samsung Pay、以及採 TSM (Trusted

Service Manager)機制發行之行動金融

卡與手機信用卡等支付應用。安全元件

擁有者為大型的行動裝置廠商或電信業

者，前者安全元件已內建於行動裝置

上，可直接將合作金融機構的卡片虛擬

表 1　行動支付應用方式比較表

行動裝置

應用程式具 NFC 使用條碼

適用作業系統

Android iOS

具安全元件

未具安全元件

1. 掃碼支付

2. 主機卡模擬

18　■ 財金資訊季刊 / No.89 / 2017.06

本期企劃〡淺談金融卡「雲支付」服務之安全思維

化至行動裝置中，雖屬方便，不過僅限

特定廠牌與裝置方可支援使用；後者則

客戶除須將行動裝置換裝 NFC SIM卡

外，尚須至金融卡或信用卡發卡機構申

辦新卡片後，方能透過 TSM下載卡片

至行動裝置上，顯見後者不但受限於電

信業者，且對使用者而言，相關申請流

程殊為不便。

(二 ) 未具安全元件類型：此類型的支付應

用，沒有安全元件硬體的束縛，僅須以

行動裝置應用程式 (APP)，搭配後端伺

服器運作即可，其應用又可細分兩種，

一為使用條碼的掃碼支付應用 (如圖 2)，

如 Android Pay、 LINE Pay、 街 口、

歐付寶、Pi 行動錢包、GOMAJI Pay

及支付寶等；另一為主機卡模擬 (Host

Card Emulation , HCE)技術應用 (如圖

3)，如本文主題之「雲支付」等。依據

圖 2　未具安全元件類型的行動支付－掃碼支付 圖 3　未具安全元件類型的行動支付－主機卡模擬

刷卡機與感應式設備

錢包/數位皮夾

圖 1　具安全元件類型的行動支付

www.fisc.com.tw ■　19

淺談金融卡「雲支付」服務之安全思維〡本期企劃

Gartner預估，HCE的滲透率在 2014

年僅有 5%，2017年為 20%，預估至

2020年將成長為 40%，是未來行動支

付發展與應用的主要趨勢之一。

三、 「雲支付」的技術概述

「雲支付」是將實體金融卡虛擬化至行

動裝置上，虛擬卡片上的卡號為裝置帳號

(Device Account Number , DAN)，亦即代碼

(Token)，非原實體帳號或金融卡號 (Primary

Account Number , PAN)。 依 其 應 用 性 質

可區分為兩類：( 一 ) 近端支付 (Proximity

Payment)、 以 及 ( 二 ) 遠 端 支 付 (Remote

Payment)。不論為何者，發卡機構均是將卡

片敏感性資料，如：主金鑰 (root key)等存放

在安全的雲端伺服器中，再將數把多樣化後之

工作階段性質的交易金鑰 (session key)，下

載至行動裝置供交易使用；於使用時，須輸入

密碼解開交易金鑰後，方能據以產生正確的交

易驗證碼供核驗。其次，若交易金鑰過期或用

罄，則須再與雲端伺服器連線補充交易金鑰。

因此，若交易金鑰充足且未過期，進行近端支

付時，行動裝置無須連網即可交易，反之則

要。另一方面，遠端支付部分，亦須連網才可

使用。

就交易流程而言，基本上與原本晶片金

融卡或行動金融卡交易大致相同，惟差異處

為：行動裝置上並非存放固定不變的交易金鑰

(00C6或 00C8)，改採每次均以不同的交易金

鑰產生交易驗證碼，且交易金鑰各有其效期及

效期驗證碼；發卡機構每次計算交易驗證碼所

使用的交易金鑰亦不同、且發卡機構需再核驗

交易金鑰之效期及效期驗證碼。

「雲支付」的近端支付係以 Google之主

機卡模擬技術為基礎，具 NFC的行動裝置上

之應用程式可模擬成一張卡片，使用者再以該

行動裝置與感應式刷卡機進行 NFC交易。此

技術將原本從 NFC介面進來的訊息轉導到一

個行動裝置上的應用程式，而非安全元件，惟

目前僅適用於 Android 4.4以上版本的行動裝

置。Android裝置具安全元件與主機卡模擬技

術之差異，請參考圖 4與 5之說明。

圖 4　具安全元件與主機卡模擬技術之架構簡圖

Android 裝置 Android 裝置

HOST CPU

NFC控制器

感應式端末機 紅線表示 NFC訊號 紅線表示 NFC訊號感應式端末機

安全元件 (SE)

具安全元件的架構 HCE的架構HOST CPU

NFC控制器

20　■ 財金資訊季刊 / No.89 / 2017.06

本期企劃〡淺談金融卡「雲支付」服務之安全思維

圖 5　傳統具安全元件與主機卡模擬技術之架構圖

「雲支付」的近端交易係透過 NFC的方

式，端末機與行動裝置上卡片的互動，基本上

與感應式金融卡或行動金融卡一樣，均是讀取

卡片上的 1003基本資料檔，使用 00C8金鑰

產生交易驗證相關資料於 1090檔案，再回傳

相關交易資訊與交易驗證碼供發卡機構核驗

(如圖 6)。

圖 6　近端交易端末機與卡片互動流程圖

www.fisc.com.tw ■　21

淺談金融卡「雲支付」服務之安全思維〡本期企劃

「雲支付」的遠端支付部分係以行動裝置

上的應用程式為基礎，應用程式 (Wallet APP)

可模擬成一張卡片或交易用的應用程式，亦可

視為讀卡機插上卡片供其他認可的行動裝置應

用程式選擇卡片進行交易。交易應用程式與行

動裝置上卡片的互動，基本上與接觸式金融卡

或行動金融卡遠端交易一樣，均是讀取卡片上

的 1001基本資料檔，使用 00C6金鑰產生交易

驗證相關資料於 1080檔案，再回傳相關交易資

訊與交易驗證碼供發卡機構核驗 (如圖 7)。

四、 「雲支付」的安全要求

「雲支付」的技術如前述，是未具安全

元件的支付類型，與過去安全元件具備高強

度之防護機制，且存放固定金鑰有所不同。因

其技術特性不同於具安全元件的支付類型，故

對於安全的要求已不適用以過去晶片通過的

Common Criteria等級套用其上，取而代之應

是以一些補償機制來控制風險，透過多層次的

防護機制 (Layered Security)與風險控管，以

降低衝擊與發生機率，亦即降低風險。

現行行動裝置應用程式除須避免基本的

OWASP Top 10 Mobile Risks外，尚須建構

多層次的安全防護思維，藉由金鑰的安全性機

制、發卡機構的風險控管來減少卡片資產的價

值，以降低支付機制遭受破解的風險；再輔以

行動裝置應用軟體的安全強化、裝置綁定、後

端交易控管等，以減少支付機制遭受破解的發

生機率。若風險 = 發生機率 x衝擊，則藉由多

層次安全防護之建構，即可有效控制風險由原

本的高危險區域，轉移至低風險區域，緩解支

付機制遭受破解的影響 (如圖 8)；相關說明分

類如下：

圖 7　遠端交易端末機與卡片互動流程圖

22　■ 財金資訊季刊 / No.89 / 2017.06

本期企劃〡淺談金融卡「雲支付」服務之安全思維

圖 8　「雲支付」安全思維概念圖

1. 金鑰的安全性

(1) 下載至行動裝置的交易金鑰，須為經後端

雲端平台多樣化後的交易金鑰，每次交易

使用不同的交易金鑰，且僅可供乙次交易

使用，用過即作廢。

(2) 下載至行動裝置的交易金鑰，均有密碼保

護機制與效期驗證機制，亦即於後端雲端

平台以密碼與交易金鑰運算加以保護，再

下載至行動裝置上。故需輸入正確密碼

方可解出正確的交易金鑰供產生交易驗證

碼，且每一把交易金鑰，發卡機構會檢查

其效期與效期驗證碼，以確保交易金鑰的

安全性。

(3) 交易金鑰更新時，必須可透過行動裝置應

用程式註冊時之認證資訊，完成行動裝置

應用程式與後端雲端平台間的相互認證，

後端平台必須確認行動裝置應用程式綁定

行動裝置之正確性，且須要求進行持卡人

驗證，以強化交易金鑰更新的安全性。

(4) 除了行動裝置應用程式透過 Https與後端

平台連結外，交易金鑰更新過程應啟動另

一個通道，以確認下載之合法性 (如：透

過推播訊息 )，並提高攻擊者偽冒進行交

易金鑰更新之難度。

(5) 交易金鑰更新時，須進行行動裝置端與雲

端平台交易之比對，發現交易紀錄異常

(如：行動裝置端包含某些雲端後台已驗

證之交易紀錄 )，則應暫時停止該卡片之

使用，並進行持卡人之照會處理。

(6) 遠端交易所使用的交易金鑰之控管機制應

較近端交易更為嚴謹，如：每次下載的金

鑰數量較少、效期較短等。

2. 發卡機構的風險控管

發卡機構得衡量自身風險的承擔能力，據

以進行風險控管作業，如：設定單筆交易限額、

www.fisc.com.tw ■　23

淺談金融卡「雲支付」服務之安全思維〡本期企劃

每月交易限額等。

3. 行動裝置應用軟體的安全強化與裝置綁定

(1) 須納入程式碼混淆技術：因行動裝置的程

式是完全暴露於客戶端，如何防範攻擊者

於可取得執行碼的前提下，輕易進行逆向

工程，進而取得所有程式的邏輯，甚至

透過程式的再造 (注入非法的程式碼 )，

產生使用者無法辨識的惡意程式，或透過

惡意之程式碼進行相關之攻擊。採混淆

(obfuscate)技術進行防範，可將程式碼

中的變數或函數名稱等轉換成另一個較無

意義的字串，或將執行流程混淆，經過處

理後的程式碼，其正向執行的邏輯及流程

並不會有所改變，但可防範蓄意的逆向工

程攻擊。

(2) 須納入白箱加密法 (White-box Cryptography,

WBC)：確保儲存在客戶端的交易金鑰及

與後端認證金鑰的安全性是一項重要課

題。保護交易金鑰，可防止攻擊者自被攻

擊者的行動裝置取得或大量蒐集此金鑰的

資訊，而於其他的設備上進行非法交易。

保護與後端認證金鑰，是防止偽冒合法客

戶向後端平台要求取得交易金鑰的資訊。

白箱加密的主要目的，則是在加解密運作

過程，完全暴露在使用者可觸及的環境下

(視為白箱，與傳統亂碼化設備無法任意

窺探不同 )，透過邏輯及資料的混淆，保

護加解密金鑰或其過程的安全性。

(3) 須可於執行狀態驗證其程式之完整性，並須

確保未經授權之竄改與更新、安裝與更新之

安全。此外，亦須確保行動裝置應用程式為

最新版本，且不允許使用者返回舊版本，以

維護行動裝置應用程式自身的安全性，及具

備正確的行動裝置應用程式版本。

(4) 若偵測到攻擊行為，行動裝置應用程式須

有機制回報後端平台，以利進行相關的防

護措施。

(5) 行動裝置綁定：行動裝置應用程式註冊

時，應可設定唯一的識別碼，並透過手

機簡訊 (該電話號碼須為客戶原於臨櫃或

eATM等通路登記之門號 )或電子郵件確

認其必要聯絡資訊之有效性。每一註冊之

行動裝置應用程式應綁定特定之行動裝

置，且應建立與後端伺服器 (雲端平台 )

相互認證所需之秘密資訊，此認證資訊必

須被安全的儲存於行動裝置應用程式端，

並應適時檢核綁定裝置之正確性。

(6) 敏感資料 (如個人化資料等 )須採適當之

加密機制 (如白箱加密法 )。加密後的資

料應綁定原資料儲存之硬體設備，也就是

設備所儲存的敏感性資料，無法複製至另

一設備繼續使用。相關資料不再使用時，

須安全地移除，若為暫存的敏感性資料，

使用後，應立即移除。

4. 後端平台交易控管

(1) 卡片生命週期的管理

A. 卡片核發：金融機構核發雲端行動應用

卡片時，須進行持卡人身分識別與驗證

(Identification & Verification , ID & V)。

B. 卡片的中止：由雲端平台中止某張卡

片的使用，中止後之裝置帳號不可再

被使用。

C. 暫停：由雲端平台暫時停止雲端行動

應用卡片使用。

D. 恢復：由雲端平台恢復雲端行動應用

卡片使用。恢復前，金融機構應透過

適當的方式，確認持卡人的合法性。

24　■ 財金資訊季刊 / No.89 / 2017.06

本期企劃〡淺談金融卡「雲支付」服務之安全思維

(2) 風險的控管

A. 交易 (卡片 )錯誤的控管：須設定可

容忍交易錯誤次數之邊界值，當某張

卡片交易驗證錯誤次數到達原設定之

邊界值時，將自動中止該卡片之使用。

B. 持卡人驗證錯誤的控管：須設定可容

忍密碼錯誤次數之邊界值，當持卡人

驗證連續累積錯誤次數到達原設定之

邊界值時，必須暫時停止該卡片之使

用，直到確認持卡人後，才可開放其

使用。重新恢復持卡人使用時，既有

之交易金鑰必須廢止，並重新下載所

有交易金鑰。

C. 交易序號與交易金鑰的控管：後端平

台於交易驗證時，須確認目前的交易

序號對應的交易金鑰，已經下載至行

動裝置端，且為尚未使用過或停用之

交易金鑰。交易驗證碼之核驗仍套用

原交易序號需大於發卡機構既存交易

序號的判斷原則，以防止重送交易之

攻擊 (replay attack)。

5. 作業平台安全

(1) 行動裝置應用程式於每次啟動時，均須檢

查該裝置是否被破解取得系統最高權限

(root)，若是，則應強制關閉應用程式，

以確保作業平台的安全性。

(2) 偵測與回報行動裝置所處的執行環境是否

為偵錯模式 (debug mode)，以確保執行

環境的安全性。

6. 通訊安全

行動裝置應用程式與後端平台的通訊皆採

https加密連線，且須為 TLS 1.1(含 )以上版

本，以確保資料之隱密性與完整性。

五、 結語

據 Gartner資料指出，行動支付市場交

易金額自 2013年的 2,430億美元，成長至

2015年的 4,400億美元，預計 2018年時，

將達 9,180億美元。不過，時下幾個當紅的

Apple Pay、Samsung Pay、Android Pay 等

皆屬 NFC支付模式，而這類支付模式全部加

總僅占極小的市場規模，從 2015年的 3%，

至 2018年預估也僅約 6%，其餘 9成以上皆

屬非 NFC的支付模式。易言之，目前業界行

動支付的趨勢，以未具安全元件的行動支付為

市場的主流。

「雲支付」雖是 NFC的支付模式，惟因

兼顧便利性、普及性與安全性的金融科技業

務，透過多層次的安全防護，強化行動裝置應

用程式的安全性、裝置綁定與後端雲端平台的

控管，並透過交易限額等降低交易風險，這是

行動支付應用上，於安全性與彈性間取得一個

最佳平衡點的方案。

※參考文獻 /資料來源：1. Google HCE (ht tps : / /developer.

android.com/guide/topics/connectivity/nfc/hce.html)。

2. Smart Card Alliance (http:// www.smartcardalliance.org)。

3. OWASP Top 10 Mobile Risks (https://www.owasp.org/index.php/OWASP_Mobile_Security_Project)。

4. 金融資訊系統概要設計規格書 -附錄五晶片卡共用系統規格 【附件十四】雲端支付應用規格書。