技術標準

技術標準 SSL/TLS (1)

教學目標

初步了解 SSL 和 TLS 安全協定的基本概念。

重點概念

基本介紹

安全通訊協定 (Secure Socket Layer,SSL) 和傳輸層安全協議 (Transprot Layer Security,TLS) 皆是安全協定,主要目的在於提供安全的網際網路通訊。SSL 目前已經普遍應用於 HTTP 連線,主要是以「HTTPS://」網址開頭進行連線,目前 SSL 3.0 主要是在 1996 年就進行定義,但是在 2014 年 Google 就發現 SSL 3.0 的設計缺陷,將會導致 SSL POODLE 攻擊,因此禁用 SSL 3.0 而建議採用 TLS 安全協定,至於相關安全機制的演算法主要可分為金鑰交換、加密和資料完整性三大部份。

金鑰交換演算法

演算法 SSL 3.0 TLS 1.2
RSA
DH-DSS
ECDH-ECDSA

加密演算法

演算法 SSL 3.0 TLS 1.2
AES 不適用 安全
DES 不安全 不適用
RC4 不安全 不安全

資料完整性演算法

演算法 SSL 3.0 TLS 1.2
HMAC-MD5
HMAC-SHA1
HMAC-SHA256/384

處理流程

接著 SSL 安全協定的處理流程主要有九步驟,分別為:

  1. 客戶端傳送 Client Hello 訊息將相關資訊發送給伺服器。
  2. 伺服器收到訊息進行確認之後將傳送 Server Hello 訊息給客戶端。
  3. 伺服器透過 Certificate 訊息將本身公錀的數位憑證傳給用戶端。
  4. 伺服器傳送 Server Hello Done 訊息,通知客戶端協商已結束,準備開始進行私密金鑰交換。
  5. 客戶端驗證憑證合法之後,透過憑證中公開金鑰加密客戶端隨機產生的亂數,接著再傳送 Client Key Exchange 訊息給伺服器。
  6. 客戶端傳送 Change Cipher Spec 訊息告知伺服器端之後將採用協商的私密金鑰和加密套件進行加密。
  7. 客戶端透過協商好的私密金鑰和加密演算法處理雜湊值 並且傳送 Finished 訊息給伺服器,此時伺服器會在利用同樣的方法計算雜湊值進行解密結果的比對,若兩者相同,則證明私密金鑰和加密套件協商成功。
  8. 伺服器傳送訊息,並且傳送 Change Cipher Spec 訊息通知客戶端之後傳輸將採用協商的私密金鑰和加密套件進行加密。
  9. 伺服器端透過協商好的私密金鑰和加密演算法處理雜湊值 並且傳送 Finished 訊息給客戶端,此時客戶端會在利用同樣的方法計算雜湊值進行解密結果的比對,若兩者相同和訊息鑑別碼也相同時,則證明私密金鑰和加密套件協商成功。

此外若客戶端接收到伺服器所傳送的訊息,若解密成功,則可以判斷伺服器是數位憑證的擁有者,也就代表伺服器身分驗證成功。

總結 SSL 網站連線可以滿足機密性和完整性之外,更能夠協助使用者驗證伺服器的身分,同時讓使用者相信資料在傳輸的過程中不會外洩和被更改資料,將資料傳送至正確的網站。

相關資源

技術標準 OAuth (1)

基本介紹

教學目標

初步了解 OAuth 授權協定的流程。

重點概念

OAuth 是 Open Authorization 的縮寫, 透過 OAuth 協定,使用者可以在不透漏帳號密碼的情況之下,授權第三方網路應用服務使用原本提供的網路服務,基本上 OAuth 協定目前可分為 OAuth 和 OAuth 2.0 兩種:

OAuth 1.0

認證及授權的過程中涉及三種角色包括:

  • 服務提供者 (Service Provider):
    允許透過 OAuth 協定進行存取的 Web 應用程式。
  • 使用者 (User):
    擁有服務提供者的帳戶的個人。
  • 用戶端 (Consumer):
    一個使用 OAuth 協定代表用戶進行存取服務提供者的網站或應用程式。

基本上處理的流程步驟如下:

  1. 用戶端會要求 Token
  2. 服務提供者會授予 Token
  3. 用戶端會直接將使用者直接導向服務提供者
  4. 服務提供者會直接將使用者直接導向用戶端
  5. 用戶端會請求存取 Token
  6. 服務提供者會授予存取 Token
  7. 用戶端可以存取受保護的資源

