余樂 張鵬 陳園園
(南京熊貓信息產業有限公司 江蘇省南京市 210002)
在“互聯網+”時代大背景下,國內軌道交通自動售檢票系統(AFC)新技術迅速發展,各個城市的軌道交通公司不斷嘗試引入新型支付模式,以豐富地鐵的票務支付形式,為乘客提供更便捷的出行服務。于是二維碼電子乘車碼技術方案應運而生成,它有效解決了地鐵售檢票系統存在的購票效率低、客流高峰期排隊購票時間長、車票單次使用成本大等問題。
乘客只需憑借移動應用客戶端(手機 APP)生成的二維碼即可實現地鐵“刷碼過閘”,便可以實現快速過閘的便捷出行體驗,加快了地鐵客流的流通速度。
根據適用場景以及發起方式的不同,本文主要闡述“被掃模式”下,二維碼乘車碼的關鍵技術,從二維碼設計、要點、創新等方面進行了闡述,提出了城市軌道交通互聯網票務系統二維碼乘車碼的設計方案及理念。
(1)城市軌道交通互聯網票務系統要求采用實名制,所有接入互聯網票務的移動應用均需遵循互聯網票務實名制安全要求,以確保城軌互聯網票務運營的安全。
(2)在實名制的前提下,采用信用消費模式,通過后臺行程匹配及計費來實現先乘車后付費。
(3)以“開放包容、互利共贏”為理念,支持多個業務機構或支付渠道接入。
(4)采用雙脫機方案為主,在網絡及相關條件具備且城軌業主特別要求的前提下輔以聯機驗證模式。
二維碼乘車碼由二維碼頭、行業數據域、用戶數據域組成(見圖1)。
2.1.1 二維碼頭
二維碼頭主要用于對二維碼數據結構進行闡述,用于描述結構版本、二維碼類型、城市標識、算法標識等。
2.1.2 行業數據域
行業數據域中數據由城市軌道交通互聯網票務系統提供,主要用于對二維碼電子乘車碼的通用業務限制以及對這些業務數據的授權使用有效期及簽名。行業數據域主要包含但不限于:用戶標識、二維碼有效期、應用標識、序列、用戶公鑰、行業數據簽名等。
2.1.3 用戶數據域
用戶數據域由二維碼電子乘車碼合作方的移動應用端(如:地鐵官方APP、支付寶、微信等)生成。用戶數據域包括具體特定二維碼標識、行業標識數據以及移動應用方對這些數據的簽名。用戶數據域主要包含但不限于:二維碼狀態、二維碼憑證號、生成序列、生成時間、用戶數據簽名等。

圖1:二維碼乘車碼數據組成

圖2:二維碼數據關系
二維碼乘車碼中數據生成關系見圖2。
二維碼電子乘車碼中行業數據域數據由城市軌道交通互聯網票務系統發行,并對其數據進行加密或簽名。該數據由移動應用客戶端向移動應用后臺發起請求,再由移動后臺向城市軌道交通互聯網票務系統發起申請,請求結果依次返回至移動應用客戶端。
用戶數據域數據由移動應用客戶端按照約定規則在客戶端本地生成,利用預置用戶私鑰對用戶域數據進行簽名。
待行業數據域數據與用戶數據域數據組織完畢后,由移動應用客戶端按照數據內容,遵循二維碼電子乘車碼結構生成并展現二維碼。

圖3:二維碼業務模型

圖4:二維碼乘車碼對比圖
本文中二維碼電子乘車碼,可以同時支持不同的二維碼業務合作方與城市軌道交通互聯網系統共同聯合發碼。城市軌道交通互聯網系統可以通過二維碼中應用標識,可以完成對用戶數據快速識別、分類、請款及清算的工作。
城軌官方APP 在支持二維碼電子乘車碼基礎上又可以與不同支付機構進行對接(如:銀聯、支付寶、微信等),可以為乘客提供便捷的支付選擇及支付體驗。
詳細二維碼業務模型可參見圖3。
在《GB/T18284-2000 快速響應矩陣碼》標準中對二維碼編碼的關鍵特征有兩個影響因子[1]。
3.1.1 編碼字符集的選擇符合規定交通行業使用的二維碼編碼方式有兩種:
(1)字符數字型數據(數字0~9;大寫字母A~Z;9 個其他字符:sapce,$,%,*,+,-,.,/,:);
(2)8 位字節型數據(ASCII 字符集)。
3.1.2 糾錯的選擇
4 種糾錯等級,可恢復的碼字比例為:
L 7%
M 15%
Q 25%
H 30%
下文以工程應用中的二維碼數據為樣例,在同等信息量基礎上分別采用不同編碼字符集和糾錯等級對二維碼編碼方式進行對比。如圖4所示。
根據表1的對比,在二維碼編碼方式上,建議采用8 位字節型數據編碼方式,糾錯等級選擇L(7%),這樣生成出的二維碼密度最低,識別最快,更能適應軌道交通快速識別與通行的需求。
在城市軌道交通AFC 系統中,通常采用對稱算法3DES 算法、非對稱算法RSA[2]或SM2 算法[3]來保證數據安全。
3DES 算法是一種國際上使用最廣的商用密碼算法,在軌道交通行業通常用于保證地鐵單程票數據安全。
SM2 算法和RSA 算法都是非對稱公私鑰密碼算法,其中SM2屬于國密算法,RSA 屬于國際算法,通常用于保證非接觸票卡電子現金業務及文件傳輸過程中的數據安全,通過表2的對比,SM2 算法更優于RSA 算法。
為了適應不同業務場景需求,行業數據域簽名算法應支付對稱3DES 算法和非對稱國密SM2 算法,具體選擇可以在業務實現時根據城軌業主需求確定。用戶數據域簽名采用非對稱國密SM2 算法。其中行業數據密鑰應由互聯網票務來維護,用戶密鑰由移動應用來維護。
3.3.1 二維碼生成
移動應用客戶端打開乘車碼功能時,由移動應用后臺向城市軌道交通互聯網票務申請行業授權數據,由城市軌道交通互聯網票務利用其密鑰系統通過對稱3DES 算法或非對稱SM2 算法對行業數據域數據簽名,簽名數據由用戶標識、二維碼有效期、應用標識、序列、用戶公鑰等組成。
行業數據申請可以一次申請多條,授權有效期內逐條使用;或一次申請一條,授權有效期內多次使用。當授權有效期過期后,需要重新再次申請。
當移動應用客戶端本地行業數據在有效期范圍內或已重新申請到行業數據,應在客戶端本地生成用戶數據,并通過非對稱SM2算法對用戶數據進行簽名。簽名后按照二維碼格式要求,生成并展示二維碼。
其中行業數據如采用對稱3DES 算法,簽名數據應為3DES 對行業數據進行MAC 計算后結果;如采用非對稱SM2 算法,簽名數據應采用行業數據私鑰對行業數據進行簽名后的結果。這兩種密鑰受互聯網票務系統保護。
用戶數據簽名應為移動應用客戶端中私鑰對用戶數據簽名后的結果,私鑰應與行業數據中用戶公鑰對應。該密鑰應受移動應用合作方保護,應做到一用戶一密鑰,定期更新。
3.3.2 二維碼驗證
二維碼電子乘車碼在AFC 受理終端上使用時應對行業數據、用戶數據簽名進行校驗,確保二維碼數據安全。