OAuth 1.0 流程圖

OAuth 2.0

認證及授權的過程中涉及的四種角色包括:

  • 資源擁有者 (Resource Owner) :
    授予存取受保護資源的能力。
  • 資源伺服器 (Resource Server) :
    託管受保護的資源的伺服器,能夠透過存取 Token 回應受保護資源的請求。
  • 用戶端 (Client) :
    代表受保護資源請求的應用程式資源授權的擁有者。
  • 授權伺服器 (Authorization Server) :
    發出存取 Token 成功後,用戶端存取伺服器驗證資源擁有者獲得授權。

基本上處理的流程步驟如下:

  1. 用戶端會向資源擁有者請求授權
  2. 資源擁有者會授予用戶端權限
  3. 用戶端會將被授予的權限和用戶端憑證傳給授權伺服器
  4. 授權伺服器會將存取 Token 傳給用戶端
  5. 用戶端會透過存取 Token 請求資源伺服器存取受保護的資源
  6. 資源伺服器驗證存取 Token 後會將受保護的資源給用戶端

OAuth 2.0 流程圖

相關資源

技術標準 OWASP ASVS (1)

基本介紹

教學目標

初步了解 OWASP 組織所提出針對行動應用程式的安全驗證標準。

重點概念

Introduction

OWASP Application Security Verification Standard (ASVS) is to normalize the range in the coverage and level of rigor available in the market when it comes to performing web application security verification.

How to Use This Standard

  • To help organization’s develop and maintain secure applications.
  • To allow security service/tools providers and consumers to align their requirements and offerings.

Mobile Verification Requirements

LEVEL 1

An application achieves Level 1 (or Opportunistic) certification if it adequately defends against application security vulnerabilities that are easy to discover.

V17.1

Verify that the client validates SSL certificates

V17.2

Verify that unique device ID (UDID) values are not used as security controls.

V17.3

Verify that the mobile app does not store sensitive data onto shared resources on the device (e.g. SD card or shared folders)

V17.4

Verify that sensitive data is not stored in SQLite database on the device

LEVEL 2

An application achieves Level 2 (or Standard) verification if it also adequately defends against prevalent application security vulnerabilities whose existence poses moderate-to-serious risk.

V17.5

Verify that secret keys or passwords are not hard-coded in the executable.

V17.6

Verify that the mobile app prevents leaking of sensitive data via autosnapshot feature of iOS.

V17.7

Verify that the app cannot be run on a jailbroken or rooted device.

V17.8

Verify that the session timeout is of a reasonable value.

V17.9

Verify the permissions being requested as well as the resources that it is authorized to access (i.e. AndroidManifest.xml, iOS Entitlements) .

V17.11

Verify that the application binary has been obfuscated.

V17.12

Verify that all test data has been removed from the app container (.ipa, .apk, .bar).

V17.13

Verify that the application does not log sensitive data to the system log or filesystem.

V17.14

Verify that the application does not enable autocomplete for sensitive text input fields, such as passwords, personal information or credit cards.

LEVEL 3

An application achieves Level 3 (or Advanced) certification if it also adequately defends against all advanced application security vulnerabilities, and also demonstrates principles of good security design.

V17.10

Verify that crash logs do not contain sensitive data.

V17.15

Verify that the mobile app implements certificate pinning to prevent the proxying of app traffic.

V17.16

Verify no misconfigurations are present in the configuration files (Debugging flags set, world readable/writable permissions) and that, by default, configuration settings are set to their safest/most secure value.

V17.17

Verify any 3rd-party libraries in use are up to date, contain no known vulnerabilities.

V17.18

Verify that web data, such as HTTPS traffic, is not cached.

V17.19

Verify that the query string is not used for sensitive data. Instead, a POST request via SSL should be used with a CSRF token.

V17.20

Verify that, if applicable, any personal account numbers are truncated prior to storing on the device.

V17.21

Verify that the application makes use of Address Space Layout Randomization (ASLR).

V17.22

Verify that data logged via the keyboard (iOS) does not contain credentials, financial information or other sensitive data.

V17.23

If an Android app, verify that the app does not create files with permissions of MODE_WORLD_READABLE or MODE_WORLD_WRITABLE

V17.24

Verify that sensitive data is stored in a cryptographically secure manner (even when stored in the iOS keychain).

V17.25

Verify that anti-debugging and reverse engineering mechanisms are implemented in the app.

V17.26

Verify that the app does not export sensitive activities, intents, content providers etc. on Android.

V17.27

Verify that mutable structures have been used for sensitive strings such as account numbers and are overwritten when not used. (Mitigate damage from memory analysis attacks).

V17.28

Verify that any exposed intents, content providers and broadcast receivers perform full data validation on input (Android).

相關資源

技術標準 EMVCo Payment (1)

基本介紹

教學目標

初步了解 EMVCo 組織所提出的憑證化支付的標準中的 NFC 使用案例流程,並與 Apple Pay 支付流程進行比對。

重點概念

Mobile NFC at Point of Sale

EMVCo Payment Tokenisation Specification Technical Framework

Step 1

The mobile device will interact with the NFC terminal through the payment application and pass the following key Payment Token data elements to the Merchant terminal:

  • Payment Token will be passed in the existing PAN field.
  • Token Expiry Date will be passed in the PAN Expiry Date field.
  • Token Cryptogram will be generated based on the Token data elements and will be passed in the Chip Cryptogram field.
  • Token Requestor ID will be passed as an optional field.
  • All other contactless data elements will be created and passed following the contactless data standards.

Step 2

The Merchant terminal will pass the contactless authorisation request to the Acquirer, carrying all of the standard Payment Token data fields and contactless data elements; POS Entry Mode will be set to indicate contactless transaction.

Step 3

The Acquirer will perform routine processing checks and pass the Token data fields and the contactless data to the Payment Network.

Step 4

The Payment Network will interface with the Token Service Provider to:

  • Retrieve the PAN.
  • Verify the state of the Payment Token to PAN mapping in the Token Vault for the active Payment Token, and other controls that may be defined for that Payment Token.
  • Validate the Token Cryptogram and validate the Token Domain Restriction Controls for that Payment Token.
  • Retrieve the Token Requestor ID if it was not provided in the authorisation message.

Step 5

The Payment Network will send the authorisation request to the Card Issuer, with the following changes to the authorisation request message:

  • Replace Payment Token with PAN.
  • Replace Token Expiry Date with PAN Expiry Date.
  • Add an indicator that conveys to the Card Issuer that an on-behalf-of validation has been completed by the Token Service Provider of that Payment Token.
  • The following Payment Token-related fields are passed to the Card Issuer in the authorisation request: Payment Token, Token Expiry Date (Optional), Token Assurance Data (Optional), Token Assurance Level, Token Requestor ID or POS Entry Mode Code.

Step 6

The Card Issuer completes the account-level validation and the authorisation check, and sends the PAN back in the authorisation response to the Payment Network.

Step 7

The Payment Network (possibly in communication with the Token Service Provider) may generate a response cryptogram and will replace the PAN with the Payment Token based on the mapping, and will pass the following required fields to the Acquirer as part of the authorisation response, in addition to other standard data elements:

  • Payment Token
  • Token Assurance Level
  • Last 4 digits of PAN
  • PAN Product ID (Optional)

Step 8

The Acquirer will pass the authorisation response to the Merchant.

Step 9

The consumer will be notified of the success or failure of the transaction.

Case Study

Apple Pay provides an easy and secure way for users to buy physical goods and services in your app. Using Touch ID, users can authorize payments using credit and debit card payment credentials that are stored on iPhone 6 and iPhone 6 Plus. These models contain a Secure Element, isolating card payment credentials from the main processor where your app runs.

Step 1

First the app checks that it can offer Apple Pay as a payment method. In this example, the app needs the postal code from the selected shipping address to calculate shipping cost and update the total amount due.

Step 2

When the user authorizespayment, your app receives a payment token from the Secure Element, via PassKit.

Step 3

Finally the app calls appropriate APIs in the payment processor SDK to pass the payment information to the payment processor, they process the transaction.

Apple Payment Flows

相關資源

技術標準 Gartner's Hype Cycle (1)

基本介紹

教學目標

初步了解 Gartner 在 2014 年針對技術科技所匯整出趨勢圖報告。

重點概念

應用階段

  1. 創新萌芽 (Innovation Trigger)
  2. 期望最頂點 (Peak of Inflated Expectation)
  3. 下調預期至低點 (Trough of Disillusion)
  4. 回歸理想 (Slope of Enlightenment)
  5. 生產率平台 (Plateau of Productivity)

Gartner's Hype Cycle 2014

在 2014 年期望最高的技術為 Internet of Thing ,然而 Big Data 在 2 至 5 年內會開始下調預期至低點,但是 Data Science 會在 2 年之內開始創新萌芽。

相關資源