表1:編碼方式對比說明

表2:非對稱算法性能對比
行業數據如采用對稱3DES 算法,終端校驗應采用地鐵PSAM卡完成行業數據簽名中的MAC 校驗工作。PSAM 卡中密鑰應與城市軌道交通互聯網票務中密鑰保持一致;如采用非對稱SM2 算法,終端中應采用行業數據公鑰來完成行業數據簽名校驗工作,終端中行業數據公鑰應與城市軌道交通互聯網票務系統中行業數據私鑰保持一致。
用戶數據域中簽名應由二維碼中用戶公鑰完成校驗工作。
軌道交通的交易為典型的復合消費類型,二維碼的成功使用關鍵在于業務閉環,即進站時只做相關信息記錄,出站時互聯網票務系統對進出信息進行行程配對,配對成功后完成行程費用計扣申請,由業務合作方對行程費用進行計扣。由于二維碼業務對AFC 系統網絡要求較高,在不同網絡狀況場景下,應輔以路網中央、車站、本機多級查重手段,確保二維碼在終端設備上不被重復使用。
移動客戶端打開二維碼時應及時刷新,可以對行業數據及用戶數據同時刷新,也可以只對用戶數據刷新。
進出站時由終端設備對二維碼信息采集,采用路網中央及本機雙重查重方式,確保二維碼在地鐵分時分段復合消費場景下行程唯一性,并在互聯網票務系統中完成行程信息登記,如行程無異常且符合城軌相關票務管理規定應予以放行。應準實時將用戶行程信息推送至移動客戶端,以增強用戶體驗。
當進站時遇到終端設備與互聯網票務系統網絡中斷,可以根據票務管理規定提示乘客更換使用通道(可能為單機網絡故障)或采用其他乘車方式,也可以先對乘客放行,待網絡恢復后再將用戶行程推送至互聯網票務系統。
出站時遇到終端設備與互聯網票務系統網絡中斷,應降級為車站級查重,以解決乘客在本站多次重復使用的現象,并以乘客放行為優先的原則,確保乘客正常出站,不在車站內長時間逗留,待網絡恢復后再將用戶行程推送至互聯網票務系統。
當互聯網票務系統接收到用戶出站行程,應準實時完成用戶行程配對,并根據配對信息完成行程計費請款工作,同時將相關信息推送至移動客戶端。
將數據區分為行業數據和用戶數據,城軌企業與業務合作方共同聯合發行二維碼,可以支持與多個業務合作方合作。技術實現更簡單、系統更安全、穩定、未來業務擴展性、適應性更強。
行業數據采用一次授權多條,逐條使用或一次授權一條,多次使用的方式,使用時用戶側可實現離線生碼。二維碼在AFC 受理終端校驗時,建議采用預置PSAM 卡對二維碼數據離線校驗。能夠保證交易速度小于200 毫秒,用戶體驗度不低于單程票。
采用路網中央、車站、本機多級查重手段,有效解決多種不同網絡狀態下二維碼的使用問題,能夠有效規避二維碼不具備回寫的顯著缺陷,確保二維碼不被重復使用。
在行業數據中設有發行序列、用戶數據中設有使用序列,在使用中能夠為業主提供用戶行程序列化管理的能力,能夠輔助用戶行程OD 配對及單邊交易分析,實用性更強。
在智慧城市建設的背景下,二維碼電子乘車碼已成為城市軌道交通移動支付方案的典型代表。本文對二維碼乘車碼編碼方式的研究,對于未來行業二維碼技術標準化及后續新建城市具有借鑒和參考意義。