Tiêu chuẩn quốc gia TCVN 14488-2:2025 ISO/TS 12812-2:2017 Ngân hàng lõi - Dịch vụ tài chính di động - Phần 2: Bảo mật và bảo vệ dữ liệu cho các dịch vụ tài chính di động

TIÊU CHUẨN QUỐC GIA

TCVN 14488-2:2025

ISO/TS 12812-2:2017

NGÂN HÀNG LÕI - DỊCH VỤ TÀI CHÍNH DI ĐỘNG - PHẦN 2: BẢO MẬT VÀ BẢO VỆ DỮ LIỆU CHO CÁC DỊCH VỤ TÀI CHÍNH DI ĐỘNG

Core banking - Mobile financial services -
Part 2: Security and data protection for mobile financial services

Lời nói đầu

TCVN 14488-2:2025 hoàn toàn tương đương ISO/TS 12812-2:2017

TCVN 14488-2:2025 do Ban kỹ thuật tiêu chuẩn quốc gia TCVN/TC 68 “Dịch vụ tài chính” biên soạn, Ủy ban Tiêu chuẩn Đo lường Chất lượng Quốc gia thẩm định, Bộ Khoa học và Công nghệ công bố.

Bộ TCVN 14488:2025 (ISO 12812) “Ngân hàng lõi - Dịch vụ tài chính di động” gồm các TCVN sau:

- TCVN 14488-1:2025 (ISO/TS 12812-1:2017) - Phần 1: Khuôn khổ chung

- TCVN 14488-2:2025 (ISO/TS 12812-2:2017) - Phần 2: Bảo mật và bảo vệ dữ liệu cho các dịch vụ tài chính di động

- TCVN 14488-3:2025 (ISO/TS 12812-3:2017) - Phần 3: Quản lý vòng đời ứng dụng tài chính

- TCVN 14488-4:2025 (ISO/TS 12812-4:2017) - Phần 4: Thanh toán di động cho cá nhân

- TCVN 14488-5:2025 (ISO/TS 12812-5:2017) - Phần 5: Thanh toán di động cho doanh nghiệp

 

Lời giới thiệu

Bộ TCVN 14488 (ISO 12812) bao gồm TCVN 14488-1 (ISO 12812-1), và TCVN 14488 -2 (ISO 12812-2) đến TCVN 14488-5 (ISO/TS 12812-5), được công bố dưới dạng các tiêu chuẩn Kỹ thuật về các hệ thống tương thích và bảo mật cho việc cung cấp, vận hành và quản lý Dịch vụ Tài chính Di động (MFS).

Tiêu chuẩn này nhằm hỗ trợ các nhà phát triển MFS và các nhà cung cấp dịch vụ MFS (MFSPs) để đánh giá và chọn lựa các cơ chế bảo mật cho một MFS được quản lý theo một chính sách bảo mật đã được thiết lập trước. Nó cũng quan trọng đối với người sử dụng MFS để hiểu cách thức các yêu cầu bảo mật và các yếu tố cần xem xét ảnh hưởng đến môi trường di động.

Bảo mật là yêu cầu trúng tâm cho bất kỳ MFS nào. Các tổ chức ngày càng tìm cách giảm thiểu rủi ro gian lận để bảo vệ khách hàng và do đó là bảo vệ chính doanh nghiệp của họ. Các mục tiêu bảo mật tập trung vào việc giảm thiểu rủi ro của các mối đe dọa đã được xác định đối với tính toàn vẹn và sự bảo mật của dữ liệu. Bất kỳ mô hình kinh doanh MFS bền vững nào đều phụ thuộc vào bảo mật và ngăn chặn gian lận. Do đó, MFSP cần xác định tính bảo mật và khả năng sẵn có của dữ liệu trước khi triển khai bất kỳ MFS nào.

Công nghệ di động đặt ra những vấn đề cụ thể về bảo mật do sự phổ biến và dễ dàng tiếp cận của các thiết bị di động cũng như gia tăng các hành vi tấn công vào ứng dụng di động. Kinh nghiệm với thanh toán thẻ truyền thống khác với việc sử dụng thiết bị di động và kênh không dây, và yêu cầu phải đánh giá lại các rủi ro và biện pháp kiểm soát, thực hiện lại khi cần thiết. Do đó, MFSP cần có sự hiểu biết chung về các rủi ro mà hệ sinh thái đối mặt và sự phù hợp của các tiêu chuẩn bảo mật hiện có (kiến trúc, thiết bị và cơ chế) để giải quyết chúng. Tiêu chuẩn này giả định rằng khi MFSP quyết định chính sách bảo mật cần triển khai, nguyên tắc tương xứng sẽ được áp dụng. Nói cách khác, các biện pháp bảo mật nên tương xứng với rủi ro tiềm ẩn về tài chính và tổn thất uy tín của một MFS cụ thể.

Dịch vụ tài chính di động (MFS) được khởi tạo từ một thiết bị di động có khả năng hỗ trợ các giao thức truyền thông không dây khác nhau cho các chế độ hoạt động khác nhau. Thiết bị di động có thể tận dụng các công nghệ khác nhau để cung cấp MFS, bao gồm nhưng không giới hạn ở công nghệ giao tiếp trường gần (NFC) kết hợp với sự hiện diện của môi trường bảo mật thích hợp (ví dụ: SE, TEE, phần mềm với các kiểm soát bảo mật bổ sung) có sẵn trong thiết bị di động hoặc có thể truy cập từ một văn phòng phụ trợ từ xa /trên nền tảng đám mây. Cả hai loại công nghệ này đều cung cấp các phương pháp khác nhau để bảo mật dữ liệu tài chính, các ứng dụng tài chính và dữ liệu cá nhân. Để xác định các yêu cầu bảo mật cho MFS, tiêu chuẩn này phân biệt giữa:

Chế độ vận hành gần, phù hợp với các hình thức thanh toán khác nhau, trong đó thiết bị di động trực tiếp giao tiếp với một thiết bị di động khác (ví dụ: thiết bị di động của người được trả tiền) hoặc một đầu thanh toán đặt tại đơn vị chấp nhận thanh toán. Thanh toán gần được định nghĩa là những giao dịch xảy ra khi người trả tiền và người nhận tiền có mặt ở cùng một địa điểm (xem TCVN 14488-1 (ISO 12812-1)).

- Chế độ vận hành di động từ xa, trong đó thiết bị di động sử dụng mạng truyền thông di động cho phép MFS hoạt động khi người trả tiền và người nhận tiền không ở cùng một địa điểm (xem TCVN 14488-1 (ISO 12812-1)). Trong chế độ từ xa, kênh truyền thông không dây được thiết lập theo một tập hợp các giao thức tiêu chuẩn cụ thể (ví dụ: GSM, CDMA, WiFi) bao gồm các thủ tục xác thực để cấp quyền truy cập vào các dịch vụ mạng. Một quá trình xác thực thứ hai của ứng dụng tài chính di động cho phép kết nối với ứng dụng ngang hàng tương ứng trên nền tảng từ xa.

Tiêu chuẩn này phân tích các vấn đề bảo mật khác nhau có thể phát sinh từ việc lựa chọn nền tảng và công nghệ cho việc vận hành MFS. Tiêu chuẩn này cũng xác định các lỗ hổng phần mềm độc hại trên di động khác nhau (ví dụ: vi rút, trojan) đặc trưng cho thiết bị di động.

Các mục tiêu của TCVN 14488-2 (ISO/TS 12812-2) bao gồm:

a) Định nghĩa các yêu cầu bảo mật tối thiểu, các khuyến nghị và hướng dẫn phù hợp,

b) Hỗ trợ một khuôn khổ bảo mật tổng quát cho việc cung cấp và triển khai MFS với sự linh hoạt đủ để đáp ứng các chính sách bảo mật khác nhau,

c) Thiết lập một mô hình tổng quát để quản lý bảo mật cho MFS.

d) Cung cấp các tài liệu tham khảo để người thực hiện sử dụng trong việc đánh giá rủi ro của MFS.

e) Xác định các biện pháp quản lý bảo mật cho việc vận hành MFS, bao gồm tham chiếu đến các yêu cầu pháp lý quốc gia cụ thể để chống lại các hoạt động tội phạm (ví dụ: chống rửa tiền) và để tăng cường bảo mật dữ liệu thông qua việc sử dụng các phương pháp mã hóa đã được chứng minh.

Tiêu chuẩn này được cấu trúc như sau:

Điều 5 phân loại nội dung kỹ thuật của các điều khoản trong tiêu chuẩn này dưới dạng các loại tài liệu: mô tả, khuyến nghị hoặc yêu cầu.

Điều 6 giới thiệu khái niệm về quản lý bảo mật, giải quyết tất cả các khía cạnh khác nhau của bảo mật MFS, bao gồm quản lý rủi ro. Thông tin chi tiết về phân tích rủi ro có trong Phụ lục A.

Điều 7 mô tả bộ yêu cầu bảo mật tối thiểu cho MFS, bắt đầu với các thách thức và công nghệ để thiết kế hệ thống ứng dụng di động bảo mật.

Điều 8 đưa ra yêu cầu đối với các thành phần được thiết kế đặc biệt để tạo ra một môi trường bảo mật trong thiết bị di động, cũng như các mô-đun mật mã được sử dụng trong xử lý giao dịch MFS.

Điều 9 cung cấp thông tin chi tiết và đưa ra các yêu cầu về các phương pháp đánh giá và chứng nhận bảo mật.

Điều 10 đến Điều 12 thảo luận chi tiết hơn về các khái niệm đã được nêu trong Điều 7 bằng cách cung cấp các yêu cầu thêm về dịch vụ bảo mật cần thiết để cân bằng các lỗ hổng và mối đe dọa của các mạng không dây khác nhau trong các chế độ gần và xa.

Điều 13 đặc biệt liên quan đến các yêu cầu bảo mật tiền điện tử.

Điều 14 cung cấp thông tin liên quan đến việc lựa chọn các biện pháp đối phó để giảm thiểu các rủi ro pháp lý liên quan đến việc vi phạm các luật bảo vệ dữ liệu.

Phụ lục A tập trung vào phân tích rủi ro, bao gồm các nguyên tắc để thiết lập một chương trình quản lý bảo mật cho MFS.

Phụ lục B cung cấp thông tin về các ràng buộc quy định cần được xem xét khi thiết kế và/hoặc vận hành MFS.

Phụ lục C là danh sách các tiêu chuẩn mã hóa ISO được khuyến nghị và các triển khai để thiết kế các dịch vụ bảo mật được nêu trong tiêu chuẩn này.

Phụ lục D trình bày chi tiết các lỗ hổng và mối đe dọa đối với các kênh truyền thông khác nhau được sử dụng cho MFS.

Để biết thêm thông tin về bảo mật thanh toán di động, vui lòng tham khảo thư mục Tài liệu tham khảo

 

NGÂN HÀNG LÕI - DỊCH VỤ TÀI CHÍNH DI ĐỘNG -

PHẦN 2: BẢO MẬT VÀ BẢO VỆ DỮ LIỆU CHO CÁC DỊCH VỤ TÀI CHÍNH DI ĐỘNG

Core banking - Mobile financialservices -

Part 2: Security and data protection for mobile financial services

1 Phạm vi áp dụng

Tiêu chuẩn này mô tả và xác định một khung quản lý bảo mật cho MFS. Tiêu chuẩn này bao gồm:

- Một mô hình chung cho việc thiết kế chính sách bảo mật,

- Một bộ yêu cầu bảo mật tối thiểu,

- Các giao thức và cơ chế mã hóa được khuyến nghị cho việc xác thực thiết bị di động, trao đổi bảo mật các tin nhắn tài chính và xác thực bên ngoài, bao gồm:

a) Các khía cạnh điểm đến điểm (point-to-point) cần xem xét cho MFS;

b) Các khía cạnh đầu-cuối cần xem xét;

c) Các khía cạnh chứng nhận bảo mật;

d) Tạo chữ ký kỹ thuật số di động;

- Các vấn đề khả năng tương thích để chứng nhận bảo mật cho MFS,

- Khuyến nghị về bảo vệ dữ liệu nhạy cảm,

- Các hướng dẫn về việc thực thi các luật và quy định quốc gia (ví dụ: chống rửa tiền và chống tài trợ khủng bố (AML/CFT), và

- Các cân nhắc về quản lý bảo mật.

Để tránh trùng lặp công việc xây dựng tiêu chuẩn mà đã được các tổ chức khác thực hiện, tiêu chuẩn này sẽ viện dẫn các tiêu chuẩn khác khi cần thiết người sử dụng tiêu chuẩn này tham khảo các tiêu chuẩn đã được công bố.

2 Tài liệu viện dẫn

Các tài liệu viện dẫn sau đây là rất cần thiết cho việc áp dụng tiêu chuẩn. Đối với tài liệu viện dẫn ghi năm công bố thì áp dụng phiên bản được nêu. Đối với tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm cả các bản sửa đổi.

ISO 9564 (all parts), Financial services - Personal Identification Number (PIN) management and security (tất cả các phần), Dịch vụ tài chính - Quản lý và bảo mật Mã số nhận dạng cá nhân (PIN)).

ISO 11568, Financial services - Key management (retail) (Dịch vụ tài chính - Quản lý khóa (bán lẻ)) TCVN 14488-1:2025 (ISO 12812-1), Ngân hàng lõi - Dịch vụ tài chính di động - Phần 1: Khuôn khổ chung. TCVN 14488-3:2025 (ISO/TS 12812-3), Ngân hàng lõi - Dịch vụ tài chính di động - Phần 3: Quản lý vòng đời ứng dụng tài chính.

ISO 13491 (all parts), Financial services - Secure cryptographic devices (retail) (tất cả các phần), Dịch vụ tài chính - Thiết bị mật mã bảo mật (bán lẻ).

ISO 19092, Financial services - Biometrics - Security framework (Dịch vụ tài chính - Sinh trắc học - Khung bảo mật).

ISO 22307, Financial services - Privacy impact assessment (Dịch vụ tài chính - Đánh giá tác động về quyền riêng tư)

ISO/IEC 15408 (all parts), Information technology - Security techniques - Evaluation criteria for IT security (tất cả các phần), Công nghệ thông tin - Kỹ thuật bảo mật - Tiêu chí đánh giá cho bảo mật IT (công nghệ thông tin)

ISO/IEC 19790, Information technology - Security techniques - Security requirements for cryptographic modules (Công nghệ thông tin - Kỹ thuật bảo mật - Yêu cầu bảo mật cho các mô-đun mật mã)

ISO/IEC 29192 (all parts), Information technology - Security techniques - Lightweight cryptography (tất cả các phần), Công nghệ thông tin - Kỹ thuật bảo mật - Mật mã nhẹ)

3 Thuật ngữ và định nghĩa

Tiêu chuẩn này sử dụng các thuật ngữ và định nghĩa trong TCVN 14488-1:2025 (ISO 12812-1:2017) và những thuật ngữ và định nghĩa sau:

3.1

Cô lập ứng dụng (Application isolation)

Thuộc tính bảo mật của hệ điều hành, trong đó các ứng dụng được cách ly khỏi nhau cả trong quá trình thực thi và về mặt dữ liệu mà chúng lưu trữ và/hoặc truy cập.

3.2

Mẫu tấn công (Attack pattern)

Cách tiếp cận trừu tượng được sử dụng để tấn công tài sản của MFS.

3.3

Tiềm năng tấn công (Attack potential)

Đo lường mức độ lỗ lực cần bỏ ra để tấn công tài sản MFS, được thể hiện qua các yếu tố như chuyên môn, nguồn lực và động cơ của kẻ tấn công.

3.4

Bề mặt tấn công (Attack surface)

Tập hợp các điểm tấn công mà kẻ tấn công có thể sử dụng để xâm nhập hoặc chiếm đoạt dữ liệu trong hệ thống thông tin.

3.5

Danh sách thu hồi chứng chỉ (Certificate revocation list)

Cấu trúc dữ liệu đã ký chứa danh sách có dấu thời gian của các chứng chỉ đã bị thu hồi, được triển khai trong hạ tầng khóa công khai.

3.6

Tiêu chí chung (Common criteria)

Phương pháp đánh giá bảo mật cho các thành phần Công nghệ thông tin được tiêu chuẩn hóa bởi ISO/IEC 15408.

3.7

Mô-đun mật mã (Cryptographic module)

Bộ phần cứng, phần mềm và/hoặc phần lõi (firmware) thực hiện các chức năng bảo mật đã được phê duyệt.

3.8

Vi phạm dữ liệu (Data breach)

Mất quyền kiểm soát, bị xâm nhập, tiết lộ trái phép, chiếm đoạt hoặc truy cập trái phép, khi các cá nhân ngoài những người có quyền truy cập hợp pháp vào thông tin cá nhân có thể nhận dạng (Pll) hoặc bất kỳ thông tin nhạy cảm nào khác (ví dụ: dữ liệu xác thực, khóa).

3.9

Bảo mật đầu-cuối (End - to - end security)

Dữ liệu được mã hóa tại nguồn sao cho chỉ người nhận cuối cùng có quyền truy cập vào dữ liệu.

3.10

Xác thực mở rộng (External authentication)

Quá trình mà một ứng dụng thanh toán di động xác thực một thực thể.

3.11

Hệ thống quản lý an toàn thông tin (Information security management system)

Một phần của hệ thống quản lý tổng thể, dựa trên phương pháp tiếp cận rủi ro kinh doanh, được sử dụng để thiết lập, triển khai, vận hành, giám sát, xem xét, duy trì và cải tiến an toàn thông tin.

3.12

Tính toàn vẹn của thiết bị di động (Mobile device integrity)

Không có sự thay đổi trái phép hoặc không mong muốn trong phần cứng, phần lõi (firmware) và phần mềm của thiết bị di động.

3.13

Cá nhân hóa (Personalization)

Quá trình lưu trữ dữ liệu ứng dụng người dùng trên thiết bị di động cần thiết để thực hiện MFS.

3.14

Mã hóa điểm đến điểm (Point - to - point encryption)

Dữ liệu được mã hóa giữa hai nút, trong đó ít nhất một trong hai nút không phải là nguồn cũng không phải là người nhận cuối cùng của dữ liệu.

3.15

Hồ sơ bảo vệ (Protection profile)

Tập hợp các yêu cầu bảo mật được chỉ định với mục tiêu đối phó với các mối đe dọa đã được xác định trong một môi trường cụ thể.

3.16

Giả ẩn danh (Pseudo-anonymity)

Các đặc điểm bảo mật mà trong đó danh tính thật của người (ví dụ: người trả tiền, người nhận tiền) bị ẩn.

3.17

Rooting (Rooting)

Hành vi thao túng mà qua đó người dùng thiết bị di động có quyền truy cập vào các quyền quản trị hệ điều hành đặc quyền.

3.18

Miền bảo mật nhà cung cấp phần tử bảo mật (Secure element provider security domain)

Đơn vị vật lý và/hoặc đơn vị logic bị giới hạn trong phần tử bảo mật, nơi mà chính sách bảo mật dưới sự kiểm soát của nhà cung cấp phần tử bảo mật được áp dụng.

3.19

Kiểm soát bảo mật (Security controls)

Quản lý, vận hành và kiểm soát kỹ thuật (ví dụ: các biện pháp bảo vệ hoặc đối phó) được chỉ định cho một hệ thống thông tin để bảo vệ tính bảo mật, toàn vẹn và khả dụng của hệ thống và thông tin của nó.

3.20

Đóng gói bảo mật (Security encapsulation)

Bảo mật theo lớp, trong đó một giao thức (ví dụ: mã hóa PIN) được nhúng bên trong một giao thức khác (ví dụ: SSL, TLS).

3.21

Dữ liệu nhạy cảm (Sensitive data)

Dữ liệu cần được bảo vệ bằng các biện pháp kiểm soát bảo mật cho một MFS nhất định.

VÍ DỤ: Thông tin xác thực, thông tin thanh toán và ngân hàng, khóa mật mã

3.22

Khóa phiên (Session key)

Khóa mật mã tạm thời được sử dụng để bảo vệ dữ liệu cho phiên làm việc hiện tại.

3.23

Dấu thời gian (Time stamp)

Cơ chế bảo mật cung cấp bằng chứng kỹ thuật số chứng minh rằng một tài liệu hoặc tin nhắn điện tử đã được tạo ra hoặc ký trước một thời điểm nhất định.

3.24

Thiết bị di động tin cậy (Trusted mobile device)

Thiết bị di động đã được chứng nhận tuân thủ một số thông lệ nhất định của ngành mà có thể hỗ trợ một hồ sơ rủi ro đã biết (ví dụ: tạo chữ ký điện tử).

3.25

Không thể liên kết (Unlinkability)

Thuộc tính bảo mật của một giao thức bảo vệ nó khỏi việc một bên không có thẩm quyền có thể liên kết hai lần thực thi của giao thức với một thiết bị di động cụ thể.

4 Các thuật ngữ viết tắt

5 Tóm tắt tính chất kỹ thuật của các điều khoản

Bảng 1 mô tả tính chất kỹ thuật của các điều khoản, phân loại theo yêu cầu, khuyến nghị hoặc tài liệu mô tả.

Bảng 1 - Phân loại tính chất kỹ thuật của các điều khoản

6 Cân nhắc về quản lý bảo mật

6.1 Tổng quan

Điều 6 thiết lập một khuôn khổ để quản lý bảo mật của MFS. Các nhà cung cấp dịch vụ tài chính di động (MFSPs) rất nhạy cảm với khả năng mất đi uy tín và vì vậy họ cố gắng đảm bảo rằng các MFS là an toàn đối với khách hàng của họ. Do đó, tất cả các MFSPs đều chú trọng đến việc quản lý mối quan hệ với khách hàng và duy trì tính toàn vẹn và bảo mật của MFS của họ, để tránh những tổn thất về uy tín, tài chính và pháp lý có thể phát sinh từ các rò rit dữ liệu và gian lận.

CHÚ THÍCH: Tham khảo Phụ lục A để biết thêm chi tiết về phân tích rủi ro.

- Vì vậy, điều quan trọng là phải thiết lập một chính sách bảo mật cho chương trình MFS trong đó:

- Các vai trò và trách nhiệm được phân công,

- Các vấn đề bảo mật được quản lý và có các động lực để thực hiện và duy trì các thực hành bảo mật tốt nhất,

- Các giao dịch được bảo vệ và đáng tin cậy,

- Quyền riêng tư được đảm bảo, và

- Các hệ thống quản lý bảo mật của các bên liên quan là có thể so sánh và đáng tin cậy.

Một trong các mục tiêu của tiêu chuẩn này là cung cấp cho người thực thi cả các yêu cầu và khuyến nghị để thiết lập một chính sách bảo mật cho các hoạt động liên quan đến MFS. Theo Điều 5, TCVN 14488-1:2025 (ISO 12812-1:2017), mục tiêu của tiêu chuẩn là khả năng tương tác kỹ thuật. Tiêu chuẩn này cung cấp các tham chiếu đến các tiêu chuẩn mật mã, việc triển khai các tiêu chuẩn này hỗ trợ khả năng tương tác của các giao thức và ứng dụng cho MFS.

6.2 Mô hình ba lớp để quản lý bảo mật cho các dịch vụ tài chính di động

Tiêu chuẩn này thiết lập một mô hình chung để quản lý bảo mật nhằm giảm thiểu rủi ro tiềm ẩn liên quan đến MFS. Mô hình này dựa trên việc triển khai các biện pháp kiểm soát bảo mật trên ba lớp chức năng khác nhau cần thiết để cung cấp MFS, bao gồm (1) lớp quy trình, (2) lớp ứng dụng và (3) lớp cơ sở hạ tầng. Các nhà cung cấp dịch vụ tài chính di động (MFSPs) có trách nhiệm xác định và giảm thiểu các rủi ro cụ thể liên quan đến mỗi lớp.

- Lớp quy trình bao gồm tổ chức và các chính sách liên quan được thiết kế bởi chương trình MFS và triển khai bởi MFSP để giảm thiểu các rủi ro trong quá trình MFS.

- Lớp ứng dụng đề cập đến phần mềm phân tán dưới sự kiểm soát trực tiếp của MFSP hoặc của các đối tác của họ, được tích hợp trong các máy tính xử lý khác nhau và các liên kết giao tiếp cần thiết để khởi tạo và xử lý MFS (ví dụ: một ứng dụng được lưu trữ trong môi trường bảo mật của thiết bị di động, một nhân hệ điều hành (kernel) trong điểm tương tác).

- Lớp cơ sở hạ tầng bao gồm các thiết bị máy tính và mạng lưới tạo ra, lưu trữ, xử lý hoặc vận chuyển dữ liệu MFS (ví dụ: một thiết bị di động, mạng không dây, cơ sở dữ liệu, mô-đun mật mã).

Hình 1 mô tả ba lớp của mô hình chung và cung cấp các ví dụ về các tiêu chuẩn bảo mật mà người thực thi có thể tham khảo để thiết kế kiến trúc bảo mật cho MFS.

Hình 1 - Phương pháp 3 lớp

Tùy thuộc vào kết quả của việc đánh giá rủi ro, các phép đo dựa trên rủi ro tiếp theo nên được thực hiện cùng với các phương pháp thực hành tốt nhất phù hợp với các yêu cầu bảo mật. Tương tự, bề mặt tấn công có thể được phân tích hiệu quả và các biện pháp đối phó thích hợp có thể được triển khai, nếu các vectơ triển khai cụ thể đã được xác định.

Các nhà thực thi có thể muốn tham khảo các tài nguyên có sẵn để xác định cách thiết kế và triển khai các biện pháp bảo mật của họ. Một số tài nguyên như vậy là Sổ tay Kiểm tra Công nghệ thông tin của FFIEC, Hướng dẫn của Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa kỳ (NIST) (thường được sử dụng bởi các bên tham gia hệ thống thanh toán khác nhau) và PCI-DSS.

Mô hình kết nối hệ thống mở bảy lớp (ISO/IEC 7498-1) có thể được ánh xạ vào các Lớp ứng dụng và Cơ sở hạ tầng được mô tả trong 6.2.3 và 6.2.3.

6.2.1 Lớp quy trình

Tại lớp quy trình (lớp vận hành), mỗi bên trong chương trình MFS cung cấp hoặc đóng góp vào việc cung cấp MFS phải có một hệ thống quản lý an toàn thông tin (ISMS) với một bộ chính sách, quy trình và hệ thống xác định để quản lý rủi ro đối với tài sản thông tin. Trong một số trường hợp, ngoài vai trò là người tiêu dùng, các thực thể tiêu thụ thông tin MFS (ví dụ: các nhà cung cấp đám mây) cũng phải có một hệ thống quản lý an toàn thông tin. Bên liên quan tương ứng sẽ cung cấp thông tin về ISMS của họ khi có yêu cầu từ bất kỳ ai mà thông tin đó có liên quan (ví dụ: kiểm toán viên, đối tác hợp đồng), hoặc trong những trường hợp thích hợp, thậm chí đến khách hàng. Bất kì bên nào được yêu cầu phải có một ISMS phải được định kỳ xem xét (ví dụ: hàng năm) và cập nhật nó để đảm bảo tính hiện tại.

ISMS phải chứa ít nhất các phương pháp và quy trình để giám sát và quản lý các rủi ro liên quan mà các bên đã xác định và phải phân bổ các nguồn lực và trách nhiệm thích hợp để giảm thiểu các rủi ro này.

Mỗi bên tham gia, ngoại trừ người tiêu dùng, phải xác định trách nhiệm của mình và các tài sản có giá trị cần bảo vệ trong phạm vi trách nhiệm của mình.

Các mục tiêu kiểm soát tối thiểu cần được quản lý và tài liệu hóa bởi mỗi bên tham gia, ngoại trừ người tiêu dùng, bao gồm:

- Một chính sách bảo mật,

- Tổ chức bảo mật thông tin (ví dụ: cơ cấu CNTT phân cấp, cấu trúc quản lý bảo mật theo tầng),

- Một kế hoạch quản lý tài sản, bao gồm kiểm soát truy cập, và

- Khi thích hợp, các bên phải có bảo mật nguồn lực nhân sự và đào tạo nguồn lực liên quan.

Tùy thuộc vào các dịch vụ mà họ cung cấp, các mục tiêu kiểm soát bổ sung nên là một phần của hệ thống quản lý an toàn thông tin, bao gồm nhưng không giới hạn ở những mục tiêu sau:

- Bảo mật vật lý và môi trường;

- Quản lý truyền thông và vận hành;

- Kiểm soát truy cập;

- Thu thập, phát triển và bảo trì hệ thống thông tin;

- Quản lý sự cố bảo mật thông tin;

- Quản lý liên tục hoạt động kinh doanh;

- Cơ chế tuân thủ hoặc phù hợp.

Mặc dù MFSP có trách nhiệm cao nhất trong việc đạt được và duy trì bảo mật, nếu một số dịch vụ được thuê ngoài hoặc được cung cấp thông qua các đối tác hợp đồng khác của MFSP, thì một số hoặc một phần khu vực trách nhiệm có thể được giao lại cho các đơn vị khác, mặc dù trách nhiệm cuối cùng vẫn thuộc về MFSP. MFSP phải giám sát các nhà cung cấp và/hoặc đại lý mà họ đã thuê ngoài để đáp ứng bất kỳ yêu cầu bảo mật nào, nhằm xác minh sự tồn tại của mức dịch vụ bảo mật theo định kỳ, đảm bảo rằng các vấn đề bảo mật đang được xử lý phù hợp với các yêu cầu của tiêu chuẩn này.

Một số nhà thực thi có thể thấy hữu ích khi tham khảo TCVN ISO 27001, tiêu chuẩn này định nghĩa hệ thống quản lý an toàn thông tin (ISMS). Tuy nhiên, cần lưu ý rằng tiêu chuẩn này không được phát triển dành riêng cho ngành dịch vụ tài chính.

6.2.2 Lớp ứng dụng

Tại lớp ứng dụng, các thành phần phần mềm phải tuân thủ các yêu cầu thông tin được nêu trong tiêu chuẩn này.

Các mối đe dọa và rủi ro liên quan đến một MFS cụ thể có thể được mô tả tùy thuộc vào các thiết bị được sử dụng, hành vi dự kiến của khách hàng, các mẫu tấn công và môi trường ứng dụng.

Có thể tiến hành đánh giá rủi ro và đánh giá các biện pháp bảo mật theo các trường hợp sử dụng. Điều này áp dụng cho các vai trò và trách nhiệm của mỗi bên trong một MFS, bao gồm cả MFSP, khách hàng và bên thứ ba. Mạng không dây, cung cấp lớp cơ sở hạ tầng (xem 6.2.3), thường không nằm dưới sự kiểm soát trực tiếp của MFSP. Có thể sử dụng các giao thức không dây khác nhau để kết nối thiết bị di động với cơ sở hạ tầng xử lý. Kết nối này được thực hiện thông qua một mạng viễn thông di động hoặc kết nối Internet, do một MNO hoặc một thực thể thứ ba cung cấp.

Tối thiểu, MFSP cần xác định, ghi lại, đánh giá và giảm thiểu tác động của các mối đe dọa cụ thể đối với các ứng dụng liên quan đến các mẫu tấn công sau:

- Truy cập trái phép vào ứng dụng và dữ liệu thanh toán (ví dụ: tiết lộ khóa, bẻ khóa mã);

- Lạm dụng dữ liệu ứng dụng được tạo ra trong quá trình MFS (ví dụ: tấn công lặp lại, tấn công ghi lén, nghe lén);

- Ngăn chặn người dùng hợp pháp truy cập vào ứng dụng (ví dụ: từ chối dịch vụ);

- Chặn và thu thập dữ liệu xác thực (ví dụ: mã di động);

- Cài đặt các ứng dụng độc hại vào thiết bị di động có thể tạo điều kiện cho các hành vi trên.

Các mục tiêu kiểm soát bảo mật cụ thể sẽ được thiết lập để bảo vệ khách hàng và MFSP khỏi các rủi ro phát sinh từ các cuộc tấn công tiềm ẩn. Các mục tiêu kiểm soát này áp dụng cho:

- Xác thực ứng dụng,

- Kiểm soát truy cập ứng dụng,

- Bảo trì ứng dụng, và

- Kiểm soát vòng đời ứng dụng.

6.2.3 Lớp cơ sở hạ tầng

Tại lớp cơ sở hạ tầng, các thành phần phần mềm, quản lý mạng, hệ điều hành, phần lõi (firmware) và phần cứng phải tuân thủ các yêu cầu bảo mật thông tin được nêu trong tiêu chuẩn này.

Việc lựa chọn các biện pháp kiểm soát bảo mật và đo lường hiệu suất cần được triển khai chủ yếu phụ thuộc vào giải pháp kỹ thuật và môi trường chương trình MFS. Trong cơ sở hạ tầng cần thiết để bảo mật MFS, các thiết bị mật mã và các quy trình quản lý khóa tạo thành các thành phần trung tâm. ISO 13491 (tất cả các phần) và ISO 11568 được ngành tài chính sử dụng rộng rãi cho mục đích triển khai.

Tùy thuộc vào kết quả của việc đánh giá rủi ro liên quan đến các mối đe dọa đối với cơ sở hạ tầng, các biện pháp đo lường bổ sung theo hướng rủi ro cần được thực hiện bên cạnh các phương pháp thực hành tốt nhất phù hợp với các yêu cầu bảo mật. Tương tự, các rủi ro liên quan đến bề mặt tấn công (attack surface) của tổng thể cơ sở hạ tầng có thể được phân tích nếu các vectơ được biết đến cho phép thiết kế các biện pháp kiểm soát bảo mật tương ứng.

Một bộ các mục tiêu kiểm soát tối thiểu cho cơ sở hạ tầng cần thiết để cung cấp MFS, bao gồm:

- Bảo mật vật lý và môi trường,

- Kiểm soát truy cập cơ sở dữ liệu,

- Quản lý năng lực

- Quản lý liên tục hoạt động kinh doanh, và

- Quản lý sự cố bảo mật thông tin.

7 Nguyên tắc bảo mật và yêu cầu tối thiểu đối với dịch vụ tài chính di động

7.1 Các khía cạnh kiến trúc bảo mật cần xem xét

Trong mô hình ba lớp được mô tả trong 6.2, MFS và các ứng dụng liên quan được triển khai qua mạng không dây, với điều kiện rằng các yêu cầu bảo mật được xác định bởi MFSP có thể được thực hiện qua kênh đó. Mỗi điều từ 7.2 đến 7.4 gắn liền và phải hoạt động trong khuôn khổ mô hình, 7.5 tóm tắt các yêu cầu từ các điều trước đó.

Kiến trúc bảo mật là thiết kế về cách thức các kiểm soát bảo mật được định vị và sử dụng để đối phó với các mối đe dọa đối với các ứng dụng tài chính di động và dữ liệu nhạy cảm, cũng như cách thức chúng liên quan đến kiến trúc tổng thể hệ thống tài chính di động. Dữ liệu nhạy cảm bao gồm các dữ liệu được sử dụng để thực hiện hành vi gian lận, dữ liệu dùng để khởi tạo thanh toán di động, dữ liệu dùng cho mục đích xác thực và bất kỳ dữ liệu nào khác mà nếu bị thay đổi sẽ làm nguy hại đến bảo mật và/hoặc quyền riêng tư của giao dịch.

Kiến trúc bảo mật này nhằm giúp hệ thống MFS đạt được một loạt các mục tiêu bảo mật như đã được quy định trong chính sách bảo mật của hệ thống. Những mục tiêu này phụ thuộc vào bản chất của MFS mà hệ thống cung cấp. Tuy nhiên, vẫn tồn tại những mục tiêu quan trọng chung giữa các MFS khác nhau, như sau:

- Đạt được mức độ bảo vệ khi thực thi ứng dụng di động với thiết bị di động, tương đương với những yêu cầu đối với các thiết bị cá nhân khác (ví dụ: máy tính xách tay của công ty).

- Bảo vệ các giao dịch MFS với mức độ bảo mật phù hợp và hiệu quả ít nhất tương đương với mức độ bảo mật của cơ sở hạ tầng cũ.

- Bảo vệ quyền riêng tư của người dùng.

- Cung cấp giao diện người dùng đáng tin cậy cho các dịch vụ tài chính có mức độ rủi ro cao, bao gồm các tính năng như:

a) Những gì bạn nhìn thấy chính là những gì bạn ký,

b) Tính toàn vẹn và bảo mật của dữ liệu UVM đã nhập,

c) Dịch vụ bảo mật để kích hoạt/lựa chọn ứng dụng.

- Triển khai các biện pháp đối phó hiệu quả với các mối đe dọa từ mạng mở (ví dụ: từ chối dịch vụ, lừa đảo qua mạng, thư rác),

- Ngăn chặn rửa tiền và các tội phạm tài chính khác, và

- Tuân thủ các yêu cầu được quy định trong các quy định liên quan đến các giao dịch MFS.

Ngay cả khi mật mã là một công cụ quan trọng để bảo vệ tài sản tài chính di động, thiết kế hệ thống bảo mật bao gồm nhiều khía cạnh khác, đặc biệt là việc thực hiện chính xác các cơ chế mật mã, đánh giá các mẫu tấn công và lưu trữ an toàn các khóa mật mã. Do đó, kiến trúc bảo mật phụ thuộc vào mức độ bảo mật của các thiết bị có thể thiết lập các liên kết truyền thông an toàn. Một nền tảng có khả năng lưu trữ nhiều ứng dụng, với vòng đời của chúng có thể được quản lý độc lập, sẽ phát sinh các mối quan tâm cụ thể được giải quyết trong Điều 8.

MFSP cũng có thể xem xét các yêu cầu phi kỹ thuật, đặc biệt chú trọng đến việc phân bổ trách nhiệm được quyết định dựa trên kết quả của mô hình kinh doanh được hỗ trợ và các rủi ro đã được xác định.

- Tính phức tạp và bản chất không đồng nhất của các hệ thống MFS

Hạ tầng MFS là các hệ thống thông tin phức tạp. Các điểm truy cập và giao diện với hệ thống rất đa dạng và nằm dưới sự kiểm soát của các bên liên quan/khách hàng khác nhau, đồng thời phạm vi khả năng của các thiết bị di động sẵn có ngày càng cao (và gia tăng). Do đó, việc giám sát cách mỗi bên liên quan tuân thủ các yêu cầu của tiêu chuẩn trở nên khó khăn.

- Mối đe dọa từ kết nối không dây và Internet

Việc mở rộng một hệ sinh thái di động toàn diện đã dẫn đến việc sử dụng các công nghệ mới (ví dụ: điện toán đám mây) qua các mạng truyền thông mở. Một MFSP cần duy trì bảo mật các giao dịch khi sử dụng các công nghệ mới nổi này, đặc biệt là khi có thể có một kênh hoặc mạng không bảo mật (ví dụ: mạng không dây hoặc mạng không bảo mật khác, Internet) và xét đến việc các ứng dụng MFS có thể được tải xuống từ môi trường an toàn của thiết bị di động qua mạng không dây.

- Các cấp độ tham gia và kiểm soát khác nhau của các bên liên quan trong suốt cả quá trình phát triển MFS và vận hành hệ thống

Trong các hệ thống thanh toán thẻ truyền thống, hầu hết tất cả các thành phần đều được kiểm soát/quản lý bởi các tổ chức tài chính. Trong các hệ thống MFS, các thành phần được cung cấp, sở hữu và kiểm soát bởi một loạt các bên liên quan. Các bên liên quan này có các hệ thống khác nhau trong bảo mật khác nhau tùy thuộc vào kết quả của các hoạt động kinh doanh chính của họ.

- Mối đe dọa liên quan đến việc nhận dạng người dùng và máy chủ MFS

Việc thiếu các quy trình nhận dạng và xác thực mạnh cho người dùng và máy chủ tạo điều kiện cho các hành vi giả mạo và gian lận, đặc biệt là trong các giao dịch thanh toán di động cho cá nhân. Những mối đe dọa này có thể được giảm thiểu thông qua việc thực hiện các quy định phù hợp của "Định danh khách hàng" (KYC; xem Phụ lục B) để tuân thủ pháp luật địa phương về phòng chống rửa tiền và tội phạm tài chính.

- Tính bảo mật, toàn vẹn và khả dụng của thông tin trao đổi

Các tin nhắn chứa dữ liệu thanh toán gửi đến thiết bị di động (ví dụ: để xác thực và/hoặc mục đích thông báo) liên quan đến các giao dịch MFS có thể trở thành tài sản kỹ thuật số có giá trị, cần được bảo vệ về tính toàn vẹn, bảo mật và khả dụng.

- Môi trường bảo mật và các thiết bị di động được chia sẻ và các nền tảng mở

Một phần của kiến trúc bảo mật của hệ thống sẽ được hỗ trợ bởi thiết bị di động, bao gồm ít nhất một môi trường bảo mật (ví dụ: SE, TEE, phần mềm bổ sung tuân theo phân tích rủi ro). Các ứng dụng tài chính di động được triển khai bởi các MFSP khác nhau có khả năng đồng thời tồn tại trên cùng một thiết bị di động, sử dụng tài nguyên chung và chia sẻ cùng một môi trường bảo mật. Từ góc độ bảo mật, điều này có nhiều hệ quả.

a) Việc cung cấp một ứng dụng MFS mới cần phải minh bạch với các ứng dụng có thể có trên thiết bị di động, ứng dụng mới không được gây ra bất kỳ lỗ hổng bảo mật nào cho các ứng dụng khác trong quá trình cung cấp, lưu trữ và/hoặc thực thi.

b) Các bên liên quan tham gia vào quá trình tải xuống cần phải bảo vệ dữ liệu trao đổi bằng các cơ chế mật mã phù hợp, nhằm:

■ Bảo vệ tính toàn vẹn của ứng dụng khi tải xuống qua mạng không dây, và

■ Bảo vệ chống lại việc tải đồng thời phần mềm độc hại.

c) Bảo mật của một ứng dụng cần được đánh giá và chứng nhận trên nền tảng mà ứng dụng sẽ được cung cấp.

Phụ lục D mô tả các mối đe dọa bảo mật chung được quan sát thấy đối với các hoạt động liên quan đến MFS: thanh toán di động gần, thanh toán di động từ xa và ngân hàng di động. Tuy nhiên, các vấn đề bảo mật thông tin cần được xem xét riêng biệt cho mỗi MFS.

7.2 Tổng quan về kỹ thuật tăng cường bảo mật dịch vụ tài chính di động

7.2.1 Tổng quan

Điều 7.2 mô tả các kỹ thuật tăng cường bảo mật khác nhau cho các thành phần, thiết bị và mạng cần thiết cho MFS, hoạt động trong các lớp ứng dụng và/hoặc hạ tầng.

- 7.2.2 và 7.2.3 đề cập đến các thành phần của hạ tầng mà không cần thiết nằm trong sự kiểm soát của MFSP và do đó có thể coi là không đáng tin cậy từ góc độ của MFSP: thiết bị di động và mạng không dây.

7.2.4 đến 7.2.7 đề cập đến các kỹ thuật tăng cường bảo mật cho ứng dụng và dữ liệu MFS được sử dụng bởi MFSP để giảm thiểu các rủi ro.

7.2.2 Tổng quan về các kỹ thuật tăng cường bảo mật thiết bị di động

Thiết bị di động thường bao gồm một giao diện người dùng và một môi trường bảo mật để thực hiện dịch vụ tài chính di động. Các thiết bị di động có thể có khả năng khởi tạo một số hình thức giao dịch tài chính di động mà không cần SE, với điều kiện MFSP đã ban hành một hình thức kiểm soát bảo mật thay thế. Thêm vào đó, thiết bị di động có thể góp phần vào việc thực hiện các chức năng có lợi cho các dịch vụ tài chính di động như: (1) hỗ trợ các UVM khác nhau; (2) giao diện người dùng để lựa chọn và chấp thuận ứng dụng của bên thanh toán; và (3) khóa từ xa thiết bị di động nếu nó bị mất hoặc bị đánh cắp.

Về bảo mật, thiết bị di động có thể được coi là một thành phần dễ bị tổn thương. Do đó, cần có các nguyên tắc cô lập và bảo mật đề các nhà phát triển ứng dụng để giải quyết bất kỳ vấn đề cụ thể nào với hệ điều hành của thiết bị di động. Các yêu cầu chi tiết cho các môi trường bảo mật của thiết bị di động được quy định trong Điều 8.

7.2.3 Tổng quan về kỹ thuật tăng cường bảo mật mạng không dây

Mạng không dây tuân thủ các yêu cầu bảo mật tiêu chuẩn khác nhau, bao gồm các tùy chọn triển khai.

CHÚ THÍCH: Các cơ quan tiêu chuẩn khác nhau đã thông qua các tiêu chuẩn hiện có có thể hữu ích cho những người triển khai lớp hạ tầng cho MFS (ví dụ: IEEE, IUT-T, Bluetooth, WAP, ETSI).

Một thiết bị di động có thể được cấu hình để hoạt động trên các mạng khác nhau sử dụng các giao thức khác nhau. Một số mạng này có thể không được triển khai trong môi trường an toàn. Do đó, tiêu chuẩn này giả định rằng kênh giao tiếp không dây là không an toàn. Các biện pháp kiểm soát bảo mật chính trong việc tương tác giữa ứng dụng trên thiết bị di động và MFSP sẽ phải trong suốt (tức là vô hình) đối với kênh giao tiếp không dây. Chúng thường bao gồm:

- Bảo vệ tính bảo mật và toàn vẹn của dữ liệu và ứng dụng di động khi nghỉ và trong quá trình truyền tải,

- Không chối bỏ các giao dịch đã được người dùng ủy quyền,

- Bảo vệ chống lại các cuộc tấn công phát lại, và

- Các cơ chế xác thực khác nhau cho người dùng, ứng dụng MFS và các tiện ích máy chủ từ xa của MFSP.

7.2.4 Quản lý từ xa bảo mật các thành phần thiết bị di động bằng OTA

7.2.4.1 Mô tả công nghệ OTA

OTA là công nghệ được sử dụng để giao tiếp với, tải xuống ứng dụng và quản lý các thiết bị như UICCs và các môi trường bảo mật khác qua tất cả các mạng không dây, bao gồm các mạng di động và Wi-Fi.

OTA được xây dựng trên kiến trúc máy khách/chủ, trong đó một đầu là hệ thống phụ trợ của nhà điều hành hoặc đại lý (ví dụ: dịch vụ khách hàng, hệ thống thanh toán, máy chủ ứng dụng) và đầu kia là một thành phần được nhúng trong thiết bị di động.

OTA quản lý và cung cấp khả năng kết nối cho mỗi thiết bị di động và môi trường bảo mật của nó, bất kể kênh (SMS, http hoặc cả hai) hay công nghệ mạng nào được sử dụng. Việc trao đổi thông tin được bảo vệ bằng cách sử dụng liên kết truyền thông bảo mật đầu - cuối từ MFSP , quản lý dịch vụ tin cậy (TSM) đến môi trường bảo mật. Bảo mật đầu - cuối đạt được thông qua các khóa mật mã được chia sẻ giữa TSM và môi trường bảo mật.

Để triển khai công nghệ OTA, các thành phần sau đây được sử dụng:

- Một hệ thống phụ trợ (back-end) để gửi yêu cầu đến thành phần thiết bị di động mục tiêu;

Một cổng OTA để xử lý các yêu cầu này;

Một máy chủ SMSC để truyền tải các yêu cầu qua một thiết bị mang (ví dụ: thiết bị mang tin nhắn SMS);

- Một thiết bị di động để nhận các yêu cầu và truyền chúng đến môi trường bảo mật trong thiết bị di động;

- Một môi trường bảo mật để nhận và thực thi yêu cầu;

- Một TSM có vai trò tương tự như hệ thống cá nhân hóa thẻ.

7.2.4.2 Quản lý dịch vụ tin cậy trên OTA

TSM đóng vai trò quan trọng trong việc cung cấp và quản lý các ứng dụng MFS bằng cách sử dụng các chức năng sau:

- Giao diện giữa MFSP, MNO và trong một số tình huống là nhà sản xuất của thiết bị di động (thường được gọi là Nhà sản xuất Thiết bị gốc hay OEM);

- Bảo mật đầu - cuối để cung cấp môi trường bảo mật cho thiết bị di động;

- Quản lý vòng đời ứng dụng, bao gồm kích hoạt và hủy kích hoạt MFS trên thiết bị di động;

- Quản lý khóa từ MFSP, MNO và nhà cung cấp môi trường bảo mật.

7.2.4.3 Yêu cầu bảo mật

TSM phải sử dụng kênh giao tiếp OTA bảo mật để tránh khả năng chặn dữ liệu nhạy cảm khi nó được truyền qua mạng không dây. Cụ thể, tính toàn vẹn và bảo mật của các ứng dụng được cá nhân hóa trong môi trường bảo mật sẽ được bảo vệ trong quá trình truyền tải qua kênh OTA. Đối với yêu cầu bảo mật áp dụng cho việc quản lý khóa để bảo vệ kênh OTA, tham khảo 7.4.

7.2.5 Kỹ thuật tăng cường bảo mật ứng dụng tài chính di động

Các dịch vụ bảo mật sau đây có sẵn cho các ứng dụng máy khách MFS để bảo mật giao dịch được thực hiện qua các thành phần và mạng dễ bị tấn công ngoài tầm kiểm soát của MFSP:

- Dịch vụ bảo mật Nền tảng (xem 7.2.6) là các dịch vụ do chính thiết bị di động cung cấp để chia sẻ cho tất cả các ứng dụng và không nhất thiết yêu cầu các cơ chế mã hóa. Chúng bao gồm các dịch vụ để:

a) Bảo vệ và lọc dữ liệu nghi ngờ (ví dụ: danh sách trắng, phần mềm diệt virus),

b) Bảo vệ ứng dụng tài chính di động trong quá trình thực thi,

c) Hủy kích hoạt các thành phần được sử dụng trong quá trình giao dịch (ví dụ: mô-đun NFC), và

d) Bảo vệ các ứng dụng MFS trong trường hợp thiết bị di động bị mất hoặc bị đánh cắp.

- Dịch vụ bảo mật cấp ứng dụng (xem 7.2.7) được MFSP cung cấp bằng cách sử dụng các tài nguyên mật mã (ví dụ: thư viện mật mã) do cả thành phần chống giả mạo (ví dụ: SE) nơi ứng dụng lưu trú và thành phần mật mã từ xa khác như Mô-đun Bảo mật Phần cứng (HSM) cung cấp. Những dịch vụ này bảo vệ ứng dụng và dữ liệu ứng dụng cả khi nghỉ và trong quá trình truyền tải.

- Dịch vụ bảo mật quản lý ứng dụng (xem 7.2.8) được kích hoạt trong quá trình vận hành liên quan đến quản lý vòng đời của ứng dụng theo TCVN 14488-3 (ISO/TS 12812-3).

7.2.6 Dịch vụ bảo mật nền tảng

MFSP phải sử dụng các biện pháp bảo mật nền tảng sau đây do thiết bị di động cung cấp làm cơ sở cho việc quản lý bảo mật MFS.

- Bảo vệ chống lại phần mềm độc hại

Thiết bị di động có khả năng thực thi tất cả các loại ứng dụng, bao gồm cả virus và phần mềm độc hại. MFS từ xa thường phụ thuộc vào bảo mật dựa trên phần mềm, vốn dễ bị tấn công bởi nhiều mối đe dọa.

Tốc độ đổi mới công nghệ (tính không đồng nhất cao trên các nền tảng điện toán cơ bản và hệ điều hành phát triển nhanh chóng, khiến cho việc tìm một giải pháp diệt vi-rút chung trở nên khó khăn, làm tăng các chế độ giao tiếp) và cách thức sử dụng thiết bị di động (kết nối thường xuyên với mạng mở) khiến thiết bị di động dễ bị tấn công hơn so với các thiết bị máy tính cá nhân khác. Các bên liên quan như các nhà sản xuất thiết bị di động hoặc các nhà cung hệ điều hành OS cần đưa phần mềm bảo mật di động (ví dụ: phần mềm đi động diệt vi-rút) vào bộ ứng dụng mặc định được tải lên các thiết bị di động mới.

- Môi trường bảo mật để thực thi ứng dụng

Việc tạo ra một môi trường bảo mật để thực thi ứng dụng tài chính di động dựa trên hai nguyên tắc:

a) Cô lập ứng dụng trong một hoặc nhiều môi trường điện toán bảo mật, trên chính thiết bị di động (SE, TEE, các biện pháp kiểm soát bảo mật của hệ điều hành di động);

b) Bảo mật giao diện người dùng bằng cách tạo kênh đáng tin cậy giữa các thiết bị ngoại vi đầu vào/đầu ra của thiết bị di động và môi trường tính toán bảo mật.

- Hủy kích hoạt các giao diện gần

Hệ điều hành thiết bị di động có thể có các chức năng để hủy kích hoạt giao diện giao tiếp cho các khoản thanh toán gần, khi không có giao thức giao tiếp hoạt động bên ngoài nào và/hoặc cung cấp cho giao diện người dùng khả năng cắt đứt liên kết truyền thông giữa phần tử bảo mật và mô-đun tần số vô tuyến bên ngoài. Người tiêu dùng có toàn quyền kiểm soát thời điểm bật giao diện cho giao dịch, để giao diện đó hầu như bị vô hiệu hóa khi không được sử dụng cho các giao dịch thanh toán gần. Nếu không, dữ liệu thanh toán có thể bị kẻ tấn công đọc được và sử dụng, chẳng hạn như trong một cuộc tấn công chuyển tiếp (Phụ lục D).

- Hủy kích hoạt từ xa thiết bị di động

Trong trường hợp một khách hàng báo cáo rằng thiết bị di động của họ bị mất hoặc bị đánh cắp, MFSP phải có khả năng vô hiệu hóa từ xa tất cả các ứng dụng tài chính di động trên thiết bị di động đó, bằng cách sử dụng các tin nhắn cụ thể. Rủi ro mất mát tài chính cũng giảm thiểu bởi thực tế là việc mất thiết bị di động cần phải được báo cáo nhanh chóng.

7.2.7 Dịch vụ bảo mật cấp ứng dụng cho các ứng dụng tài chính di động

7.2.7.1 Tổng quan

Điều khoản này tập trung vào các cơ chế bảo mật ở cấp ứng dụng. Những cơ chế này sử dụng các thuật toán và khoá mật mã để đạt được các mức độ bảo vệ khác nhau đối với dữ liệu được trao đổi trong MFS. Dữ liệu ứng dụng MFS cần được bảo vệ trong suốt quá trình cá nhân hóa, lưu trữ và sử dụng trên thiết bị di động, đặc biệt là:

- Cần có cơ chế bảo rằng không có dữ liệu thanh toán nhạy cảm và dữ liệu cá nhân nào bị truy cập hoặc thay đổi bởi một bên được ủy quyền thông qua bất kỳ giao diện giao tiếp nào của thiết bị di động, và

- Dữ liệu thanh toán và dữ liệu cá nhân dạng văn bản nhạy cảm cần được lưu trữ và quản lý trong một môi trường bảo mật phù hợp.

Thông thường, việc thực thi một ứng dụng tài chính di động sẽ yêu cầu các dịch vụ bảo mật được cung cấp bởi một số giao thức, cơ chế này được gọi là đóng gói bảo mật. Ví dụ:

- Giao thức đầu tiên có thể hỗ trợ kiểm soát quyền truy cập vào dịch vụ tài chính di động, ví dụ, bằng cách sử dụng cơ chế xác thực bên ngoài và trao đổi dữ liệu cần thiết để tạo ra một khóa phiên, và

- Giao thức thứ hai có thể cung cấp dịch vụ bảo mật cho các tin nhắn trao đổi, sử dụng các khóa phiên đã thỏa thuận, cũng như dịch vụ đảm bảo tính toàn vẹn của thông tin trao đổi. Những giao thức này cũng có thể bảo vệ chống lại các loại tấn công khác vốn có trong các kênh không dây (ví dụ: hành vi đánh cắp thông tin skimming, tấn công phát lại và nghe lén; xem Phụ lục D).

7.2.7.2 Các đặc tính bảo mật của các ứng dụng tài chính di động

Các dịch vụ bảo mật của hệ thống cung cấp nhiều thuộc tính bảo mật khác nhau cho dữ liệu ứng dụng và giao dịch được tạo ra bởi các ứng dụng. Các thuộc tính này bao gồm:

a) Xác thực người dùng,

b) Bảo mật dữ liệu nhạy cảm khi nghỉ, trong quá trình truyền tải và trong suốt quá trình thực thi để đảm bảo rằng dữ liệu chỉ có thể được truy cập bởi các bên được ủy quyền,

c) Tính toàn vẹn của dữ liệu khi ở trạng thái nghỉ, trong quá trình truyền tải và trong suốt quá trình thực thì được duy trì bằng cách sử dụng mã xác thực tin nhắn, và

d) Không chối bỏ khi một tin nhắn truyền đạt sự xác nhận từ người dùng.

MFS cũng có thể sử dụng các biện pháp bảo vệ bổ sung (ví dụ: thời gian chờ) không dựa trên các cơ chế mật mã.

7.2.7.3 Mã hóa điểm đến điểm

Mã hóa điểm đến điểm là một trường hợp đặc biệt của mã hóa ở cấp ứng dụng, trong đó mã hóa được áp dụng một cách có chọn lọc trong chuỗi xử lý của ứng dụng MFS. Nó định nghĩa một quá trình mật mã để mã hoá cho dữ liệu giữa hai nút giao tiếp bất kì trong suốt quá trình xử lý thanh toán:

a) Dữ liệu gốc được mã hóa tại điểm thu nhận;

b) Dữ liệu chỉ được giải mã khi nỏ cần thiết cho các nút xử lý cụ thể, những nút này không có lựa chọn nào khác ngoài việc truy cập vào dữ liệu gốc.

Mã hóa điểm đến điểm yêu cầu kiểm soát nghiêm ngặt các khóa cần thiết để giải mã dữ liệu, nhằm đảm bảo rằng chỉ các nút được ủy quyền mới có thể truy cập vào dữ liệu gốc.

7.2.7.4 Bảo mật đầu - cuối

Bảo mật đầu cuối, tương tự như mã hóa đầu cuối, định nghĩa một quy trình mã hóa cho dữ liệu bảo mật tại nguồn, để việc giải mã tương ứng chỉ xảy ra tại điểm đích cuối cùng của tin nhắn. Trong trường hợp này, một tin nhắn nhất định sẽ được mã hóa trong môi trường bảo mật, bằng cách sử dụng một khóa chia sẻ với một Mô-đun Bảo mật phần cứng (HSM) từ xa, dưới sự kiểm soát của MFSP. HSM được sử dụng rộng rãi để quản lý và bảo vệ các khóa mật mã và hỗ trợ xử lý bảo mật nhằm đạt được khả năng bảo vệ mật mã cần thiết khi dữ liệu bị mã hóa bởi MFS từ xa.

Bất kể thực tế là tin nhắn có thể truyền qua các mạng dễ bị tấn công, nếu được triển khai đúng cách, mã hóa đầu cuối sẽ bảo vệ dữ liệu khỏi bị nghe lén và các cuộc tấn công brute -force.

CHÚ THÍCH: Mã hóa điểm đến điểm giữa nguồn và người nhận cuối cùng tương ứng với bảo mật đầu cuối.

7.2.8 Dịch vụ bảo mật quản lý ứng dụng

Các dịch vụ bảo mật này nhằm mục đích bảo vệ các tài sản cấp ứng dụng trong suốt vòng đời của ứng dụng MFS. Các hoạt động quản lý cung cấp cho các ứng dụng tính bảo mật và tính xác thực trong suốt quá trình cá nhân hóa của chúng, đảm bảo rằng các ứng dụng di động chỉ được tải xuống từ các nguồn đáng tin cậy.

Yêu cầu bảo mật cho việc quản lý ứng dụng được quy định trong 7.4.

7.3 Bộ yêu cầu bảo mật tối thiểu cho các dịch vụ tài chính di động

7.3.1 Tổng quan

Yêu cầu tối thiểu đối với MFS áp dụng cho các MFSP có thể triển khai chúng với sự hỗ trợ của các chương trình MFS và các nhà cung cấp MFS khác.

CHÚ THÍCH: Thuật ngữ "phiên" trong điều này đề cập đến một quy trình được mở bằng kết nối thành công với MFSP nhằm chạy một hoặc nhiều giao dịch.

7.3.2 Yêu cầu truy cập MFS từ xa

Các yêu cầu trong điều này và 7.4 áp dụng khác nhau cho ba cơ chế truy cập khác nhau vào MFS từ xa.

7.3.2.1 Đối với MFS được truy cập qua trình duyệt di động, các phần tử bảo mật tương tự như những yếu tố áp dụng cho dịch vụ tài chính được truy cập qua máy tính để bàn truyền thống (PC). MFSP phải cung cấp phương tiện để khách hàng xác minh tính xác thực của trang web tại thời điểm truy cập (ví dụ: sử dụng chứng chỉ xác thực mở rộng hoặc các cơ chế tương tự).

7.3.2.2 Đối với MFS được truy cập thông qua một chức năng chuyên dụng trên thiết bị di động (ví dụ: ứng dụng MFS), các yêu cầu liên quan được quy định trong điều này và 7.4 sẽ được áp dụng. Cụ thể, MFSP phải cung cấp phương tiện để khách hàng xác minh tính xác thực của ứng dụng tài chính di động (ví dụ: sử dụng chữ ký phần mềm, giao tiếp ngoài băng tần).

7.3.2.3 Đối với MFS được cung cấp qua các kênh của MNO (ví dụ: SMS, USSD) mà không có ứng dụng tài chính di động cụ thể nào được tải xuống trên thiết bị di động của khách hàng trước đó thì các yêu cầu liên quan được quy định trong điều này sẽ được áp dụng.

7.3.3 Yêu cầu xử lý giao dịch

7.3.3.1 Xác thực khách hàng và dữ liệu MFS

7.3.3.1.1 Phải có cơ chế xác thực khách hàng để đảm bảo rằng chỉ có chủ tài khoản hợp pháp mới được phép thực hiện các giao dịch tài chính.

7.3.3.1.2 MFSP phải cung cấp cho khách hàng một UVM (ví dụ: mã di động) để chứng minh sự hiện diện của khách hàng trong giao dịch MFS.

7.3.3.1.3 Trước khi cung cấp thông tin xác thực cho khách hàng mới, MFSP phải thực hiện đăng kí xác minh KYC (định danh khách hàng) theo quy định hiện hành (xem Phụ lục B).

7.3.3.1.4 Xác thực khách hàng có thể có các mức độ khác nhau (mạnh hoặc cơ bản). Mức độ mạnh tương ứng với xác thực khách hàng mạnh được triển khai quy trình xác thực bởi nhà cung cấp MFS hoặc đại lý của họ, tuân thủ ba điều kiện sau:

a) Việc xác thực thành công phải bao gồm ít nhất hai trình xác thực độc lập cá nhân theo quan điểm bảo mật, có nghĩa là sự xâm nhập vào một trong hai trình xác thực không làm tổn hại đến trình còn lại;

b) Ít nhất một trong các trình xác thực sẽ là động với tính bảo mật chuyển tiếp tuyệt đối, không thể tái sử dụng và không thể sao chép;

c) Ít nhất một trong các trình xác thực phải là UVM.

7.3.3.1.5 Quy trình xác thực phải được thiết kế theo cách đảm bảo tính bảo mật cho trình xác thực:

a) Nếu sử dụng sinh trắc học làm UVM, các biện pháp kiểm soát bảo mật theo yêu cầu trong ISO 19092 phải được đáp ứng;

b) Nếu mã PIN được sử dụng làm UVM, mã PIN phải được quản lý theo ISO 9564 (tất cả các phần);

c) Nếu mã di động được sử dụng làm UVM, mã di động phải được mã hóa.

Thuật ngữ "Xác thực mạnh" có thể có một định nghĩa pháp lý riêng biệt theo luật pháp của từng quốc gia.

Xác thực khách hàng cơ bản là xác thực một yếu tố hoặc xác thực dựa hoàn toàn vào dữ liệu tĩnh.

7.3.3.1.6 Ngoài ra, ứng dụng MFS phải được bảo vệ (ví dụ: bằng cách sử dụng mã hóa, MAC, HMAC, chữ ký số), và nghi nhận rằng có nhiều mức độ khác nhau tùy thuộc vào độ bảo mật của hệ điều hành hoặc độ bảo mật của nơi lưu trữ ứng dụng (ví dụ: SE, TEE, hoặc phần mềm với các kiểm soát bảo mật bổ sung). Cả khía cạnh này đều đóng góp vào mức độ bảo đảm bảo mật bắt nguồn từ xác thực khách hàng. Các yếu tố khác (ví dụ: nhận dạng thiết bị, phân tích mô hình chi tiêu) cũng có thể góp phần.

7.3.3.1.7 Mức độ bảo đảm bảo mật phải được xem xét khi xác định các loại và/hoặc mức độ giao dịch và môi trường được phép. Điều này bao gồm việc chỉ cho phép các giao dịch giá trị thấp hoặc chuyển tiền giữa các tài khoản thuộc sở hữu của cùng một cá nhân, khi thực hiện xác thực bảo mật thấp, ngược lại, cho phép các giao dịch có giá trị cao khi đạt được mức độ bảo mật cao.

7.3.3.1.8 Quan trọng là MFSP phải xem xét rằng, trong khi thiết bị di động có thể là kênh thứ hai cho các giao dịch khởi tạo máy tính cá nhân PC hoặc bằng thẻ chip, khi một giao dịch đã được khởi tạo từ thiết bị di động, thì thiết bị di động lúc này là cùng kênh. Trong trường hợp này, MFSP phải triển khai các cơ chế bảo mật kênh thứ hai sử dụng một thiết bị khác (ví dụ: máy tính bảng, thiết bị di động thứ hai) để thiết bị di động không thể vô tình đóng vai trò cho cả kênh thứ nhất và kênh thứ hai. Do đó, Ví dụ trong trường hợp này SMS sẽ không được sử dụng để truyền đạt mật khẩu một lần.

7.3.3.1.9 Nhà cung cấp MFS cần áp dụng các cơ chế như giới hạn thời gian xác thực khách hàng (ví dụ: yêu cầu xác thực mới sau một thời gian kể từ lần xác thực thành công cuối cùng) và giới hạn số lần thử lại khi xác thực không thành công

7.3.3.1.10 MFSP phải sử dụng các cơ chế để xác thực ứng dụng MFS.

7.3.3.2 Giám sát giao dịch

7.3.3.2.1 Nhà cung cấp MFS phải sử dụng các cơ chế bảo mật để giảm thiểu hoặc bảo vệ chống lại các cuộc tấn công brute force (ví dụ: tấn công cạn kiệt trên UVM) và các cuộc tấn công khác phù hợp với các kiểu gian lận đã biết.

7.3.3.2.2 Trước khi cung cấp dịch vụ tài chính di động cho khách hàng, MFSP nên đặt ra các giới hạn áp dụng cho các dịch vụ đó (ví dụ: số tiền tối đa cho mỗi giao dịch cá nhân hoặc tổng số tiền trong một khoảng thời gian nhất định) và nên thông báo cho khách hàng về các giới hạn này.

7.3.3.2.3 Một nhà cung cấp MFS phải, nếu có đủ khả năng vật lý, ghi lại các sự kiện quan trọng, bao gồm:

a) Thất bại trong việc xác thực;

b) Thất bại trong việc xác thực một tin nhắn;

c) Dữ liệu cần thiết để giải quyết việc từ chối một giao dịch thanh toán;

d) Bắt đầu phiên;

e) Kết thúc phiên.

7.3.3.2.4 Dữ liệu nhạy cảm không được ghi lại. Các điều kiện lỗi khác có thể được ghi lại.

7.3.4 Bảo vệ dữ liệu nhạy cảm

7.3.4.1 Tổng quan

7.3.4.1.1 MFSP phải sử dụng các cơ chế bảo mật để ngăn chặn quyền truy cập trái phép vào dữ liệu nhạy cảm khi lưu trữ hoặc trong quá trình truyền tải.

7.3.4.1.2 Có thể sử dụng giao diện người dùng đáng tin cậy để hạn chế khả năng tiếp xúc với phần mềm độc hại giả danh ứng dụng tài chính di động hợp pháp hoặc lời nhắc xác thực khách hàng.

7.3.4.1.3 Cần phải xem xét mức độ bảo vệ dữ liệu nhạy cảm khi quyết định loại và/hoặc mức độ giao dịch nào được phép, và loại dữ liệu nào có thể được lưu trữ trên thiết bị di động hoặc trên máy chủ an toàn.

7.3.4.2 Bảo vệ dữ liệu trong quá trình lưu trữ

7.3.4.2.1 Tính bảo mật và tính toàn vẹn của dữ liệu nhạy cảm phải được bảo vệ trên thiết bị di động. Dữ liệu nhạy cảm phải được lưu trữ trong môi trường an toàn của thiết bị di động và phải được mã hóa, và tính toàn vẹn của dữ liệu phải được bảo vệ bằng mật mã. Các thuật toán mật mã được sử dụng phải thuộc các thuật toán được chỉ định trong Phụ lục C.

7.3.4.2.2 Tính toàn vẹn và tính xác thực của các khóa công khai được sử dụng cho MFS được tạo ra từ các tiêu chuẩn được công nhận (xem Phụ lục C) phải được bảo vệ bằng chứng chỉ số.

7.3.4.3 Bảo vệ dữ liệu trong quá trình truyền tải

7.3.4.3.1 Nếu ứng dụng MFS không hoạt động trong môi trường bảo mật, thì cần thực hiện các biện pháp bảo mật hiệu quả khác để hạn chế việc tài khoản khách hàng bị lộ trong trường hợp bị xâm phạm. Những biện pháp này có thể bao gồm việc sử dụng mã thông báo dùng một lần hoặc chỉ sử dụng thiết bị di động cho mục đích xác thực. Dữ liệu mã PIN phải được nhập và truyền tải theo đúng ISO 9564 (tất cả các phần). Trong những trường hợp này, không có dữ liệu nhạy cảm nào được lưu trữ trên thiết bị di động và cơ chế xác thực không dễ bị xâm phạm bởi các cuộc tấn công vào thiết bị di động.

CHÚ THÍCH: Việc tối giản mã nguồn tự nó không được coi là đủ.

7.3.4.3.2 Dữ liệu nhạy cảm phải được mã hóa khi truyền tải giữa bất kỳ hai điểm nào trong quá trình xử lý giao dịch. Tương tự như chuyển đổi mã PIN, để tránh lộ khóa và dữ liệu nhạy cảm, cần có phần cứng mã hóa cho việc giải mã, hoặc chỉ cho phép dữ liệu không nhạy cảm. Dữ liệu nhạy cảm phải được xác thực và bảo vệ chống lại sự thay thế và sửa đổi. Khi dữ liệu này tương ứng với một ứng dụng cần được tải xuống, thì các yêu cầu được quy định trong 7.4 sẽ được áp dụng.

7.3.5 Yêu cầu đối với thiết bị di động

7.3.5.1 Một MFSP phải sử dụng các cơ chế bảo mật để bảo vệ ứng dụng tài chính di động khỏi việc sửa đổi và/hoặc thay thế trái phép. Các cơ chế này phải bao gồm các kiểm tra bảo mật thiết bị, như kiểm tra các bản vá và phiên bản của hệ điều hành, phát hiện phần mềm độc hại hoặc việc root (hay còn gọi là "jail-breaking"-bẻ khoá) thiết bị.

7.3.5.2 Việc triển khai MFS phải cung cấp các biện pháp đối phó với các mối đe dọa phát sinh từ việc sử dụng các giao diện đầu vào và đầu ra của thiết bị di động, bao gồm NFC, Bluetooth và quét mã vạch 2D.

7.3.5.3 Cơ chế bảo vệ MFS phải tính đến nguy cơ dễ bị tấn công của kết nối giữa thiết bị di động và máy chủ.

7.3.5.4 Cần tính đến sức mạnh tổng hợp của các cơ chế bảo mật do xác thực khách hàng, bảo vệ dữ liệu bảo mật thiết bị di động và bảo mật ứng dụng nên được xem xét khi xác định các loại giao dịch nào được phép và loại dữ liệu nào có thể được lưu trữ trên thiết bị di động. MFS chỉ hỗ trợ các giao dịch có giá trị thấp và không yêu cầu lưu trữ dữ liệu nhạy cảm có thể yêu cầu ít bảo mật hơn so với MFS có thể được sử dụng cho các giao dịch có giá trị cao hoặc lưu trữ dữ liệu nhạy cảm của khách hàng.

7.3.6 Đào tạo khách hàng

Một MFSP nên đảm bảo rằng thông tin trước đó cung cấp cho khách hàng chứa các chi tiết cụ thể liên quan đến MFS. Những điều này nên bao gồm, nếu thích hợp:

- Thông tin rõ ràng về bất kỳ yêu cầu nào liên quan đến thiết bị của khách hàng, phần mềm hoặc công cụ cần thiết khác (ví dụ: các hệ điều hành/phiên bản/thiết bị di động tương thích);

- Hướng dẫn sử dụng thông tin xác thực đúng cách và bảo mật;

- Mô tả chi tiết về quy trình khách hàng gửi và xác thực giao dịch và/hoặc nhận thông tin, bao gồm hậu quả của từng hành động;

- Hướng dẫn sử dụng đúng cách và bảo mật tất cả phần cứng và phần mềm được cung cấp cho khách hàng;

- Các quy trình cần tuân theo trong trường hợp mất hoặc bị đánh cắp thông tin đăng nhập của phần cứng hoặc phần mềm của khách hàng khi đăng nhập hoặc thực hiện giao dịch

- Các thủ tục cần thực hiện nếu phát hiện hoặc nghi ngờ có hành vi lạm dụng

- Mô tả về trách nhiệm và nghĩa vụ của MFSP và khách hàng liên quan đến việc sử dụng MFS

7.4 Bộ yêu cầu bảo mật tối thiểu cho quản lý ứng dụng di động

7.4.1 Yêu cầu đăng ký và cung cấp cho khách hàng

7.4.1.1 Đối với bất kỳ việc đăng ký nào, khách hàng phải được MFSP xác thực. Quá trình xác thực này cần sử dụng nhiều yếu tố và/hoặc các kênh cung cấp đảm bảo bảo mật độc lập, có nghĩa là việc xâm phạm một yếu tố (ví dụ: mật khẩu bị xâm phạm) hoặc một kênh (ví dụ: phần mềm độc hại trên thiết bị) bị xâm phạm thì khả năng yếu tố hoặc kênh khác bị xâm phạm thì đồng thời là rất thấp.

7.4.1.2 Các ứng dụng tài chính di động phải được gắn vào thiết bị di động cụ thể tại thời điểm cài đặt, và tại thời điểm kích hoạt, phải được liên kết với một khách hàng đã được xác thực duy nhất và/hoặc những người khác do khách hàng đó lựa chọn. Do đó, ứng dụng này chỉ được sử dụng độc quyền cho các giao dịch của khách hàng đó và/hoặc những người khác mà khách hàng lựa chọn.

7.4.1.3 MFSP phải cung cấp phương tiện để khách hàng xác minh việc cài đặt và cá nhân hóa thành công bất kỳ ứng dụng tài chính di động nào đã được tải xuống.

7.4.1.4 MFSP phải quản lý một thứ mục của tất cả các MFS do thiết bị di động cung cấp

7.4.2 Quản lý khóa

7.4.2.1 MFSP hoặc đại lý của MFPS phải vận hành một hệ thống quản lý khóa để tạo ra các khóa duy nhất dành riêng cho các môi trường bảo mật hoặc thiết bị di động.

7.4.2.2 Tất cả các khóa được sử dụng để mã hóa/giải mã dữ liệu tài chính di động phải được tạo ra bằng trình tạo ngẫu nhiên hoặc bán ngẫu nhiên đã được chứng nhận theo các tiêu chuẩn được công nhận.

7.4.2.3 Việc cá nhân hóa các khóa phải kết hợp cơ chế xác thực để xác minh rằng các khóa đã được cá nhân hóa hiệu quả cho thiết bị mà chúng được sử dụng và các khóa này là hợp lệ.

7.4.2.4 MFSP phải ghi lại các thủ tục được sử dụng để bảo mật việc quản lý các khóa mật mã các thành phần của hệ thống di động sử dụng trong quá trình cá nhân hóa và vận hành tại chỗ của thành phần đó.

7.4.2.5 MFSP phải sử dụng các thuật toán mã hóa để bảo vệ việc truyền tải dữ liệu qua OTA.

CHÚ THÍCH: Tham khảo Phụ lục C để biết hướng dẫn.

7.4.2.6 Khóa mật mã phải được vận chuyển an toàn bằng cách sử dụng độc quyền các Khóa Trao Đổi Khóa (KEK) với độ entropy (độ hỗn loạn) cao, có nghĩa là phải có ít nhất độ entropy của khóa được vận chuyển.

7.4.2.7 Các thành phần trong suốt của khóa mật mã được hệ thống di động sử dụng phải được lưu trữ trong mô-đun bảo mật chống giả mạo và/hoặc, nếu có thể, trong một thiết bị sử dụng cơ chế chống giả mạo.

CHÚ THÍCH: Các nhà triển khai có thể tìm thấy hướng dẫn về yêu cầu bảo mật đối với HSM trong thông số kỹ thuật PCI-SCC.

7.4.3 Trao đổi nhà cung cấp dịch vụ tài chính di động và người quản lý dịch vụ đáng tin cậy

7.4.3.1 Tất cả các ứng dụng do MFSP cung cấp cho TSM phải được lưu trữ dưới dạng mã hóa với khả năng bảo vệ tính toàn vẹn.

7.4.3.2 Sau khi được mã hóa, TSM không được cho phép bất kỳ ứng dụng MFS nào hoặc dữ liệu nhạy cảm nào khác được giải mã, ngoại trừ mục đích là mã hóa lại chúng bằng khóa dành riêng cho thiết bị trước khi gửi chúng đến thiết bị người dùng cuối, hoặc truyền chúng trong hệ thống xử lý thanh toán.

7.4.4 Tải xuống ứng dụng

7.4.4.1 MFSP phải đảm bảo mã hóa đầu cuối giữa TSM và thiết bị di động.

7.4.4.2 Ứng dụng tài chính di động chỉ được cung cấp sau khi thiết lập được kênh bảo mật giữa thiết bị di động và nhà phân phối ứng dụng.

7.4.4.3 Kênh bảo mật phải bảo vệ tính toàn vẹn của ứng dụng MFS trong suốt quá trình tải xuống.

7.4.4.4 MFSP phải cung cấp phương tiện để xác thực ứng dụng đã tải xuống.

7.4.5 Hủy kích hoạt ứng dụng

7.4.5.1 MFSP phải cung cấp cho khách hàng phương tiện để hủy kích hoạt một phần hoặc toàn bộ ứng dụng tài chính di động.

7.4.5.2 Khi bị xâm phạm hoặc theo yêu cầu của khách hàng, MFSP phải cung cấp phương tiện để hủy kích hoạt từ xa, một phần hoặc toàn bộ, ứng dụng tài chính di động.

7.5 Tóm tắt: Yêu cầu đối với dịch vụ bảo mật cho dịch vụ tài chính di động

8 Yêu cầu bảo mật cho các thành phần mật mã được sử dụng cho MFS

8.1 Môi trường bảo mật cho thiết bị di động

8.1.1 Yêu cầu về thiết bị di động cho MFS

Tiêu chuẩn này xem thiết bị di động là môi trường có khả năng dễ bị tấn công. Các điều khoản sau tập trung vào các yêu cầu bảo mật cho môi trường an toàn trên thiết bị di động, được hiểu là những thuộc tính mong muốn giúp tăng cường tính toàn vẹn của các ứng dụng tài chính di động. Tiêu chuẩn này giả định rằng các hệ điều hành của thiết bị di động tiềm ẩn các rủi ro bảo mật, đặc biệt là khi chủng thực thi các ứng dụng MFS thuộc sở hữu của bên thứ ba.

Một thiết bị di động tuân thủ tiêu chuẩn này phải hỗ trợ các dịch vụ bảo mật phù hợp, có thể bao gồm một hoặc nhiều nội dung sau:

a) Đảm bảo việc thực thi an toàn các ứng dụng tài chính di động;

b) Xác định và xác thực người dùng hợp pháp của ứng dụng tài chính di động;

c) Cung cấp các giao diện truyền thông an toàn;

d) Hỗ trợ các biện pháp kiểm soát bảo mật phù hợp để lưu trữ các ứng dụng tài chính di động;

e) Mã hóa dữ liệu nhạy cảm khi được MFS yêu cầu;

f) Cung cấp cho khách hàng các cơ chế quản lý các ứng dụng tài chính di động sẵn có, bao gồm khi cần thiết: đăng ký an toàn, cài đặt ứng dụng, kích hoạt ứng dụng, liệt kê các ứng dụng có sẵn và lựa chọn chúng một cách an toàn;

g) Cung cấp yêu cầu ủy quyền cho MFSP hoặc dữ liệu cần thiết để xây dựng yêu cầu ủy quyền này (tức là khi POI yêu cầu ủy quyền);

h) Hỗ trợ các chức năng tùy chọn như tạo và xác minh chữ ký số di động hoặc các dịch vụ bảo mật khác do MFSP cung cấp.

Đặc biệt, một thiết bị di động phải triển khai ít nhất một môi trường bảo mật để lưu trữ và/hoặc thực thi các ứng dụng thanh toán di động.

Tiêu chuẩn này xác định năm cấp độ bảo mật cho môi trường an toàn. Các cấp độ này có thể được kết hợp:

- Có hai cấp độ là giải pháp bảo mật phần mềm thuần túy:

L1: Kiểm soát bảo mật phần mềm: Thường dựa vào việc làm rối mã hoặc phân tán mã và kiến trúc bảo mật hệ điều hành chung;

L2: Môi trường thực thi tin cậy (TEE) là giải pháp phần mềm thuần túy.

- Môi trường an toàn sử dụng phần cứng mở rộng L3:

L3: Môi trường thực thi tin cậy (TEE) với hỗ trợ phần cứng cụ thể (ví dụ: quản lý các ngữ cảnh thực thi chuyên dụng).

- Môi trường an toàn L4 và L5 yêu cầu phần cứng được chứng nhận bảo mật cụ thể cho mục đích lưu trữ và thực thi:

L4: Phần tử bảo mật (SE);

L5: Phần tử bảo mật và môi trường thực thi tin cậy (SE + TEE) thường được thiết kế để cung cấp giao diện người dùng đáng tin cậy.

Việc triển khai TEE hay SE không bắt buộc. Tuy nhiên, nếu MFSP quyết định sử dụng chúng, thì việc tuân thủ các yêu cầu trong 8.1.3 và 8.1.4 là yêu cầu tương ứng.

8.1.2 Môi trường bảo mật dựa trên phần mềm

8.1.2.1 Định nghĩa và chức năng cốt lõi

Môi trường bảo mật dựa trên phần mềm đề cập đến phần mềm thuần túy được sử dụng để bảo vệ dữ liệu MFS và chạy các ứng dụng sử dụng tài nguyên hệ điều hành của thiết bị di động. Công nghệ mô phỏng thẻ máy chủ (HCE) được sử dụng cho các thanh toán di động gần là một ví dụ về môi trường bảo mật dựa trên phần mềm.

8.1.2.2 Yêu cầu bảo mật

8.1.2.2.1 Dữ liệu nhạy cảm MFS tĩnh không được lưu trữ trong môi trường bảo mật phần mềm, trừ khi dữ liệu này được bảo vệ bởi một TEE.

8.1.2.2.2 Mã và dữ liệu lưu trữ trong môi trường bảo mật phần mềm phải được bảo vệ bằng các phương pháp cụ thể như làm rối mã và mã hóa hộp trắng.

8.1.2.2.3 Các giao dịch được khởi tạo từ môi trường bảo mật phần mềm phải sử dụng một mã thông báo thanh toán thay vì sử dụng mã định danh tài khoản thanh toán thực.

8.1.3 Môi trường thực thi tin cậy

8.1.3.1 Định nghĩa và chức năng cốt lõi

Môi trường thực thi tin cậy (TEE) là một môi trường bảo vệ, chạy hệ điều hành bảo mật trên bộ vi xử lý chính của thiết bị di động. TEE bao gồm các chức năng lưu trữ và quản lý khóa, tuân thủ ISO 11568. Nó cũng bao gồm lưu trữ bảo mật, có thể được sử dụng để lưu trữ nhật ký giao dịch và thông tin xác thực trong một khu vực riêng tư.

Thông thường, TEE:

- Triển khai và cô lập tài nguyên tính toán trong thiết bị di động,

- Kiểm soát các tài nguyên di động dễ bị tổn thương, đặc biệt là các thiết bị ngoại vi.

- Cung cấp các thuộc tính bảo mật cho ứng dụng tài chính di động đang thực thi để đảm bảo ứng dụng này miễn nhiễm với các mối đe dọa phần mềm độc hại, và

- Bổ sung môi trường thực thi bảo mật mà SE cung cấp, bao gồm việc cung cấp bất kì chức năng mã hóa nào mà MFSP yêu cầu bằng cách:

a) Mã nguồn của tất cả các ứng dụng tài chính di động nhạy cảm phải được thực thi trong môi trường cách ly và bảo vệ này, và

b) Dữ liệu nhạy cảm lưu trữ trong khu vực này phải được mã hóa

Hình 2 - Giao diện Logic để tích hợp TEE vào kiến trúc thiết bị di động

TEE bao gồm các chức năng mật mã cũng như chức năng lưu trữ và quản lý khóa. Nó cũng bao gồm lưu trữ khối lượng dữ liệu bảo mật, có thể được sử dụng để lưu trữ nhật ký giao dịch và thông tin xác thực trong khu vực riêng tư.

8.1.3.2 Giao diện người dùng đáng tin cậy: TEE và việc triển khai phần tử bảo mật

Tùy thuộc vào các trường hợp sử dụng, TEE cung cấp sự cân nhắc giữa sự linh hoạt cao và khả năng phát triển dễ dàng trên hệ điều hành di động với mức độ bảo mật thấp, và tính linh hoạt thấp và cùng những ràng buộc nghiêm ngặt khi phát triển trên phần tử bảo mật (Secure Element) với mức độ bảo mật cao.

Mục đích của TEE là bổ sung cho các phần tử bảo mật trong thiết bị di động, kết hợp việc triển khai giao diện người dùng đáng tin cậy (TUI). TUI này cung cấp một kênh giao tiếp bảo mật giữa Giao diện người dùng và môi trường bảo mật, có thể là trong thiết bị di động hoặc trên máy chủ từ xa.

TUI kiểm soát màn hình và bàn phím và/hoặc bàn di chuột, tách chúng khỏi hệ điều hành, từ đó đảm bảo các dịch vụ bảo mật sau:

- Xác thực bảo mật: nhập thông tin xác thực được bảo vệ, có thể được truyền qua một kênh giao tiếp riêng tư đến phần tử bảo mật, hoặc đến máy chủ để xác minh trực tuyến.

- Chống chối bỏ: thông tin giao dịch quan trọng được hiển thị trên màn hình thiết bị di động theo cách mà không thể bị giả mạo. Các kiểm soát truy cập để xác thực người dùng hợp pháp yêu cầu sự hiện diện của một mô-đun phần mềm đang chạy trên thiết bị di động hoặc trong chính phần tử bảo mật.

Các đặc tính bảo mật của việc triển khai TEE cần được chứng minh thông qua quy trình đánh giá và chứng nhận bảo mật. Điều 9.5 hướng dẫn về chứng nhận TEE.

8.1.4 Yêu cầu đối với phần tử bảo mật

8.1.4.1 Bảo mật ở cấp độ phần cứng

8.1.4.1.1 Các phần tử bảo mật phải cung cấp khả năng lưu trữ và xử lý dữ liệu nhạy cảm trong một mô-đun điện toán tách biệt về mặt vật lý. Dữ liệu bí mật cũng phải được bảo vệ khỏi các cuộc tấn công tiết lộ thông tin ngay cả khi cuộc tấn công gây ra sự phá hủy vật lý của SE.

8.1.4.1.2 Các phần tử bảo mật phải cung cấp môi trường thực thi biệt lập cho MFS, có nghĩa là khả năng chạy phần mềm ứng dụng hoàn toàn tách biệt khỏi mã khác trong phần tử bảo mật hoặc trong các thành phần khác của thiết bị di động.

3.1.4.1.3 Các phần tử bảo mật phải được thiết kế với các cơ chế bảo mật vật lý để có khả năng chống phá hoại tích hợp

8.1.4.1.4 Các phần tử bảo mật phải xác minh tính toàn vẹn và tính xác thực của phần lõi (firmware) và phần mềm đã tải về trước khi cài đặt, cũng như cung cấp cơ chế để xác minh các phiên bản firmware hoặc phần mềm đã cài đặt (ví dụ: số bản phát hành, ngày tháng).

8.1.4.1.5 Các phần tử bảo mật phải có khả năng tự xác thực động với nhà cung cấp SE.

8.1.4.1.6 Các phần tử bảo mật phải được thiết kế sao cho một kẻ tấn công không thể mạo danh được phần tử bảo mật.

8.1.4.1.7 Việc sản xuất và cá nhân hóa các phần tử bảo mật phải diễn ra trong môi trường ngăn ngừa các vấn đề sau:

- Xâm phạm khóa trong quá trình cá nhân hóa;

- Cá nhân hóa lạm dụng hoặc trái phép;

- Tải lên phần mềm và dữ liệu trái phép;

- Hành vi đánh cắp các phần tử bảo mật.

8.1.4.2 Bảo vệ và sử dụng dữ liệu nhạy cảm

8.1.4.2.1 Bảo vệ dữ liệu xác thực

8.1.4.2.1.1 Phần tử bảo mật phải triển khai một cơ chế bảo mật cho việc cá nhân hóa dữ liệu xác thực.

8.1.4.2.1.2 Các phần tử bảo mật phải hỗ trợ kiến trúc bảo mật bao gồm một miền bảo mật của nhà cung cấp SE với các thông tin xác thực riêng và các miền bảo mật bổ sung tùy chọn.

8.1.4.2.1.3 Nếu có, các miền bảo mật bổ sung phải lưu trữ các thông tin xác thực độc lập.

8.1.4.2.1.4 Các phần tử bảo mật phải được thiết kế để tạo ra dữ liệu động cho việc xác thực.

8.1.4.2.1.5 Các phần tử bảo mật phải cung cấp cơ chế phản hồi chống giả mạo (ví dụ: xóa dữ liệu - zeroization) cho thông tin xác thực được lưu trữ.

8.1.4.2.2 Dữ liệu xác minh người dùng

8.1.4.2.2.1 Các phần tử bảo mật phải có khả năng lưu trữ dữ liệu xác minh người dùng tham chiếu và so sánh với dữ liệu mà người dùng nhập vào.

8.1.4.2.2.2 Các phần tử bảo mật phải hỗ trợ một cơ chế sao cho dữ liệu xác minh người dùng không thể bị phát lại.

8.1.4.2.3 Quản lý và bảo vệ khóa mật mã

8.1.4.2.3.1 Nhà cung cấp phần tử bảo mật phải thực hiện một chính sách cho việc triển khai, quản lý và có thể thay đổi hoặc gia hạn định kì các khóa mật mã.

8.1.4.2.3.2 Khóa mật mã chỉ được sử dụng với các thuật toán mật mã phù hợp theo tiêu chuẩn ISO tham khảo trong Phụ lục C.

8.1.4.2.3.3 Miền bảo mật của nhà cung cấp phần tử bảo mật phải lưu trữ và quản lý các khóa mật mã cho các mục đích sau:

- Cung cấp bảo mật qua sóng

- Quản lý nội dung của phần tử bảo mật;

- Tạo và quản lý miền bảo mật bổ sung.

8.1.4.2.3.4 Miền bảo mật của nhà cung cấp phần tử bảo mật phải sử dụng riêng các khóa cụ thể để truyền tải an toàn các khóa mật mã khác.

8.1.4.2.3.5 Các miền bảo mật bổ sung có thể dựa vào trình quản lý khóa miền bảo mật của nhà cung cấp phần tử bảo mật để tải ứng dụng, hoặc phải có trình quản lý khóa riêng.

8.1.4.2.3.6 Các phần tử bảo mật phải cung cấp xác thực dựa trên danh tính cho việc sử dụng khóa riêng đối xứng hoặc bất đối xứng.

8.1.4.2.3.7 Các phần tử bảo mật phải cung cấp cơ chế phản hồi chống giả mạo (ví dụ: xóa dữ liệu) đối với các khóa mật mã đã lưu trữ.

8.1.4.2.3.8 Các phần tử bảo mật phải cung cấp cơ chế phát hiện giả mạo và xóa khóa mật mã.

8.1.4.2.3.9 Các phần tử bảo mật phải cung cấp cơ chế để phát hiện và ngăn chặn mọi nỗ lực tái sử dụng các khóa mật mã đã bị xóa.

8.1.4.2.4 Tính toàn vẹn và bảo mật dữ liệu ứng dụng

8.1.4.2.4.1 Phần tử bảo mật phải đảm bảo tính bí mật và toàn vẹn của dữ liệu ứng dụng cả khi đang lưu trữ và khi được xử lý.

8.1.4.2.4.2 Các ứng dụng MFS và các ứng dụng khác lưu trú trong phần tử bảo mật phải được cô lập bằng cơ chế tường lửa.

8.1.4.2.4.3 Phần tử bảo mật phải xác thực bất kỳ ứng dụng nào cố gắng sử dụng phần tử bảo mật.

8.1.4.2.4.4 Dữ liệu ứng dụng được lưu trữ và/hoặc xử lý bởi phần tử bảo mật phải được bảo vệ khỏi việc thao túng trái phép.

8.1.4.2.4.5 Khi một miền bảo mật hoặc ứng dụng cư trú sử dụng chữ ký số để xác thực dữ liệu và đảm bảo không thể chối bỏ, các yêu cầu trong 8.1.5 sẽ được áp dụng.

8.1.4.2.4.6 Khi bảo vệ dữ liệu trong quá trình truyền, phần tử bảo mật phải sử dụng các khóa riêng biệt cho tính bảo mật và toàn vẹn.

8.1.4.2.4.7 Việc mã hóa, giải mã, xác minh và tạo dữ liệu liên quan đến xác thực phải được xử lý bên trong phần tử bảo mật.

8.1.4.2.5 Ghi nhật ký giao dịch

8.1.4.2.5.1 Dữ liệu liên quan đến các giao dịch được xử lý bởi phần tử bảo mật phải được ghi lại.

8.1.4.2.5.2 Việc xử lý nhật ký phải được bảo mật.

8.1.4.2.5.3 Dữ liệu nhật ký đã lưu phải được bảo vệ chống lại việc tiết lộ và thao túng trái phép, và chỉ được truyền một cách an toàn cho một thực thể được ủy quyền.

8.1.5 Yêu cầu về phần tử bảo mật đối với dịch vụ chữ ký số

8.1.5.1 Cơ sở lý luận

Chữ ký số trên thiết bị di động là một chức năng có thể cần thiết khi truy cập vào MFS, nơi yêu cầu bằng chứng không thể chối bỏ về sự đồng ý từ người dùng hợp pháp. Điều này giả định rằng việc giao tiếp giữa người dùng và máy chủ có thể diễn ra trên cả thiết bị di động tin cậy ("đã đồng ý") và thiết bị dễ bị tấn công.

8.1.5.2 Thiết bị di động tin cậy để tạo chữ ký số

8.1.5.2.1 Thiết bị di động có chữ ký đáng tin cậy phải đảm bảo rằng thông tin hiển thị được bao gồm trong dữ liệu đã ký.

8.1.5.2.2 Thiết bị di động có chữ ký đáng tin cậy phải đảm bảo không ghi lại và không tiết lộ trái phép dữ liệu do khách hàng nhập vào.

8.1.5.2.3 Thiết bị di động có chữ ký đáng tin cậy phải vượt qua quy trình đánh giá và chứng nhận theo hồ sơ bảo vệ [theo tiêu chuẩn ISO 15408 (tất cả các phần)], có tính đến bản chất của các dịch vụ tài chính cần truy cập và môi trường mà dịch vụ đó được vận hành.

8.1.5.3 Yêu cầu áp dụng cho chữ ký số được tạo ra bởi thiết bị di động

8.1.5.3.1 Một ứng dụng tạo chữ ký số cư trú trong một phần tử bảo mật có thể được chạy trên các thiết bị di động hoàn toàn đáng tin cậy hoặc trên một thiết bị di động kém bảo mật hơn, tùy thuộc vào mức độ bảo mật yêu cầu bởi MFSP.

8.1.5.3.2 thiết bị di động tin cậy phải xác thực với phần tử bảo mật có ký hoặc với môi trường bên ngoài.

8.1.5.3.3 Chữ ký do ứng dụng cư trú trong một phần tử bảo mật tạo ra bằng cách sử dụng thiết bị di động tin cậy phải bao gồm bằng chứng chứng minh thiết bị di động đó là xác thực.

8.1.5.3.4 Khi phần tử bảo mật có ký được sử dụng để xác thực một thiết bị di động và/hoặc MFS, người dùng phải được cung cấp bằng chứng về tính xác thực của thiết bị di động và/hoặc MFS.

8.1.5.3.5 Việc sử dụng phần tử bảo mật có ký trong bất kỳ thiết bị di động nào không được làm suy yếu sự tính bảo mật của thiết bị di động tin cậy. Ví dụ, phần tử bảo mật có ký phải hỗ trợ hai thông tin xác thực khác nhau để ủy quyền chữ ký số tại một thiết bị đầu cuối đã được đồng ý hoặc không đồng ý. Mục tiêu là không làm tổn hại thông tin xác thực ban đầu được sử dụng cho các ứng dụng nhạy cảm cao, theo ý của MFSP là do việc sử dụng phần tử bảo mật có ký trong thiết bị di động không đồng ý và có thể bị giả mạo.

8.1.5.3.6 Máy chủ dấu thời gian phải được triển khai dưới sự quản lý của một nhà cung cấp dịch vụ dấu thời gian. Khi MFS yêu cầu một dấu thời gian, chữ ký số do phần tử bảo mật ký tạo ra phải bao gồm bằng chứng về danh tính của máy chủ dấu thời gian.

8.1.5.3.7 Các thuật toán chữ ký số được hỗ trợ bởi phần tử bảo mật có ký phải phù hợp theo các tiêu chuẩn ISO tham khảo trong Phụ lục C.

8.1.5.3.8 Theo yêu cầu của thiết bị di động tin cậy và theo các quy tắc truy cập liên quan, phần tử bảo mật có ký phải tạo ra một cặp khóa bất đối xứng, một khóa riêng tư cho chữ ký số và một khóa công khai để xác minh mục đích của chữ ký.

8.1.5.3.9 Phần tử bảo mật có ký phải xác thực hai loại máy chủ: những máy chủ quản lý danh sách thu hồi chứng chỉ (CRL), hoặc giao thức trạng thái chứng chỉ trực tuyến (OCSP) thay thế cho CRL, và máy chủ cung cấp dịch vụ dấu thời gian.

8.1.5.3.10 Ngoài các thuật toán và định dạng cần thiết để hỗ trợ các chức năng trên, sự tương tác giữa thiết bị di động và các phần tử bảo mật có ký phải tuân thủ các tiêu chuẩn ISO liên quan (ví dụ: ISO/IEC 7816).

8.1.5.3.11 Khả năng tương tác của phần tử bảo mật có ký yêu cầu phải tuân thủ với các tiêu chuẩn xác định cú pháp cho quá trình tương tác dữ liệu được chuyển giao. Cụ thể, cú pháp cho các tin nhắn có ký số (bao gồm chứng chỉ) phải độc lập với thuật toán chữ ký đã sử dụng.

CHÚ THÍCH: W3C đã chỉ định một cú pháp và quy trình chữ ký XML. Các tổ chức tiêu chuẩn hóa châu Âu CEN và ETSI đã phát triển một số tiêu chuẩn cho sản phẩm chữ ký điện tử. Tại Hoa Kỳ, tiêu chuẩn X9 là X9.31, dựa trên NIST FPS 186-2.

8.1.5.3.12 Phần tử bảo mật có ký cho các ứng dụng tài chính phải có khả năng xử lý các thuật toán khóa công khai. Phần tử bảo mật có ký cũng phải có khả năng hỗ trợ nhiều ứng dụng, yêu cầu chữ ký số cho mục đích xác thực và không thể chối bỏ với các yêu cầu đặc biệt (đếm, nhật ký chữ ký). Mỗi ứng dụng tài chính trong phần tử bảo mật có ký có thể có cặp khóa riêng và chứng chỉ số cụ thể tương ứng với ứng dụng đó.

8.1.5.3.13 Phần tử bảo mật có ký phải hỗ trợ hai phương pháp sau để tạo cặp khóa bất đối xứng cho việc tạo chữ ký số:

- Tạo cặp khóa cho phần tử bảo mật và chứng nhận khóa công khai bởi cơ quan chứng nhận (CA);

- Tạo cặp khóa bởi CA, sau đó cá nhân hóa các khóa này vào phần tử bảo mật cùng với chứng chỉ công khai. Quy trình cá nhân hóa này phải diễn ra thông qua một kênh bảo mật đầu-cuối cao giữa máy chủ CA và phần tử bảo mật có ký.

8.2 Yêu cầu bảo mật đối với các mô-đun mật mã sử dụng cho MFS

8.2.1 Tổng quan

Các chương trình MFS sử dụng rộng rãi các mô-đun mật mã để bảo vệ tin nhắn, khóa mật mã và các dữ liệu nhạy cảm khác được MFS sử dụng. Mô-đun mật mã được định nghĩa là tập hợp phần cứng, phần mềm và/hoặc phần lõi (firmware) thực hiện các chức năng bảo mật được phê chấp thuận trong ranh giới mật mã do ISO 19790 chỉ định (bao gồm các thuật toán mật mã và tạo khóa).

Tính bảo mật của MFS phần lớn phụ thuộc vào tính bảo mật của các mô-đun mật mã này.

Bốn cấp độ bảo mật tiêu chuẩn đối với các mô-đun mật mã được xác định trong ISO/IEC 19790. Mỗi cấp độ bảo mật đều tăng cường tính bảo mật cao hơn so với cấp độ trước đó:

- Cấp độ bảo mật 1 cung cấp mức độ bảo mật thấp nhất với các cơ chế bảo mật vật lý cụ thể đã yêu cầu và cho phép các thành phần phần mềm và phần lõi (firmware) của mô-đun mật mã được thực thi trên hệ thống máy tính đa mục đích mà sử dụng hệ điều hành chưa được đánh giá.

- Cấp độ bảo mật 2 nâng cao cơ chế bảo mật của mô-đun mật mã cấp độ 1 bằng cách bổ sung yêu cầu về chứng cứ chống giả mạo và tối thiểu là xác thực dựa trên vai trò.

- Cấp độ bảo mật 3 cải thiện các cấp độ bảo mật thấp hơn bằng cách yêu cầu các cơ chế phát hiện và phòng ngừa để ngăn chặn xâm nhập truy cập vào bất kỳ tham số bảo mật quan trọng nào (CSP) như khóa đối xứng hoặc khóa riêng bất đối xứng, và các thông tin xác thực. Xác thực được tăng cường bằng cách yêu cầu các cơ chế xác thực dựa trên danh tính (so với cơ chế dựa trên vai trò). Hơn nữa, yêu cầu phải phân tách các cổng dữ liệu cho CSP khỏi các loại thông tin khác.

- Cấp độ bảo mật 4 cung cấp mức bảo mật cao nhất, yêu cầu một lớp bảo vệ hoàn chỉnh xung quanh mô-đun mật mã với mục đích phát hiện và phản hồi mọi nỗ lực truy cập vật lý trái phép. Các cơ chế phát hiện và phòng ngừa yêu cầu xóa dữ liệu (zeroization) của CPS.

Nói chung, Cấp độ bảo mật 1 là một mô-đun phần mềm chạy trên máy tính đa mục đích, cấp độ bảo mật 2 có thể là một mô-đun phần mềm hoặc phần cứng, cấp độ bảo mật 3 là mô-đun phần cứng, hoặc có thể là mô-đun phần mềm chạy trên máy tính chuyên dụng đã được đánh giá chính thức theo Các tiêu chí chung của cấp đảm bảo đánh giá (EAL) 3 hoặc cao hơn. Cấp độ bảo mật 4 luôn là mô-đun phần cứng dành cho mục đích đặc biệt. Hầu hết các mô-đun bảo mật phần cứng mục đích đặc biệt (HSM) đều là cấp độ bảo mật 3, nhưng một số được chứng nhận ở cấp độ bảo mật 4 khi hoạt động ở chế độ ISO/IEC 19790. Các mô-đun mật mã loại 1 được quân đội và một số cơ quan chính phủ sử dụng được chứng nhận bằng một quy trình đánh giá chính thức khác. Các mô-đun mật mã khác không được chứng nhận chính thức là các mô-đun loại 1 hoặc loại 2 được gọi là mô-đun loại 3.

8.2.2 Danh sách yêu cầu đối với các mô-đun phần cứng mật mã

8.2.2.1 Mô-đun mật mã phần cứng phải được thiết kế tuân thủ ISO/IEC 19790. Cụ thể, mô-đun phải được thiết kế sao cho bất kỳ nỗ lực can thiệp nào vào nó sẽ phá hủy toàn bộ các tài liệu mật mã đã lưu trữ.

8.2.2.2 Mô-đun mật mã phần cứng phải triển khai ít nhất một trong các chức năng bảo mật theo tiêu chuẩn ISO/IEC 19790:2012, Phụ lục C. MFSP có thể chỉ định thêm một chức năng bảo mật không có trong Phụ lục C nhưng được MFS yêu cầu.

8.2.2.3 Nếu ứng dụng xóa các khóa, nó phải đảm bảo rằng mô-đun hoạt động đầy đủ khi một khóa bị xóa. Nếu không, khóa đã xóa có thể xuất hiện lại khi mô-đun được phục hồi.

8.2.2.4 Ngoài các yêu cầu được quy định trong ISO/IEC 19790, MFSP có thể quyết định có các thủ tục và chính sách bổ sung cho chức năng sẵn sàng cao của các dịch vụ do mô-đun cung cấp. Cụ thể, MFSP phải triển khai và tài liệu hóa chính sách phục hồi trong trường hợp mất điện.

8.2.2.5 MFSP phải làm rõ bản chất của các dịch vụ mật mã, nếu có, mà mô-đun mật mã có thể cung cấp trong chế độ hoạt động suy yếu.

8.2.3 Yêu cầu đối với mô-đun phần mềm mật mã

Một mô-đun phần mềm có thể đạt được cấp độ bảo mật 2 theo ISO/IEC 19790 bằng cách hỗ trợ xác thực dựa trên vai trò và cung cấp cơ chế bằng chứng chống giả mạo. Đối với phần mềm, điều này có nghĩa là phát hiện mã thực thi (nhị phân) đã bị thay đổi theo cách nào đó, khiến mô-đun không còn là bản sao hợp lệ của mã gốc. Đây là một loại lỗ hổng phần mềm độc hại mà mặc dù không nhất thiết phải ngăn ngừa được nhưng vẫn có thể phát hiện được. Các sản phẩm chống virus có thể phát hiện, cảnh báo và cách ly mô-đun phần mềm đã bị sửa đổi. Chữ ký mã có thể được sử dụng để xác minh phần mềm trước khi thực thi, trong các đợt quét định kỳ, hoặc tại thời điểm tải xuống mã mới như một phần của hệ thống quản lý vòng đời lỗ hổng bảo mật (VLMS) tổng thể.

Chữ ký mã dựa trên các thuật toán mật mã như hàm băm, chữ ký số hoặc dấu thời gian đáng tin cậy. Một hàm băm đơn lẻ không đủ để phát hiện sự sửa đổi mã do có thể xảy ra va chạm (cùng một giá trị băm được tạo ra từ nhiều hơn một chuỗi nhị phân). Hàm băm bảo mật (xem Phụ lục C) và/hoặc việc sử dụng các khóa mật mã có thể ngăn chặn một cách nghiêm ngặt khả năng của kẻ xâm nhập trong việc sửa đổi hoặc tạo ra một mô-đun phần mềm khác mà sẽ tạo ra một hàm băm đã tồn tại.

9 Các khía cạnh đánh giá và chứng nhận bảo mật

9.1 Khuyến nghị chung

Mỗi thành phần của hệ thống thanh toán di động phải trải qua một quá trình đánh giá và chứng nhận bảo mật của bên thứ ba độc lập. Việc đánh giá các thành phần vật lý như mô-đun mật mã có thể được thực hiện phần lớn bằng các quy trình tiêu chuẩn. Việc xem xét các đối thủ mạnh nhất hiện có và tận dụng những tiến bộ phân tích mật mã mới nhất trong quá trình đánh giá phần cứng mật mã là rất quan trọng khi xét đến khó khăn trong việc khắc phục các vi phạm bảo mật.

Điều này cung cấp tổng quan về các phương pháp đánh giá bảo mật khác nhau dựa trên các tiêu chuẩn ISO có thể được sử dụng để chứng nhận các thành phần theo yêu cầu của MFS.

9.2 Mô-đun mật mã

Một mô-đun mật mã được định nghĩa là tập hợp phần cứng, phần mềm và/hoặc phần lõi (firmware) thực hiện các chức năng bảo mật đã được phê duyệt trong phạm vi mật mã được quy định bởi ISO/IEC 19790 (bao gồm các thuật toán mật mã và tạo khóa). Bốn cấp độ bảo mật tiêu chuẩn đối với các mô-đun mật mã được định nghĩa trong ISO/IEC 19790. Mỗi cấp độ bảo mật cung cấp mức độ bảo mật cao hơn so với cấp độ trước đó.

- Cấp độ bảo mật 1 cung cấp mức bảo mật thấp nhất với các cơ chế bảo mật vật lý cụ thể được yêu cầu và cho phép các thành phần phần mềm và phần lõi của mô-đun mật mã được thực thi trên một hệ thống máy tính đa mục đích sử dụng hệ điều hành chưa được đánh giá.

- Cấp độ bảo mật 2 nâng cao các cơ chế bảo mật của mô-đun mật mã cấp độ 1 bằng cách bổ sung yêu cầu chứng cứ chống giả mạo và tối thiểu là xác thực dựa trên vai trò.

- Cấp độ bảo mật 3 cải thiện các cấp độ bảo mật thấp hơn bằng cách yêu cầu các cơ chế phát hiện và phòng ngừa để ngăn chặn xâm nhập truy cập vào bất kỳ tham số bảo mật quan trọng nào (CSP) như khóa đối xứng hoặc khóa riêng bất đối xứng, và các thông tin xác thực. Xác thực được tăng cường bằng cách yêu cầu các cơ chế dựa trên danh tính (so với cơ chế dựa trên vai trò). Hơn nữa, cần phải phân tách các cổng dữ liệu cho CSP khỏi các loại thông tin khác.

- Cấp độ bảo mật 4 cung cấp mức bảo mật cao nhất, yêu cầu một lớp bảo vệ hoàn chỉnh xung quanh mô-đun mật mã với mục đích phát hiện và phản hồi mọi nỗ lực truy cập vật lý trái phép. Các cơ chế phát hiện và phòng ngừa yêu cầu xóa dữ liệu của CPS.

Nói chung, Cấp độ Bảo mật 1 là một mô-đun phần mềm chạy trên máy tính đa mục đích, cấp độ Bảo mật 2 có thể là mô-đun phần mềm hoặc phần cứng, cấp độ Bảo mật 3 là mô-đun phần cứng hoặc có thể là phần mềm chạy trên máy tính chuyên dụng và đã được đánh giá chính thức theo Các tiêu chí chung của cấp đảm bảo đánh giá (EAL) 3 hoặc cao hơn. Cấp độ Bảo mật 4 luôn là mô-đun phần cứng dành cho mục đích đặc biệt. Hầu hết các mô-đun bảo mật phần cứng mục đích đặc biệt (HSM) đều là cấp độ bảo mật 3, nhưng một số được chứng nhận ở cấp độ bảo mật 4 khi hoạt động ở chế độ ISO/IEC 19790. Các mô-đun mật mã loại 1 được quân đội và một số cơ quan chính phủ sử dụng được chứng nhận bằng một quy trình đánh giá chính thức khác. Các mô-đun mật mã khác không được chứng nhận chính thức là các mô-đun loại 1 hoặc loại 2 được gọi là mô-đun loại 3.

9.3 Mô-đun phần mềm

Một mô-đun phần mềm có thể đạt Cấp độ Bảo mật 2 theo ISO/IEC 19790 bằng cách hỗ trợ xác thực dựa trên vai trò và cung cấp cơ chế bằng chứng chống giả mạo. Đối với phần mềm, điều này có nghĩa là phát hiện mã thực thi (nhị phân) đã bị thay đổi theo cách nào đó, khiến mô-đun không còn là bản sao hợp lệ của mã gốc. Đây là một loại lỗ hổng phần mềm độc hại mà mặc dù không nhất thiết phải ngăn ngừa được nhưng vẫn có thể phát hiện được. Các sản phẩm chống virus có thể phát hiện, cảnh báo và cách ly mô-đun phần mềm đã bị sửa đổi. Chữ ký mã có thể được sử dụng để xác minh phần mềm trước khi thực thi, trong các đợt quét định kỳ, hoặc tại thời điểm tải xuống mã mới như một phần của hệ thống quản lý vòng đời lỗ hổng bảo mật (VLMS) tổng thể.

Chữ ký mã dựa trên các thuật toán mật mã như băm (hash), chữ ký số hoặc dấu thời gian đáng tin cậy. Một hàm băm đơn lẻ không đủ để phát hiện sự sửa đổi mã do có thể xảy ra va chạm (cùng một giá trị băm được tạo ra từ nhiều hơn một chuỗi nhị phân). Hàm băm bảo mật (xem Phụ lục C) và/hoặc việc sử dụng các khóa mật mã có thể ngăn chặn một cách nghiêm ngặt khả năng của kẻ xâm nhập trong việc sửa đổi hoặc tạo một mô-đun phần mềm khác mà sẽ tạo ra một hàm băm đã tồn tại.

9.4 Khả năng tương tác của các chứng nhận bảo mật

Việc chứng nhận các ứng dụng tài chính di động đặt ra một số vấn đề về khả năng tương tác liên quan đến việc công nhận lẫn nhau giữa các chứng nhận bảo mật do các tổ chức chứng nhận khác nhau phát hành. Các ứng dụng tài chính di động nên được xây dựng trên các nền tảng đã được chứng nhận.

Trong điều khoản này, thuật ngữ nền tảng đề cập đến một thiết bị phần cứng và phần mềm, bên trong một thiết bị di động được tạo thành từ một mạch tích hợp được chứng nhận, lưu trữ:

- một hệ điều hành,

- một trình thông dịch hoặc máy ảo, và

- một hoặc nhiều ứng dụng tài chính di động.

Tiêu chuẩn này phân biệt giữa hai tình huống sau:

- Khi nền tảng được phát hành bởi một tổ chức chịu trách nhiệm chứng nhận cả nền tảng và ứng dụng, quy trình chứng nhận cũ có thể được sử dụng. Trong trường hợp này, các phương pháp đánh giá và chứng nhận bảo mật, ví dụ như đối với thẻ thanh toán truyền thống, sẽ cần phải được điều chỉnh.

- Khi nền tảng được phát hành bởi bên thứ ba chịu trách nhiệm chứng nhận nền tảng, và theo các quy tắc của hệ thống, một tổ chức muốn tải xuống ứng dụng của riêng mình trong nền tảng này, sử dụng cơ chế theo TCVN 14488-3 (ISO/TS 12812-3). Trong trường hợp này, nhiều giao diện để đảm bảo khả năng tương tác lẫn nhau sẽ được sử dụng.

Trong tình huống này, từ góc độ tài chính, vấn đề nằm ở mức độ tin cậy mà một nền được phát hành bởi bên thứ ba (ví dụ: MNO) cung cấp để thực thi một ứng dụng tài chính di động thường thuộc sở hữu của một tổ chức tài chính.

Sự khác biệt lớn thứ hai với chứng nhận thẻ truyền thống nằm ở chỗ thực tế các ứng dụng tài chính di động có thể được tải xuống trong SE sau khi SE được phát hành. Trong trường hợp này, một ứng dụng nhất định có thể được tải xuống qua nhiều nền tảng từ cùng một hoặc các nhà cung cấp khác nhau.

- Ứng dụng này đã được chứng nhận ở một nền tảng, trong trường hợp chung là khác với nền tảng mục tiêu trong một hệ thống và sử dụng phương pháp đánh giá bảo mật đã cho. Vì vào thời điểm đó, ứng dụng đã được chứng nhận.

a) Nhà cung cấp ứng dụng không quan tâm nền tảng mà ứng dụng sẽ được tải xuống và thực thi.

b) Các lỗ hổng có thể có của ứng dụng nếu nó được cài đặt trên nền tảng khác.

c) Các lỗ hổng có thể có của nền tảng đã được phát hiện.

Trong trường hợp chung, các nền tảng này đã được nhiều phòng thí nghiệm bảo mật khác nhau đánh giá, không nhất thiết phải sử dụng cùng một phương pháp.

Các tình huống sau có thể được phân biệt để chứng nhận.

- Khi cả nền tảng và các ứng dụng đều thuộc sở hữu của tổ chức, quá trình chứng nhận sẽ tương tự như quy trình chứng nhận thẻ thanh toán đơn hoặc đa ứng dụng.

- Khi nền tảng được sở hữu bởi bên thứ ba, và ứng dụng thuộc sở hữu của một tổ chức, phạm vi chứng nhận bao gồm nền tảng được cá nhân hóa với ít nhất một ứng dụng tài chính di động.

Một ví dụ cụ thể là đánh giá và chứng nhận bảo mật của một phần tử bảo mật cho các ứng dụng tài chính di động. Một khi một ứng dụng di động đã được chứng nhận qua một nền tảng (SE) do nhà cung cấp A cung cấp sử dụng phương pháp bảo mật của Phòng thí nghiệm A, sẽ hợp lý nếu tái sử dụng một phần kết quả đánh giá này nếu cùng một ứng dụng đó có thể thực thi trên một nền tảng (SE do nhà cung cấp B sản xuất).

Trường hợp này dẫn đến sự cần thiết phải hài hòa các đặc tính bảo mật và chức năng của các nền tảng phù hợp cho việc lưu trữ và thực thi ứng dụng nhất định. Do đó, nhà cung cấp SE sẽ xử lý một loạt các ứng dụng tài chính di động và cũng đã trang bị các phần tử bảo mật từ các nền tảng chống giả mạo phần cứng được chứng nhận khác nhau do các nhà cung cấp khác nhau cấp. Nhà cung cấp ứng dụng sẽ không cần phải chứng nhận ứng dụng của mình với tất cả các nền tảng được chứng nhận.

9.5 Hướng dẫn đánh giá và chứng nhận bảo mật TEE

Bất kỳ triển khai TEE nào cũng cần có khả năng cung cấp bằng chứng về năng lực "đáng tin cậy" của mình thông qua việc đánh giá sản phẩm nhằm xác định các đặc tính bảo mật của sản phẩm.

Mức độ đảm bảo cao hơn xuất phát từ một nỗ lực đánh giá lớn hơn, thông qua phạm vi rộng hơn, và sự chú ý kỹ lưỡng đến các chi tiết nhỏ hoặc một quy trình đánh giá chính thức hơn.

- Nếu phương pháp Tiêu chí Chung (CC, ISO/IEC 15408) được MFS lựa chọn, mức độ đảm bảo phải tương đương với gói đảm bảo được xác định là EAL2+ extended AVA_VAN.2 trong phương pháp CC.

- Trong trường hợp ưu tiên FIPS 140-2, đánh giá bảo mật phải tuân thủ ít nhất mức độ FIPS 140-2 Cấp độ 3 hoặc mức độ đảm bảo cao hơn.

10 Yêu cầu bảo mật cho thanh toán di động gần

10.1 Tổng quan

Việc triển khai bảo mật các thanh toán di động gần yêu cầu thiết bị di động phải triển khai một kiến trúc bảo mật, cách ly các thành phần tin cậy và không đáng tin cậy cho mục đích lưu trữ và xử lý dữ liệu nhạy cảm, đồng thời ngăn chặn việc kích hoạt trái phép thiết bị di động (ví dụ: kích hoạt mô-đun NFC). Các yêu cầu trong điều khoản này được chia thành các yêu cầu chung cho thanh toán gần và yêu cầu cụ thể cho việc triển khai không tiếp xúc.

10.2 Yêu cầu bảo mật chung

10.2.1 Tính toàn vẹn của dữ liệu nhạy cảm và ứng dụng khi nghỉ

10.2.1.1 Các thiết bị di động phải thông báo cho người dùng khi giao diện thanh toán di động gần của thiết bị di động đang hoạt động.

10.2.1.2 Các thiết bị di động phải triển khai cơ chế để ngăn chặn việc thu thập dữ liệu trái phép khi ứng dụng thanh toán đang nghỉ (ví dụ: hủy kích hoạt giao diện kết nối cho thanh toán di động gần của thiết bị di động).

10.2.1.3 Dữ liệu nhạy cảm được sử dụng cho thanh toán gần phải được lưu trữ và xử lý riêng biệt trong một môi trường bảo mật biệt lập.

10.2.2 Xác thực

10.2.2.1 MFSP phải sử dụng một yếu tố xác thực động cho mỗi giao dịch thanh toán di động gần.

10.2.2.2 Ứng dụng thanh toán di động gần phải hỗ trợ ít nhất một UVM dựa trên kiến thức về mã di động. Khi cần thiết, mã di động phải được khách hàng nhập và xác minh.

10.2.2.3 MFSP phải cấu hình các tham số quản lý rủi ro của giao dịch (ví dụ: số tiền tối đa của giao dịch mà không yêu cầu nhập UVM) và đặc biệt là các điều kiện để xác minh người dùng trở nên cần thiết.

10.2.2.4 Nếu một mã di động được sử dụng làm UVM, mã này phải được bảo vệ bằng các yêu cầu phù hợp như được định nghĩa trong ISO 9564-2.

10.2.3 Bảo vệ dữ liệu trong quá trình truyền tải

10.2.3.1 Việc thiết lập một kênh bảo mật cho thanh toán di động gần không phải là bắt buộc. Nếu được triển khai, kênh bảo mật chỉ được thiết lập khi xác thực thành công ứng dụng thiết bị di động.

10.2.3.2 Các cơ chế mật mã phải được thiết kế để tối ưu hóa tỷ lệ bảo mật/thời gian giao dịch.

10.2.3.3 Đối với các giao dịch nhanh và có rủi ro thấp, có thể cân nhắc sử dụng mật mã nhẹ tiêu chuẩn tuân thủ ISO/IEC 29192 (tất cả các phần). ISO/IEC 29192 (tất cả các phần) phải được triển khai sao cho không có kẻ tấn công nào có thể khôi phục khóa phiên của một giao dịch mã hóa bị nghe lén.

11 Yêu cầu bảo mật cho các thanh toán di động từ xa

11.1 Tổng quan

Điều khoản này đưa ra các yêu cầu bổ sung nhằm đạt được hai mục tiêu bảo mật:

- Giảm gian lận;

- Tránh từ chối các giao dịch từ xa hợp pháp đã được chấp thuận.

11.2 Yêu cầu bảo mật

11.2.1 Xác thực

11.2.1.1 MFSP phải triển khai ít nhất một phương thức xác thực khách hàng động cho mỗi giao dịch thanh toán di động từ xa.

11.2.1.2 Các cơ chế xác thực sẽ được sử dụng phải phù hợp với mức độ rủi ro đã được đánh giá cho một giao dịch thanh toán di động từ xa cụ thể.

11.2.1.3 Tổ chức xử lý giao dịch thanh toán phải cung cấp các cơ chế để xác thực cổng thanh toán của thiết bị di động (ví dụ: bằng ứng dụng tài chính di động).

11.2.1.4 Nếu mã di động được sử dụng làm UVM, mã này phải được bảo vệ bằng các yêu cầu phù hợp như được định nghĩa trong ISO 9564-2.

11.2.2 Bằng chứng về sự đồng ý

11.2.2.1 Nhà cung cấp dịch vụ thanh toán di động từ xa phải cung cấp cho người thanh toán các phương tiện kỹ thuật (ví dụ: dựa trên mật mã) cần thiết để tạo ra bằng chứng không thể làm giả về sự đồng ý của người dùng đối với các điều khoản thanh toán, khi thanh toán vượt quá một số tiền nhất định. Cơ chế này cũng phải được cung cấp cho các nhà bán lẻ đã đăng ký chấp nhận thanh toán di động từ xa.

11.2.2.2 MFSP phải cung cấp cho người thanh toán bằng chứng chứng minh rằng giao dịch thanh toán từ xa đã diễn ra hoặc thông báo cho người thanh toán rằng quyền truy cập đã bị từ chối.

11.2.2.3 Một tin nhắn chứng minh sự đồng ý của người dùng cho giao dịch thanh toán di động từ xa không được phép tái sử dụng hoặc làm giả.

11.2.2.4 MFSP phải phê duyệt giao dịch thanh toán di động từ xa.

11.2.3 Yêu cầu xử lý cổng thanh toán

11.2.3.1 Cổng thanh toán phải hỗ trợ các thông số rủi ro của bên chấp nhận giao dịch.

11.2.3.2 Cổng thanh toán và MFSP phải đảm bảo tính toàn vẹn của việc dữ liệu xác thực và giao dịch.

11.2.3.3 MFSP phải xác thực cổng thanh toán.

CHÚ THÍCH: Nếu sử dụng công cụ thanh toán thẻ để thanh toán di động từ xa, MFSP là đơn vị tiếp nhận giao dịch.

12 Yêu cầu bảo mật cho dịch vụ ngân hàng di động

12.1 Tổng quan

Để có thể truy cập vào dịch vụ ngân hàng di động cần đáp ứng ít nhất ba điều kiện sau:

Khách hàng đã đăng ký dịch vụ cụ thể này (đăng ký);

- Khách hàng phải được xác thực;

- Thiết bị di động được kết nối với một máy chủ do tổ chức tài chính kiểm soát.

12.2 Cân nhắc về xác thực

Thông thường cần có ít nhất một quy trình xác thực hai yếu tố để có một quy trình vững chắc.

Các mức độ đảm bảo xác thực liên quan đến các mức độ tin cậy được thiết lập trước trong quá trình xác minh danh tính đã khai báo. Những mức độ này được xác định theo mức độ nghiêm trọng của tổn thất, về mặt tài chính hoặc uy tín của ngân hàng mà có thể xảy ra do gian lận trong quá trình xác thực. Mọi mức độ tin cậy đều liên quan đến các công nghệ và quy trình cụ thể cho các yếu tố xác thực được tích hợp trong hệ thống bảo mật do chính tổ chức tài chính hoặc bên thứ ba vận hành. Hệ thống bảo mật được xây dựng dựa trên chính sách bảo mật là kết quả của việc tổ chức tài chính này phân tích các mối đe dọa hệ thống, các tổn thất tiềm ẩn đã phát sinh và chi phí liên quan đến các biện pháp đối phó.

Một hệ thống bảo mật tốt là hệ thống trong đó các yêu cầu bảo mật được căn cứ vào động cơ tài chính của những người chịu trách nhiệm nếu hệ thống bị lỗi. Các ứng dụng ngân hàng di động có rủi ro cao phải yêu cầu ít nhất là tính toàn vẹn và tính xác thực của các tin nhắn nhạy cảm được trao đổi. Điều này có nghĩa là phải thiết lập một kênh bảo mật trước khi giao dịch diễn ra. Thêm vào đó, do các ràng buộc pháp lý, các dịch vụ bảo mật và không thể từ chối để bảo vệ tổ chức tài chính và khách hàng phải được hỗ trợ.

Bởi vì một xác thực thực thể thành công mở ra cánh cửa cho các dịch vụ ngân hàng, người ta cho rằng các cuộc tấn công bảo mật có khả năng sẽ nhắm vào các quy trình xác thực. Vì vậy, chính sách bảo mật của hệ thống phải xử lý cẩn thận các vấn để xác thực để giảm thiểu các mối đe dọa bao gồm:

- Thông tin xác thực: Các thông tin xác thực tĩnh yếu hơn các thông tin xác thực một lần, và một mã xác thực phần cứng tốt hơn mã phần mềm.

Giao thức xác thực: Một giao thức đã được chứng minh là an toàn trước các cuộc tấn công trung gian là yêu cầu cơ bản đối với dịch vụ ngân hàng từ xa. Một bằng chứng bảo mật của giao thức cung cấp các đảm bảo bổ sung chống lại một số cuộc tấn công nhất định.

Các thực thể cần được xác thực (ví dụ: xác thực lẫn nhau và/hoặc xác thực người dùng đa yếu tố): Người dùng, thiết bị di động, ứng dụng tài chính di động và máy chủ tổ chức tài chính.

- Mã thông báo xác thực phần cứng: Một thiết bị chuyên dụng chống giả mạo có khả năng lưu trữ khóa mật mã có thể được sử dụng để thực hiện giao thức xác thực lẫn nhau với máy chủ ngân hàng.

- Môi trường xác thực: Có thể an toàn, ví dụ như sử dụng một đầu đọc thẻ đã được chứng nhận hoặc không an toàn.

- Phương tiện truyền dữ liệu xác thực: Giữa thực thể được xác thực và máy chủ cung cấp xác thực và /hoặc cấp quyền truy cập vào các dịch vụ ngân hàng di động.

- Dữ liệu xác thực và độ mạnh của chúng chống lại việc thao túng bởi kẻ tấn công: Quan trọng là phải đánh giá rủi ro liên quan đến việc xâm phạm các khóa mật mã hoặc các thực hành không đúng trong việc xác minh dữ liệu xác thực.

- Cơ sở hạ tầng xác thực: Tích hợp các máy chủ giao diện người dùng (front-end server), máy chủ xác thực và ngân hàng di động cùng với các cơ sở dữ liệu khác nhau.

Quản lý vòng đời của thông tin liên quan đến xác thực.

Thứ tự thực hiện xác thực các thực thể có ảnh hưởng đến mức độ rủi ro mà tổ chức tài chính và khách hàng gặp phải. Nếu giai đoạn đầu tiên của giao dịch là xác thực từ phía tổ chức tài chính, có thể tiếp theo là việc thiết lập một kênh bảo mật giữa khách hàng và tổ chức tài chính đã được xác thực. Trong khi xác thực khách hàng diễn ra tại chỗ, xác thực thiết bị di động của khách hàng có thể thực hiện từ xa qua kênh bảo mật này.

Ngoài các phương pháp xác thực, chính sách bảo mật của một tổ chức tài chính mạnh cũng cần bao gồm các yếu tố khác, như nhận dạng thiết bị di động, giám sát gian lận và sử dụng thông báo đa kênh cho khách hàng.

12.3 Yêu cầu bảo mật

12.3.1 Một quy trình xác thực phải được triển khai

12.3.2 Một quy trình bảo mật cho việc đăng ký khách hàng và việc cấp phát thông tin nhận dạng và xác thực phải được triển khai.

12.3.3 Một quy trình bảo mật để tải xuống thông tin xác thực trên thiết bị di động phải được triển khai.

12.3.4 Một môi trường bảo mật cho việc nhận dạng và xác thực danh tính phải có sẵn trên thiết bị di động.

12.3.5 Một cơ chế kiểm soát quyền truy cập cho việc nhận dạng và xác thực danh tính, bao gồm cả UVM, phải được triển khai.

12.3.6 Một cơ chế truyền tải bảo mật cho các tin nhắn liên quan đến xác thực phải có sẵn.

13 Tiền điện tử

13.1 Tổng quan

Điều này nêu chi tiết yêu cầu đối với tiền điện tử (e-Money) được lưu trữ cục bộ trong một phần tử bảo mật trên thiết bị di động hoặc người tiêu dùng truy cập từ xa trong một tài khoản lưu trữ trên máy chủ.

Yêu cầu bảo mật đối với tiền điện tử thể hiện sự đánh đổi giữa nhu cầu mô phỏng việc chuyển tiền mặt vật lý, bảo vệ người dùng, đồng thời đảm bảo sự an toàn của hệ thống tiền điện tử.

Điều khoản này bao gồm các yêu cầu nhằm cung cấp tiền điện tử với một số tính năng ẩn danh, và các tính năng nhằm giảm gian lận và xây dựng lòng tin vào hệ thống tiền điện tử.

13.2 Yêu cầu về tính ẩn danh

13.2.1 Các giải pháp tiền điện tử tuân thủ tiêu chuẩn này không được tiết lộ bất kỳ thông tin nhận dạng cá nhân (Pll) nào ngoài bút danh. Tính năng này đôi khi được gọi là "ẩn danh yếu". Nói cách khác, tội phạm (không có mẫu tấn công) hoặc người nhận tiền hợp pháp sẽ không thể truy cứu danh tính của người thanh toán từ bất kỳ thuộc tính nào của tiền điện tử đã nhận. Tuy nhiên, tiêu chuẩn này thừa nhận rằng các triển vọng pháp lý có thể yêu cầu khả năng truy vết đầy đủ bởi các cá nhân được ủy quyền.

CHÚ THÍCH: Nếu người thanh toán và người nhận tiền biết nhau, người nhận đã biết danh tính của người thanh toán. Tuy nhiên, họ có thể cố gắng chứng minh cho một người thứ ba rằng giao dịch thanh toán cụ thể này là do người thanh toán tạo ra. Trong trường hợp đó, yêu cầu này ngăn chặn giao dịch tiền điện tử tạo ra dữ liệu liên kết danh tính của người thanh toán với giao dịch cụ thể đó.

13.2.2 Các đơn vị tiền điện tử phải đảm bảo tính không thể liên kết của các giao dịch thanh toán tiền điện tử trừ khi chúng tương ứng với việc tạo ra cá nhân và tải xuống sau đó trên thiết bị di động.

13.3 Yêu cầu bảo mật

13.3.1 Hệ thống tiền điện tử phải được thiết kế sao cho nhà phát hành tiền điện tử, ngay cả khi hợp tác với người dùng ác ý, cũng không thể buộc tội sai (với bằng chứng giả) cho người dùng trung thực về việc chi tiêu gấp đôi một đơn vị tiền điện tử.

13.3.2 Ứng dụng di động quản lý tiền điện tử phải cung cấp cho người dùng phương tiện để kiểm tra xem giao dịch thanh toán tiền điện tử có được thực hiện đúng cách hay không.

13.3.3 Tiền điện tử phải có khả năng phát hiện hành vi chi tiêu hai lần và xác định người chi tiêu hai lần.

13.3.4 Tiền điện tử không được phép làm giả. Không được phép tạo ra các đơn vị tiền điện tử mà không có sự ủy quyền của nhà phát hành tiền điện tử và môi trường bảo mật lưu trữ tiền điện tử.

13.3.5 Giao dịch tiền điện tử phải cung cấp thông tin cho phép người nhận tiền xác định được nhà phát hành tiền điện tử.

13.3.6 Phải có khả năng xác minh tính xác thực của tiền điện tử ngoại tuyến, có nghĩa là tiền điện tử phải được tạo ra một cách hiệu quả bởi nhà phát hành tiền điện tử được yêu cầu.

Thông tin bổ sung về bảo mật tiền điện tử ở trong phần tài liệu tham khảo.

14 Yêu cầu bảo vệ dữ liệu

14.1 Cân nhắc chung và khuôn khổ pháp lý để tuân thủ

MFSP phải đảm bảo quyền kiểm soát hiệu quả dữ liệu cá nhân của khách hàng. Việc thu thập dữ liệu cá nhân (bao gồm thông tin sử dụng internet và địa chỉ IP) phải được thực hiện qua sự đồng ý tự nguyện, thông báo rõ ràng và tích cực (opt-in), và chỉ khi thực sự cần thiết, theo cách thức minh bạch và rõ ràng. Dữ liệu cá nhân bí mật phải được bảo vệ khỏi việc sử dụng trái phép, và trong mọi trường hợp, việc sử dụng dữ liệu này phải được tối thiểu hóa. Những người bị ảnh hưởng bởi bất kỳ vi phạm dữ liệu cá nhân nào phải được thông báo kịp thời về các chi tiết của sự vi phạm và các phương tiện khắc phục sẵn có. Tiêu chuẩn này thừa nhận rằng có thể cần một giải pháp cân bằng khi các yêu cầu vận hành và thậm chí pháp lý có thể xung đột với các mối quan tâm bảo vệ dữ liệu. Do đó, các giao thức truyền thông phải đảm bảo cân bằng giữa kiểm soát truy cập với bảo vệ quyền riêng tư của khách hàng. Trách nhiệm phát sinh từ bất kỳ vi phạm quyền riêng tư nào phải được mở rộng ngoài các hành động do MFSP trực tiếp thực hiện và bao gồm cả các bên xử lý thông tin khác gồm cả các tác nhân được ủy quyền. MFSP phải thiết lập một cơ chế hiệu quả bảo vệ sự an toàn của thông tin khách hàng và chấp nhận trách nhiệm về các vi phạm ngay cả khi có lỗi từ các đại lý được ủy quyền của họ.

Ví dụ, các bản ghi là cần thiết cho việc giải quyết tranh chấp, kiểm toán và các mục đích quản lý quyền riêng tư khác. Trong trường hợp này, các bản ghi chỉ được tạo ra khi có sự đồng ý rõ ràng từ người sử dụng phần tử bảo mật có ký. Chức năng chữ ký số của phần tử bảo mật có ký có thể phục vụ cho mục đích đó. Những bản ghi này phải được bảo vệ chống lại việc truy cập, thay đổi và xóa trái phép. Một phương tiện tốt để hòa giải các yêu cầu này có thể là các bản ghi này được lưu trữ cục bộ trong phần tử bảo mật, nhưng điều này có thể gây ra vấn đề về dung lượng bộ nhớ, hoặc được lưu trữ một cách bảo mật trong cơ sở dữ liệu từ xa, với thiết bị di động cho phép truy cập dưới sự kiểm soát duy nhất của người dùng.

MFSP nên tìm kiếm sự hợp tác với các cơ quan pháp lý chịu trách nhiệm về bảo vệ người tiêu dùng trong lĩnh vực này để giám sát sự phát triển và áp dụng hiệu quả các biện pháp bảo vệ dữ liệu.

Các khuyến nghị nêu trong điều khoản tiếp theo được thiết kế để tương thích với các nỗ lực chuẩn hóa khác và đặc biệt là với ISO/IEC 29100.

Tiêu chuẩn này cung cấp các ví dụ về việc lựa chọn các chức năng phần tử bảo mật có ký để bảo vệ quyền riêng tư.

14.2 Yêu cầu và khuyến nghị về bảo vệ dữ liệu

14.2.1 Yêu cầu

14.2.1.1 Phải cung cấp cơ chế xác thực để chỉ những người yêu cầu được ủy quyền hợp lệ (ví dụ: nhân viên chính phủ) mới có thể truy cập vào dữ liệu cá nhân của người tiêu dùng.

14.2.1.2 Người yêu cầu được ủy quyền hợp lệ phải thu thập thông tin cần thiết mà không tiết lộ nó, dù có chủ đích hay vô tình.

14.2.1.3 Người yêu cầu được ủy quyền hợp lệ phải tiêu hủy hoặc xử lý thông tin khi không còn cần thiết.

14.2.2 Khuyến nghị bảo vệ dữ liệu

14.2.2.1 Không được tiết lộ danh tính của khách hàng và người yêu cầu được ủy quyền hợp lệ.

14.2.2.2 MFSP phải thực hiện các biện pháp để đảm bảo rằng bên thứ ba không thể dễ dàng xác định rằng các giao dịch khác nhau đã được tạo ra từ cùng một thiết bị di động. Hai truy vấn từ cùng một thiết bị di động không nên bị giới hạn về mặt tính toán.

14.2.2.3 Việc giải mã thông tin đã được mã hóa được truyền đi mà bị bên thứ ba thu thập trái phép là không thực tế.

14.3 Đánh giá quyền riêng tư

ISO 22307 xác định một phương pháp giúp các tổ chức trong các lĩnh vực công và tư xác định các vấn đề quyền riêng tư và giảm thiểu các rủi ro liên quan đến việc xử lý dữ liệu tài chính của khách hàng, người tiêu dùng, các đối tác kinh doanh và công dân.

Sự phát triển nhanh chóng trong hiệu suất của các hệ thống máy tính và mạng, cùng với sự giảm chi phí, cho phép các tổ chức tài chính ghi lại, lưu trữ và truy xuất lượng lớn dữ liệu nhanh chóng và hiệu quả hơn bao giờ hết. Công nghệ xử lý dữ liệu, lưu trữ, thu thập và truy xuất dữ liệu tiên tiến hiện nay có sẵn cho tất cả các lĩnh vực kinh doanh và chính phủ.

Đánh giá tác động về quyền riêng tư (PIA) phải được MFSP thực hiện ngay từ khi bắt đầu xây dựng một MFS. PIA cung cấp một cách để đảm bảo hệ thống tuân thủ các luật và quy định hiện hành quản lý quyền riêng tư của khách hàng và người tiêu dùng, đồng thời xác định các lựa chọn và giải pháp bảo mật tối ưu. Khi được sử dụng hiệu quả, PIA có thể xác định các rủi ro liên quan đến quyền riêng tư và giúp các tổ chức lập kế hoạch giảm thiểu những rủi ro đó.

 

Phụ lục A

(Tham khảo)

Hướng dẫn phân tích rủi ro

A.1 Nguyên tắc cho một chương trình bảo mật cho MFS

Việc triển khai một MFS đòi hỏi phải áp dụng một mô hình kinh doanh phù hợp và các công nghệ có thể tương tác giữa một số bên liên quan khác nhau (xem TCVN 14488-1(ISO 12812-1)). Gian lận và việc sử dụng sai MFS có thể làm tổn hại đến tính bền vững của mô hình kinh doanh và có thể làm suy giảm niềm tin của khách hàng.

Tính bảo mật của MFS là kết quả trực tiếp của các tương tác phức tạp và đa dạng giữa tất cả các thực thể tham gia vào các hoạt động liên quan. Mỗi chương trình MFS sẽ có bộ quy trình vận hành và/hoặc các yêu cầu riêng (ví dụ: "quy tắc thành viên") chi phối cách thức các bên sẽ tương tác, cách thức các xử lý giao dịch và cách thức mỗi bên có thể sử dụng nếu giao dịch không thành công hoặc là đối tượng của vi phạm bảo mật, bao gồm các cơ chế xác thực có sẵn hoặc sẽ được sử dụng.

Rủi ro bảo mật là khả năng một mối đe dọa nhất định có thể khai thác các lỗ hổng của MFS. Các MFSP riêng lẻ chịu trách nhiệm xác định, đánh giá và giảm thiểu rủi ro bảo mật. Mục tiêu của chương trình bảo mật là giảm thiểu tác động tiêu cực đến MFS của các rủi ro bảo mật đã xác định. Hơn nữa, để tối ưu hóa các nỗ lực giảm thiểu rủi ro, cần hiểu cấu trúc rủi ro liên quan đến gian lận, sử dụng sai mục đích và vi phạm bảo mật dữ liệu đối với MFS.

Để giảm thiểu rủi ro, cần kết hợp các biện pháp đối phó khác nhau nhằm:

a) Giảm bề mặt tấn công của cơ sở hạ tầng MFS,

b) Giảm thiểu hậu quả của việc kẻ tấn công chặn dữ liệu MFS trong quá trình giao dịch,

c) Bảo vệ ứng dụng MFS và dữ liệu khi nghỉ,

d) Bù đắp cho các sự cố dịch vụ bằng cách sử dụng các thành phần dự phòng.

Các MFSP phải xây dựng, áp dụng và đánh giá chương trình đánh giá rủi ro và chương trình bảo mật. Chương trình này cần bao gồm các mục sau:

- Đánh giá các rủi ro bảo mật liên quan đến MFS, mức độ liên quan của chúng và việc xác định sớm các cơ chế bảo mật để giảm thiểu chúng;

- Xác định các dữ liệu MFS có giá trị đối với kẻ gian lận:

o Thông tin nhận dạng cá nhân (PII) có giá trị thương mại;

o Thông tin xác thực;

o Thông tin hỗ trợ truy cập vào tài khoản ngân hàng;

o Thông tin cho phép truy cập vào tài khoản tiền điện tử;

- Việc xác định các dữ liệu MFS có thể được sử dụng để theo dõi khách hàng;

- Tổn thất tài chính phát sinh từ một cuộc tấn công thành công và tính toán xác suất thành công của cuộc tấn công đó. Sau đó, tiến hành đánh giá xem liệu rủi ro có chấp nhận được hay không, cùng với việc đánh giá mức đầu tư vào bảo mật cần thiết để giảm thiểu rủi ro. Các phương pháp có thể được tìm thấy trong tài liệu tham khảo.

Phân tích tác động về sự bất tiện của khách hàng nếu MFS bị tấn công thành công. Ví dụ, nếu khách hàng buộc phải hủy kích hoạt ứng dụng hoặc không thể truy cập tài khoản của mình cho đến khi sự cố bảo mật được khắc phục;

- Đóng góp riêng lẻ của mỗi MFSP vào chi phí chung để thực hiện chính sách giảm thiểu rủi ro của chương trình MFR.

Việc triển khai một chương trình bảo mật thành công yêu cầu:

- Các MFSP tham gia chương trình phải biết và hoàn thành các nghĩa vụ của mình về chính sách bảo mật theo yêu cầu của các nhà cung cấp tương ứng (ví dụ: đánh giá và chứng nhận bảo mật cho các sản phẩm liên quan đến MFS);

- Các người thực hiện MFSP cần được đào tạo đầy đủ và khách hàng của MFSP cần được giáo dục đúng cách về các thông lệ tốt về phòng ngừa rủi ro;

- MFSP và các nhà thầu phụ của họ phải có đủ phương tiện kỹ thuật và vận hành đề giám sát và nếu cần thiết, thực thi việc hoàn thành các nghĩa vụ bảo mật này (ví dụ: chỉ định một "giám sát viên hệ thống").

A.2 Cấu trúc rủi ro của dịch vụ tài chính di động

Mỗi chương trình MFSP được kỳ vọng sẽ triển khai các quy trình cần thiết để quản lý đúng cách các rủi ro sau đây:

- Rủi ro thanh toán hoặc rủi ro mà một người tham gia trong chương trình MFSP bị mất khả năng thanh toán;

- Rủi ro kinh doanh hoặc rủi ro mà một trong các bên tham gia chương trình MFSP không thể tiếp tục vận hành dịch vụ MFS (ví dụ: mất mát tài chính liên tục);

- Rủi ro vận hành hoặc rủi ro MFS bị gián đoạn vì bất kỳ lý do nào: sự cố lỗi thành phần hoặc mạng do tấn công thành công (ví dụ: tấn công từ chối dịch vụ);

- Tổn thất tài chính vì các lý do khác nhau, bao gồm:

a) Mức độ gian lận bất ngờ,

b) Chi phí điều tra và khắc phục sự cố kỹ thuật,

c) Mất uy tín do khả năng cung cấp MFS kém,

d) Chi phí liên quan đến các vụ kiện từ khách hàng hoặc các khoản tiền phạt do thực hiện không đúng các quy định pháp lý, và

e) Sự biến động của tỷ giá hối đoái.

- Rủi ro pháp lý, hoặc rủi ro phát sinh từ các khung pháp lý không ổn định có thể hạn chế hoặc thay đổi vai trò và trách nhiệm của chương trình MFS (ví dụ: bằng cách áp đặt chuyển giao trách nhiệm). Rủi ro pháp lý cũng phát sinh do sự khó khăn trong việc tuân thủ các yêu cầu pháp lý mới như các quy định về chống rửa tiền hoặc bảo mật dữ liệu.

MFSP dễ bị rủi ro về vận hành, pháp lý và hoạt động do tính phức tạp vốn có của MFS. Tuy nhiên, sự phụ thuộc lẫn nhau chặt chẽ hơn giữa các hệ thống làm thay đổi bản chất rủi ro đối với MFSP và chúng tạo ra những thử thách mới để đạt được hiệu quả quản lý rủi ro tổng thể. Một ví dụ là khi các MFSP chia sẻ cơ sở hạ tầng chung, việc gián đoạn của cơ sở hạ tầng có thể gây mất giao dịch cho tất cả các MFSP và làm tăng khả năng phát sinh các rủi ro khác (kinh doanh, thanh toán). Trong trường hợp đó, các rủi ro vận hành có thể được giảm thiểu bằng cách sử dụng các cơ sở hạ tầng dự phòng, điều này yêu cầu phải đầu tư phân tích chi phí và lợi ích tương ứng.

Thông tin bổ sung về các phương pháp đánh giá và kiểm soát rủi ro có thể được tìm thấy trong phần tài liệu tham khảo.

A.3 Rủi ro về bảo mật, bảo vệ dữ liệu và sử dụng sai mục đích MFS

- Rủi ro bảo mật dữ liệu, bao gồm việc sửa đổi, phá hủy hoặc tiết lộ dữ liệu trái phép sử dụng để hỗ trợ MFS. Những rủi ro này được giảm thiểu bằng cách sử dụng các biện pháp đối phó bảo mật ứng dụng tài chính di động, môi trường bảo mật chống giả mạo và các mô-đun mật mã được chứng nhận.

- Thiết bị di động đưa ra các rủi ro mới về quyền riêng tư. Thiết bị di động bao gồm các tính năng kỹ thuật như GPS và các dịch vụ dựa trên vị trí, công nghệ camera, v.v., có khả năng làm lộ thông tin nhận dạng cá nhân nhạy cảm của người tiêu dùng khi sử dụng mà không có sự đồng ý rõ ràng của khách hàng (ví dụ: opt-in (sự lựa chọn tham gia)) và có thể dẫn đến các nguy cơ gây hại tiềm ẩn và hậu quả không mong muốn. Các ứng dụng tài chính di động được cài đặt trên thiết bị di động thường lấy vị trí, danh sách liên lạc và các thông tin cá nhân khác, làm tăng nhu cầu về các biện pháp bảo vệ bổ sung về cách thức thu thập và sử dụng dữ liệu một cách phù hợp. MFSP chỉ được sử dụng dữ liệu này cho mục đích xử lý và giải quyết giao dịch, chứ không phải bất kỳ mục đích nào khác mà không có sự đồng ý rõ ràng của khách hàng.

MFSP cần nhận thức rằng có những rủi ro đối với chính họ và khách hàng liên quan đến việc thu thập dữ liệu cá nhân quá mức, đặc biệt là nếu dữ liệu này bị đánh cắp hoặc bị mất;

- Rủi ro sử dụng bất hợp pháp, liên quan đến việc sử dụng sai dịch vụ tài chính di động cho các tội phạm tài chính, ví dụ như rửa tiền hoặc tài trợ cho khủng bố. Để giảm thiểu chúng, có ba biện pháp đối phó chính được thực thi hợp pháp:

o Quy tắc Định danh khách hàng (KYC), mà các MFSP phải áp dụng;

o Nghĩa vụ của MFSP trong việc nhận diện đầy đủ người thanh toán và người nhận tiền trong giao dịch chuyển tiền;

o Báo cáo của MFSP cho cơ quan giám sát tài chính về các giao dịch đáng ngờ.

Tham khảo Phụ lục B để biết thêm thông tin.

Theo quan điểm của MFSP, các mối đe dọa chủ yếu phát sinh từ các lỗ hổng của những phần thuộc cơ sở hạ tầng MFS mà họ không kiểm soát trực tiếp, bao gồm thiết bị di động, mạng không dây và mạng internet.

Danh sách sau đây bao gồm một loạt các "thực hành quản lý bảo mật tốt" được khuyến nghị cho MFSP:

a) Áp dụng các biện pháp quản lý rủi ro phù hợp đã được triển khai và mở rộng các biện pháp này nếu có, cho bất kì giao thức truyền thông không dây nào được MFS sử dụng (ví dụ: các kênh không dây, đám mây, NFC) bằng cách:

• Sử dụng mật mã tiêu chuẩn mạnh, và

• Xây dựng chương trình đánh giá và chứng nhận bảo mật hoàn chỉnh, bao gồm các ứng dụng tài chính di động, thiết bị di động, nền tảng, và các thành phần liên quan khác tham gia vào quá trình xử lý giao dịch.

b) Xây dựng một chương trình bảo vệ khách hàng.

c) Cung cấp quản lý ứng dụng để kiểm soát việc cài đặt trước và quản lý vòng đời ứng dụng tài chính di động trên thiết bị di động.

d) Tư vấn và/hoặc cung cấp cho người dùng cuối phần mềm bảo mật thiết bị di động (ví dụ: phần mềm diệt vi-rút trên thiết bị di động được cập nhật thường xuyên).

e) Áp dụng các phương pháp bảo mật để đảm bảo ngăn chặn và phát hiện gian lận tại cấp độ ứng dụng tài chính di động và trong cơ sở hạ tầng văn phòng hỗ trợ (back-office).

f) Cung cấp các phương tiện xác thực khách hàng phù hợp.

g) Tuân thủ các quy định hiện hành liên quan đến phòng chống rửa tiền và phòng ngừa tội phạm tài chính (ví dụ: định danh khách hàng KYC).

h) Giáo dục và thông báo cho người dùng về cách sử dụng hợp lý và các rủi ro của MFS, bao gồm những việc cần làm trong trường hợp thiết bị di động bị mất hoặc bị đánh cắp hoặc khi phát hiện giao dịch đáng ngờ. Tuy nhiên, cần nhận thức rằng các hành động có thể của người tiêu dùng bị hạn chế ở các biện pháp như chọn mã khóa mạnh cho thiết bị di động, giữ bí mật mã di động và báo cáo khi thiết bị bị mất.

i) Phát triển các sản phẩm và ứng dụng tuân thủ TCVN 14488 (ISO 12812) như đã thỏa thuận trong hợp đồng với MFSP.

j) Chỉ sử dụng các thành phần được đánh giá đầy đủ theo chương trình chứng nhận.

k) Đảm bảo rằng các biện pháp kiểm soát bảo mật (ví dụ: một hoặc nhiều phần tử bảo mật) được cung cấp năng lượng chính xác cho các kịch bản tiêu thụ "xấu nhất" (ví dụ: thực hiện nhanh chóng một cơ chế mật mã).

Tiêu chuẩn này giả định rằng bất kỳ MFSP nào cũng có thể là nhà cung cấp các biện pháp kiểm soát bảo mật. Mặc dù tiêu chuẩn này chủ yếu giả định rằng một phần tử bảo mật phải được sử dụng để bảo vệ tài sản thương mại liên quan đến MFS, các thiết bị di động không chứa SE có thể thực hiện một số khoản thanh toán di động. Do đó, không nên đọc tiêu chuẩn này như một yêu cầu tuyệt đối rằng một SE phải được sử dụng để bảo vệ các dịch vụ ngân hàng di động phức tạp hơn, khi xét đến bối cảnh hiện tại của di động.

A.4 Hướng dẫn thiết lập chính sách trách nhiệm

Các khoản phí trái phép, bảo vệ pháp lý, bảo vệ ngành và trách nhiệm thanh toán di động được mô tả trong Tham khảo [14], . Các trích dẫn được đưa ra dưới đây.

Các khoản phí trái phép

Các khoản phí trái phép trong các thanh toán trực tuyến và di động bao gồm:

- Các khoản phí bị trừ từ tài khoản của người tiêu dùng trực tuyến sau khi sử dụng sai thông tin tài chính hoặc thông tin cá nhân khác (chẳng hạn như mật khẩu để truy cập vào tài khoản trực tuyến hoặc số thẻ tín dụng/ghi nợ được xử lý trực tuyến), và

- Các khoản phí bị trừ từ tài khoản trực tuyến mà không có sự đồng ý của người tiêu dùng. Chúng có thể phát sinh từ gian lận, nhưng không phải lúc nào cũng như vậy. Ví dụ, chúng có thể phát sinh từ một khoản thanh toán được xử lý bởi một đứa trẻ mà không có sự biết đến hoặc đồng ý của cha mẹ.

- Các khoản phí trái phép xảy ra khi bên thứ ba sử dụng thông tin tài chính của khách hàng để mua sắm trực tuyến mà không có sự đồng ý và/hoặc sự biết đến của khách hàng. Các bên liên quan chỉ ra rằng loại gian lận này là vấn đề nghiêm trọng đối với thanh toán trực tuyến và thanh toán di động. Trong nhiều trường hợp, gian lận này được thực hiện khi kẻ gian có được thông tin cá nhân mà người tiêu dùng đã tiết lộ trước đó trên mạng, và điều này được gọi là trộm cắp danh tính trực tuyến.

Mặc dù có những nỗ lực để nâng cao bảo mật, hầu hết các hệ thống thanh toán trực tuyến vẫn dễ bị tổn thương với vấn đề các khoản phí trái phép. Các loại lỗ hổng bảo mật khác nhau tùy theo phương tiện thanh toán. Ví dụ, ban đầu thẻ tín dụng và thẻ ghi nợ không được thiết kế cho việc sử dụng trên Internet; những người đánh cắp thông tin thẻ tín dụng có thể sử dụng thông tin đó để mua hàng mà không cần phải sở hữu thẻ thực tế.

Bảo vệ pháp lý

Nỗ lực đáng kể đã được thực hiện bởi các cơ quan quản lý để giải quyết những lo ngại thông qua việc triển khai cơ chế hoàn tiền.

Bảo vệ của ngành

Ngành công nghiệp cũng đã có những bước đi để bảo vệ người tiêu dùng thông qua các cơ chế hoàn tiền.

Trách nhiệm thanh toán di động

Liên quan đến các khoản thanh toán qua điện thoại di động, một số ý kiến đã kêu gọi bảo vệ người tiêu dùng mạnh mẽ hơn trước các khoản phí trái phép. Mặc dù các vụ trộm cắp và các khoản phí trái phép thường xuyên xảy ra, nhưng ở một số quốc gia, người tiêu dùng trong hầu hết các trường hợp phải chịu trách nhiệm về tổn thất tài chính tiềm ẩn. Dưới các khuôn khổ pháp lý của hầu hết các quốc gia, nếu người tiêu dùng thực hiện thanh toán di động bằng thẻ tín dụng hoặc thẻ ghi nợ (thông qua thanh toán di động từ xa), người tiêu dùng có quyền được bảo vệ kèm theo thẻ. Tuy nhiên, nếu dịch vụ thanh toán được cung cấp trực tiếp bởi nhà mạng di động và các khoản phí xuất hiện trên hóa đơn điện thoại di động của người tiêu dùng. Có thể không có sự bảo vệ hợp pháp. Hơn nữa, nếu nhà mạng di động yêu cầu người tiêu dùng đặt cọc trước để thanh toán các khoản phí trong tương lai, các biện pháp bảo vệ cũng có thể không có.

Khuyến nghị của OECD về giới hạn trách nhiệm trong thương mại điện tử

Hướng dẫn về thương mại điện tử của OECD năm 1999 đưa ra khuyến nghị sau:

"Mục V Thanh toán: Người tiêu dùng phải được cung cấp các cơ chế thanh toán dễ sử dụng và bảo mật và thông tin về mức độ bảo mật mà các cơ chế này cung cấp."

Giới hạn trách nhiệm đối với việc sử dụng trái phép hoặc gian lận các hệ thống thanh toán và cơ chế hoàn tiền là những công cụ mạnh mẽ để nâng cao lòng tin của người tiêu dùng và sự phát triển cũng như sử dụng của chúng nên được khuyến khích trong bối cảnh thương mại điện tử.

Các hướng dẫn ban đầu này đã được xác nhận thêm vào năm 2014 bởi hướng dẫn chính sách của OECD về Thanh toán di động và Thanh toán trực tuyến và các hướng dẫn về thương mại điện tử đã sửa đổi được phát hành vào tháng 3 năm 2016.

 

Phụ lục B

(Tham khảo)

Triển khai yêu cầu hệ thống tài chính di động theo yêu cầu “Định danh khách hàng”

Các cơ quan quản lý lo ngại về khả năng sáng tạo của MFS có thể tạo điều kiện cho các tội phạm tài chính.

Các khung pháp lý đã được thiết lập trên toàn thế giới nhằm ngăn chặn việc sử dụng hệ thống tài chính để phục vụ cho các tội phạm tài chính (Luật Phòng chống Rửa tiền và Tài trợ Khủng bố). Chúng cũng thường được gọi là các quy tắc AML/CFT. Trong bối cảnh tiêu chuẩn này, các quy tắc này áp dụng cho các MFSP cần phải:

- Đăng ký khách hàng mới đúng cách,

- Xác định người thanh toán và người nhận thanh toán,

- Báo cáo các giao dịch nghi ngờ cho cơ quan chức năng, và

- Thiết lập các kiểm soát nội bộ để ngăn ngừa hành vi rửa tiền.

Phụ lục này cung cấp thông tin chi tiết về việc giám sát các giao dịch tài chính di động nhằm ngăn ngừa, phát hiện và chặn các thanh toán di động gian lận trước khi chúng được thực hiện.

Một yêu cầu cốt lõi đối với các MFSP là quy trình gọi là "định danh khách hàng" (KYC). Điều này được thể hiện, mặc dù không hoàn toàn, trong yêu cầu nhận diện khách hàng của họ (nghĩa vụ nhận định danh tính), điều này dẫn đến luật pháp đã đưa ra một số quy tắc liên quan đến các tình huống không trực tiếp đối mặt. Trong lĩnh vực dịch vụ tài chính, đây là các tình huống mà khách hàng không có mặt trực tiếp khi tham gia vào mối quan hệ kinh doanh hoặc thực hiện giao dịch. Đối với tiêu chuẩn này, nó tương ứng với cả thanh toán di động và ngân hàng từ xa.

Trên thực tế, việc áp dụng các quy tắc AML/CFT dẫn đến:

a) MFSP triển khai hệ thống Quản lý Nhận dạng có khả năng tiến hành xác thực mạnh mẽ đối với người khởi tạo (và người thụ hưởng trong trường hợp giao dịch thanh toán);

b) Việc triển khai các quy trình cụ thể để giám sát các giao dịch và xác định hành vi bất thường của khách hàng khi sử dụng MFS;

c) Việc từ chối cuối cùng quyền xác nhận giao dịch tài chính di động nếu bị coi là nghi ngờ.

Về vấn đề này, khả năng không tiếp xúc của thiết bị di động và khả năng giao tiếp với một thiết bị không tiếp xúc khác như thẻ không tiếp xúc có thể cung cấp một giải pháp. Thẻ không tiếp xúc lưu trữ thông tin nhận dạng và thông tin xác thực có thể được sử dụng để xác định mạnh mẽ danh tính khách hàng. Thẻ này sẽ sau đó cung cấp dịch vụ KYC cho ứng dụng tài chính di động sử dụng thông tin nhận dạng được cấp bởi các cơ quan chính phủ. Giải pháp này hiện đang được đánh giá bởi một số khu vực pháp lý đã phát hành thẻ căn cước công dân có giao diện không tiếp xúc.

 

Phụ lục C

(Tham khảo)

Cơ chế mã hóa cho dịch vụ tài chính di động

C.1 Khuyến nghị chung

Các tiểu ban kỹ thuật của ISO/JTC 1/SC 27 và ISO/TC 68/SC 2 hợp tác để xác định và chọn lựa các cơ chế mật mã:

- dạng nguyên thủy (ví dụ: thuật toán, mã hóa đối xứng và bất đối xứng, độ dài khóa);

- các chương trình (ví dụ: chế độ mã hóa, xác thực);

- các giao thức (ví dụ: xác thực, chữ ký điện tử);

về cơ bản là phù hợp để sử dụng cho MFS.

Đối với MFS, các cơ chế mật mã sau đây nên được áp dụng:

- Theo khuyến nghị chung, nên tuân theo ISO/TR 14742, được duy trì bởi tiểu ban kỹ thuật ISO/TC 68/SC 2;

- ISO 9564-2 chỉ rõ các thuật toán mã hóa có thể được sử dụng để mã hóa PIN. Chúng có thể áp dụng để mã hóa UVM (ví dụ: mã di động);

- Chỉ nên sử dụng các lược đồ mật mã có thể được chứng minh được theo nghĩa toán học nghiêm ngặt.

C.2 Triển khai các giải pháp mật mã cho dịch vụ tài chính di động

- Các nhà thiết kế giải pháp mật mã cho MFS phải đưa ra các lựa chọn về các thuật toán mật mã và độ dài khóa sẽ sử dụng, đồng thời cân nhắc giữa các yếu tố bảo mật và chi phí.

- Độ mạnh của một khóa liên quan đến "độ bảo mật theo bít" của khóa. Độ mạnh khóa "k" có nghĩa là độ phức tạp của cuộc tấn công được biết đến nhiều nhất để khôi phục lại khóa là 2 ^k . Hệ số "k" cho các độ dài khóa khác nhau được ghi chú trong Bảng C.1.

- Các Cơ quan An ninh Quốc gia thường xuyên công bố các khuyến nghị về việc triển khai (ví dụ: độ dài khóa) các thuật toán mật mã. Trong tài liệu tham khảo, có một số tài liệu tham khảo hữu ích dành cho những người triển khai giải pháp mật mã cho MFS. Những tài liệu tham khảo này không đầy đủ, nhưng cung cấp cái nhìn tổng quan tốt về các thực hành tốt nhất.

- Những khuyến nghị này, có thể mang tính ràng buộc về mặt pháp lý, thường đặt ra các thời hạn cho việc chuyển đổi sang các giải pháp an toàn hơn (ví dụ: độ dài khóa mở rộng), tạo điều kiện thuận lợi cho việc lập kế hoạch đổi mới hệ thống. Tuy nhiên, những khuyến nghị này không phải lúc nào cũng nhất quán và vì vậy, những người triển khai cần tham khảo trực tiếp các phiên bản áp dụng.

- Đối với bất kỳ tài liệu kỹ thuật nào, một số điều khoản của các tiêu chuẩn đã công bố hiện tại có thể không còn phù hợp (ví dụ: các điểm yếu/tấn công đã được báo cáo sau khi công bố tiêu chuẩn). Vì vậy, cần phải thường xuyên tham khảo tiêu chuẩn của tiểu ban kỹ thuật ISO/JTC 1/SC 27 Standing Document 12 (SD12) "Đánh giá các thuật toán mật mã và độ dài khóa". Tiêu chuẩn này cung cấp sự trợ giúp để đưa ra các lựa chọn dựa trên thông tin cập nhật về mức độ bảo mật của các thuật toán mật mã đã được chứng minh bằng cách sử dụng các độ dài khóa khác nhau.

- Khi cần thiết, Phụ lục này cung cấp các ví dụ (ví dụ: độ dài khóa được khuyến nghị cho một số thuật toán mã hóa).

C.3 Thuật toán mã hóa và khóa cho dịch vụ tài chính di động

Mật mã đối xứng tiêu chuẩn

Mật mã đối xứng cấu thành nên cơ chế cơ bản cho tính bảo mật các giao dịch tài chính di động. Mật mã đối xứng được chia thành mật mã khối và mật mã dòng. Mật mã khối được sử dụng nhiều hơn trong các ứng dụng tài chính. Khuyến nghị sử dụng mật mã khối theo ISO/IEC 18033-3 có trong ISO/TR 14742. Tuy nhiên, thực tế là mật mã dòng có xu hướng nhỏ hơn và nhanh hơn, nên chúng có thể phù hợp với các ứng dụng có ít tài nguyên tính toán, như một số thiết bị di động. Nếu được sử dụng, chúng phải tuân thủ ISO/IEC 18033-4.

Thường thì, kích thước khóa được khuyến nghị là một giới hạn dưới, được xác định bằng cách giả định rằng cuộc tấn công tốt nhất chống lại mật mã đối xứng là tìm kiếm khóa theo kiểu xả. Một khi có cuộc tấn công tốt hơn tìm kiếm khóa theo kiểu xả được biết đến, độ dài khóa danh nghĩa không còn là thước đo về mức độ bảo mật của nó nữa và thay vào đó, kích thước khóa hiệu quả sẽ được sử dụng.

Mật mã Khối Tiêu chuẩn

Mật mã khối khoá đối xứng mã hóa toàn bộ khối văn bản thuần túy cùng một lúc bằng cùng một khóa.

- 3-DES được sử dụng rộng rãi cho các giao dịch thanh toán thẻ trực tuyến. Tuy nhiên, AES được kì vọng sẽ trở thành thuật toán mã hóa thống trị trong thế hệ tiếp theo.

- AES là một khối mã hoá hiện đại, hỗ trợ ba độ dài khóa là 128, 192 và 256 bit, cung cấp khả năng bảo mật lâu dài xuất sắc chống lại các cuộc tấn công brute-force. Hiện tại không có cuộc tấn công nào được biết đến vào toàn bộ AES-128, với bất kỳ triển khai thực tế nào về bảo mật AES. Tuy nhiên, vào năm 2011, một cuộc tấn công lý thuyết vào AES đã được công bố (tham khảo tài liệu).

Lưu ý rằng ISO/TR 14742 đối với mã hóa khối mã hoá khuyến nghị ít nhất 96 bit bảo mật. Giá trị này không được chứng minh rõ ràng và các lựa chọn khác có thể là ưu tiên hơn. Ví dụ, ANSSI của Pháp khuyến nghị ít nhất 100 bit bảo mật trước năm 2020, và 128 bit sau năm 2020.

Tạo số ngẫu nhiên chuẩn (RNG)

Mật mã tốt đòi hỏi phải có Hệ số ngẫu nhiên (RNG) tốt.

a) Hầu hết các giao thức mật mã đều yêu cầu việc tạo và sử dụng các giá trị bí mật mà kẻ tấn công không biết.

b) Bộ tạo Số Ngẫu Nhiên là thành phần ban đầu cần thiết để tạo ra các cặp khóa công khai/riêng tư cho các thuật toán bất đối xứng (khoá công khai).

c) Các khóa cho các hệ thống mật mã đối xứng cũng được tạo ngẫu nhiên. RNG cũng được sử dụng để tạo ra các thử thách, nonces (muối).

d) Việc tạo ra các thuật toán chữ ký số yêu cầu phải có số ngẫu nhiên chất lượng cao (ví dụ: cho chữ ký EC-DSA, xem dưới đây).

Vì các giao thức bảo mật phụ thuộc vào sự không thể đoán trước của các khóa mà chúng sử dụng, cần phải rất thận trọng trong việc phát triển, thử nghiệm và lựa chọn RNG.

ISO/IEC 18031 cung cấp hướng dẫn về cơ chế tạo số ngẫu nhiên chất lượng cao. Thuật ngữ "chất lượng cao" đề cập đến cả độ tin cậy và khả năng tạo ra các số với mức độ entropy cao. Các thử nghiệm thống kê để kiểm tra tính ngẫu nhiên đã được công bố bởi NIST/SP 800-22.

ISO/IEC 18032 hoàn thiện ISO/IEC 18031 và chỉ ra cách tạo số nguyên tố khi có đủ số ngẫu nhiên phù hợp.

Mật mã khóa công khai: Hệ thống mật mã dựa trên RSA

RSA là hệ thống mật mã khóa công khai được sử dụng rộng rãi nhất và sẽ ngày càng tồn tại song song với các triển khai dựa trên ECC.

Ngay cả khi hiện tại không thể phân tích được các số 1024-bit, việc sử dụng RSA với mô đun 2048-bit được khuyến cáo mạnh mẽ khi cần bảo mật lâu dài.

CHÚ THÍCH: hàng năm EMVCo công bố một đánh giá về thời gian hiệu lực của các khóa RSA cho thẻ và thiết bị đầu cuối EMV.

Mật mã khóa công khai: Triển khai Đường cong Elliptic (ECC)

Đường cong elliptic có thể được sử dụng cho chữ ký số, giao thức trao đổi khóa và mã hóa dữ liệu. ECO cung cấp cùng mức độ bảo mật như RSA hoặc hệ thống logarit rời rạc với các toán tử ngắn hơn nhiều và do đó các văn bản mã hóa và chữ ký cũng ngắn hơn. Mức độ bảo mật ECC tương ứng với AES-128 sẽ yêu cầu RSA-3072 và EC-DSA-256. Hơn nữa, NSA gần đây đã công bố các thuật toán Suite B và chỉ khuyến nghị các thuật toán dựa trên đường cong elliptic, loại trừ RSA. Lợi thế của việc sử dụng cho thanh toán di động là giảm thời gian giao dịch. Bảng C.1 cung cấp sự so sánh về độ dài khóa cần thiết cho mức độ bảo mật nhất định (cột đầu tiên từ mức độ 80-bit đến 256-bit) của các thuật toán khóa đối xứng, hệ thống mật mã RSA và ECC.

CHÚ THÍCH: Bảng C.1 chỉ phục vụ cho mục đích so sánh và không khuyến nghị mức độ bảo mật cụ thể. Lưu ý rằng ISO/TR 14742 cho mã hóa khối khuyến nghị ít nhất 96 bít bảo mật.

Bảng C.1 - So sánh giữa các mức độ bảo mật khác nhau

Cho đến nay, các triển khai ECC chưa được sử dụng rộng rãi bởi ngành công nghiệp thanh toán. Tuy nhiên, các hệ thống thanh toán quốc tế đã và đang triển khai công việc để chỉ định hệ thống mật mã ECC.

Chữ ký số Tiêu chuẩn

Chữ ký số sẽ cung cấp một tin nhắn tài chính di động đã ký với các thuộc tính bảo mật về tính toàn vẹn của tin nhắn, xác thực tin nhắn và không thể phủ nhận.

Chữ ký số RSA Tiêu chuẩn

ISO/IEC 9796-2 bao gồm các chữ ký dựa trên RSA cung cấp khả năng khôi phục tin nhắn. Phiên bản sửa đổi gần đây của tiêu chuẩn này bao gồm một cơ chế mới để tránh các cuộc tấn công đã được công bố trên thẻ thanh toán.

Mô-đun của các lược đồ chữ ký số RSA nên có độ dài ít nhất là 1024 bit. Để bảo mật lâu dài, nên sử dụng mô-đun có độ dài k = 3072 bít

Thuật toán Chữ ký số chuẩn (DSA)

Đây là một tiêu chuẩn của chính phủ Hoa Kỳ cho chữ ký số do NIST đề xuất. Nó là một biến thể của thuật toán chữ ký Elgamal. Lợi thế chính của nó so với thuật toán chữ ký Elgamal là chữ ký dài chỉ 320 bit và có khả năng chống lại một số cuộc tấn công đã được đề xuất cho chữ ký Elgamal.

Biến thể DSA 1024 bit hiện tại là an toàn. Các biến thể 2048 bit và 3072 bít cung cấp bảo mật lâu dài tốt.

Hệ mật dựa trên đường cong Elliptic chuẩn (ECDSA)

Thuật toán sinh chữ kí số dựa trên đường cong elliptic là ECDSA. Có các triển khai quốc gia được chuẩn hóa trong ISO/IEC 14888-3. Khi so sánh hiệu suất giữa RSA và ECDSA, cần thiết lập sự khác biệt giữa việc tạo chữ ký số và xác minh chữ ký số.

Chữ ký ECDSA luôn nhanh hơn RSA bất kể thành phần và mức độ bảo mật nào được nhắm đến. Hơn nữa, hiệu quả của ECC trong chế độ chữ ký tăng theo mức độ bảo mật. Đối với ECDSA, có thể chọn độ dài bít trong phạm vi từ 160 bít -256 bít, cung cấp bảo mật tương đương với RSA 1024 bit -3072 bit.

Mặt khác, thời gian thực hiện việc xác minh bằng ECC lâu hơn so với thời gian xác minh bằng RSA. Xác minh bằng ECC yêu cầu cùng phương tiện mật mã và cùng loại thời gian thực thi như đối với chữ ký ECC, điều này không thể thực hiện với RSA. Đối với RSA trong trường hợp có số mũ công khai nhỏ (trường hợp ở đây), việc xác minh rất nhanh (vì nó đơn giản hơn về mặt tính toán mật mã).

Hàm băm tiêu chuẩn

Hàm băm phải có độ dài ít nhất 160 bit để chống lại các cuộc tấn công va chạm. Hàm băm cung cấp đầu ra dài 256-bit được khuyến nghị mạnh mẽ cho bảo mật lâu dài.

Cuộc thi NIST SHA-3 đang diễn có thể sẽ đưa đến các hàm băm chuẩn hóa mới vào thời điểm tiêu chuẩn này được công bố.

Mã xác thực thông báo chuẩn (MAC)

MAC cung cấp hai dịch vụ bảo mật, đó là tính toàn vẹn của tin nhắn tài chính di động và xác thực tin nhắn. Người gửi và người nhận (người xác minh) của tin nhắn chia sẻ một khóa bí mật (gồm K bit). Bước đầu tiên của quy trình MAC là tạo ra khóa phiên.

Dựa trên mã khối và hàm băm.

Mã khối MAC, sử dụng một mã khối trong chế độ CBC (Cipher Chaining Mode) đã được chuẩn hóa tại Hoa Kỳ và được sử dụng rộng rãi để đảm bảo tính toàn vẹn của các giao dịch tài chính. NIST Special Publication 800-38D đã chỉ ra một thuật toán MAC dựa trên mã khối khóa đối xứng, được gọi là CMAC.

CBC-MACs chứa CMAC sử dụng thuật toán mã khối (ALG) 128 bít (16 byte) như AES ở chế độ CBC có sẵn trong ISO/IEC 9797-1.

MAC dựa trên hàm băm được sử dụng với SHA-1; dự kiến sẽ chuyển sang các hàm băm hiện đại như SHA-2 và SHA-3.

Tiêu chuẩn MAC bao gồm MAC dựa trên hàm băm phổ quát (UMAC) có trong ISO/IEC 9797-3.

Các giao thức thiết lập khóa tiêu chuẩn

Tất cả các dịch vụ bảo mật trên đều giả định rằng các khóa mật mã đã được tạo ra và phân phối giữa các bên tham gia vào một giao dịch tài chính di động. Theo quan điểm bảo mật, việc phân phối khóa an toàn là một trong những vấn đề nhạy cảm nhất. Thông thường, một bên tạo và phân phối khóa bí mật cho bên còn lại, sử dụng giao thức Chuyển khóa (Key Transport).

Trong bước thứ hai, một giao thức Thỏa thuận Khóa được thực hiện để tạo ra một khóa phiên được lấy từ khóa gốc. Các cơ chế tiêu chuẩn để phân phối khóa có thể sử dụng:

- Hệ thống mật mã đối xứng (ISO/IEC 11770-2), hoặc

- Hệ thống mật mã bất đối xứng (ISO/IEC 11770-3).

Cơ chế mã hóa tiêu chuẩn cho các giao dịch rất ngắn thời gian

Các thiết bị di động thế hệ trước có tài nguyên tính toán đáng kể. Tuy nhiên, nhiều ứng dụng tài chính di động không hoạt động tốt do thiếu tài nguyên cho tính toán, lưu trữ dữ liệu, băng thông mạng và dung lượng pin. MFS liên quan đến việc thực thi các ứng dụng, yêu cầu thực hiện các giao thức mã hóa phức tạp.

Giải pháp kiến trúc đơn giản nhất cho các vấn đề này là chọn mật mã dựa trên một thuật toán chuẩn, được công khai giám sát với độ dài khóa thích hợp. Ví dụ, ISO/IEC 18033 cung cấp các thuật toán mã hóa mạnh dựa trên cả kỹ thuật đối xứng và bất đối xứng với nhiều mức độ bảo mật khác nhau. Các cơ chế mật mã ISO này và các cơ chế khác đã được chứng minh và mạnh mẽ cho xác thực, hàm băm, MAC, chữ ký điện tử và quản lý khóa có sẵn trong ISO/TR 14742.

Ngoài ra, ISO/IEC 29192 (tất cả các phần) mô tả các cơ chế mật mã, được thiết kế để cân bằng tốt giữa bộ ba bảo mật-thời gian thực hiện-độ phức tạp, khiến chúng trở thành lựa chọn bổ sung khả thi cho thanh toán di động/ngân hàng trong một số ứng dụng.

Ví dụ, ISO/IEC 29192-4 cung cấp một cơ chế xác thực phần tử bảo mật nhanh chóng và trao đổi khóa tiếp theo được điều chỉnh cho các giao dịch không tiếp xúc rất nhanh. Tùy thuộc vào độ dài của khóa được trao đổi, giao thức nhẹ có thể được sử dụng để thực hiện mã hóa (ví dụ: theo ISO/IEC 18033-3).

 

Phụ lục D

(Tham khảo)

Các lỗ hổng và cuộc tấn công vào dịch vụ tài chính di động

D.1 Các yếu tố chung đối với dịch vụ tài chính di động

Khách hàng không thể tránh khỏi việc tải các tệp ở nhiều định dạng, tạo ra cửa ngõ cho các lỗ hổng, đặc biệt là nếu khách hàng không cài đặt phần mềm diệt virus/phần mềm chống phần mềm độc hại. Các thiết bị di động chứa các thành phần (ví dụ: bộ xử lý trung tâm và hệ điều hành, giao diện truyền thông với thế giới bên ngoài, hệ thống khởi động thiết bị di động, các thành phần bảo mật) là mục tiêu tiềm năng của các cuộc tấn công.

a) Phần mềm độc hại là nguồn gốc của nhiều mối đe dọa bảo mật

Thường thì phần mềm độc hại di động được thiết kế để thu thập và sử dụng sau dữ liệu tài chính và cá nhân của khách hàng.

- Phần mềm độc hại được cài đặt trong thiết bị di động có thể chiếm đoạt mã UVM (ví dụ: mã di động) do khách hàng hợp pháp nhập vào để cấp quyền truy cập vào ứng dụng thanh toán. Sau đó, ứng dụng thanh toán có thể truyền dữ liệu thật đến một thiết bị di động khác đang được sử dụng trong giao dịch không tiếp xúc gần.

- Việc cài đặt phần mềm độc hại vào thiết bị di động cũng có thể dẫn đến một loạt các cuộc tấn công vào dữ liệu giao dịch, như sẽ được mô tả dưới đây.

Phần mềm độc hại cũng có thể được sử dụng trong một cuộc tấn công từ chối dịch vụ đề ngăn cản khách hàng hợp pháp thực hiện thanh toán.

b) Nghe lén

Nghe lén là một cuộc tấn công thụ động đặc biệt yêu cầu một kẻ tấn công thụ động với một anten để can thiệp vào các kênh truyền thông đã được thiết lập qua mạng không dây bởi thiết bị di động và ghi lại thông tin chi tiết về giao dịch mà không làm nhiễu tin nhắn hoặc kênh. Đối với các khoản thanh toán di động gần, giao diện NFC triển khai giao tiếp hai chiều qua mạng không dây và các giao dịch có thể bị nghe lén bởi một công cụ gián điệp, vấn đề chính là kẻ tấn công cần phải ở gần thiết bị để ghi lại tín hiệu có thể khai thác. Các kết quả đã công bố còn gây tranh cãi. Lý do có thể là các điều kiện môi trường ảnh hưởng đến khoảng cách đọc. Mặt khác, các kết quả trong phòng thí nghiệm không nhất thiết phải tái tạo được trong điều kiện thực tế.

Thiết lập một kênh bảo mật giữa thiết bị di động và thiết bị đầu cuối hoặc đến cổng MFS từ xa là biện pháp phòng ngừa rõ ràng để bảo vệ chống lại việc nghe lén và bất kỳ loại tấn công sửa đổi dữ liệu nào.

Kênh bảo mật này, sử dụng giao thức trao đổi khóa, có thể được thực hiện có hoặc không thực hiện xác thực lẫn nhau trước đó:

- không có xác thực;

- với xác thực phần tử bảo mật/ứng dụng tài chính di động;

- với xác thực lẫn nhau.

c) Tấn công phủ đầu

Tấn công phủ đầu (skimming) là cuộc tấn công chủ động để bắt đầu một giao dịch bằng thiết bị di động mà không biết chủ sở hữu hợp pháp. Nó yêu cầu kích hoạt từ xa giao diện NFC của thiết bị di động hoặc một kênh truyền dữ liệu khác của thiết bị di động mà không có sự đồng ý của chủ sở hữu. Tấn công phủ đầu được coi là một mối đe dọa đáng kể đối với người trả tiền và từ góc độ kinh doanh, nó đại diện cho một mối quan ngại bảo mật chính đối với các sản phẩm thanh toán di động không tiếp xúc.

Một biện pháp đối phó khả thi là tích hợp tính năng chống tấn công phủ đầu vào thiết bị di động. Mối quan tâm thứ hai liên quan đến việc bảo vệ bất kỳ dữ liệu bí mật nào có thể được đảm bảo bằng cách tạo ra một kênh bảo mật với một khóa phiên mã hóa đã được thương lượng có đủ ngẫu nhiên

Một số giao thức mã hóa không triển khai tính năng chống tấn công phủ đầu, điều này dẫn đến việc thiết bị di động tiết lộ không kiểm soát khi bắt đầu bất kỳ giao dịch nào, dù là hợp pháp hay không. Ngoài các rủi ro gian lận, còn có mối quan ngại về quyền riêng tư, do vấn đề phát sinh đối với việc truyền chứng chỉ được lưu trữ trong phần tử bảo mật khi bắt đầu thực hiện giao thức. Do đó, về mặt lý thuyết, khả năng truy xuất nguồn gốc của người dùng là có thể. về mặt quyền riêng tư, các giao thức thiết kế cần phải bao gồm một giai đoạn đầu tiên để chứng chỉ này được truyền đi dưới dạng mã hóa.

d) Tấn công tiếp sức

Trong một cuộc tấn công tiếp sức, một thiết bị di động NFC giả được sử dụng để thanh toán cho một điểm giao dịch không tiếp xúc hợp pháp POI (ví dụ: PCD theo ISO/IEC 14443) bằng cách sử dụng dữ liệu cấp ứng dụng do một ứng dụng thanh toán di động hợp pháp tạo ra (ví dụ: lưu trú trong thẻ không tiếp xúc hoặc trong một phần tử bảo mật) đã bị đánh cắp bằng cách sử dụng một đầu đọc giả (ví dụ: một NFC thứ hai, xem chú thích). Thực tế, giao dịch không tiếp xúc diễn ra giữa hai ứng dụng hợp pháp không tiếp xúc, không nhận thức được cuộc tấn công.

Với các cuộc tấn công tiếp sức từ xa, phần mềm độc hại được cài đặt trong hệ điều hành giàu tính năng của thiết bị di động của nạn nhân có thể thực hiện thanh toán trái phép bằng cách chuyển hướng các thông tin liên lạc NFC hợp pháp tới một kẻ tấn công từ xa, cho mua hàng mà không cần phải sở hữu thiết bị di động của nạn nhân.

Các cuộc tấn công tiếp sức không dễ bị ngăn chặn vì kẻ tấn công không cần phải truy cập vào dữ liệu rõ ràng.

Có thể chặn giao dịch bằng một cuộc tấn công chủ động chỉ bằng cách phát ra các tín hiệu vô tuyến nhiễu có tần số sóng mang 13,56 MHz, làm bão hòa tầng thu của các thiết bị liên lạc.

e) Từ chối dịch vụ/sửa đổi dữ liệu

Thiết bị di động trở nên không phản hồi vì kênh giao tiếp bị mờ hoặc sửa đổi. Cuộc tấn công này có thể xảy ra vì các tín hiệu được trao đổi rất yếu. Mặc dù cuộc tấn công này không mang lại bất kì lợi ích kinh tế cho kẻ tấn công, cũng như không gây ra tổn thất tài chính cho nạn nhân, nhưng nó có thể làm tổn hại danh tiếng của MFSP.

f) Tấn công xen giữa

Các cuộc tấn công xen giữa không được coi là có nguy cơ đáng kể trong bối cảnh NFC, trong điều kiện hiện tại với điều kiện là hai bên giao tiếp là hợp pháp. Lý do là một cuộc tấn công xen giữa liên quan đến việc nghe lén tín hiệu gửi từ A đến B, sau đó tránh (ví dụ: làm mờ bộ thu B) để B nhận dữ liệu bị nghe lén và cuối cùng gửi lại cho B một tin nhắn do kẻ tấn công tạo ra như thể từ A, khi A vẫn đang gửi tin nhắn ban đầu đến B). Kịch bản này được coi là không khả thi về mặt thực tế khi sử dụng tín hiệu RF. Với các cuộc tấn công xen giữa từ xa, kẻ gian sẽ sử dụng các kỹ thuật khác, như phishing và pharming, để chuyển hướng khách hàng đến một trang web độc hại.

CHÚ THÍCH: Các cuộc tấn công này cũng có thể xảy ra trong quá trình giao dịch giữa thẻ không tiếp xúc và đầu đọc không tiếp xúc. Tuy nhiên, khả năng tính toán của thiết bị di động và khả năng mô phỏng cả đầu đọc không tiếp xúc và thẻ không tiếp xúc và làm tăng nguy cơ sử dụng sai thiết bị di động NFC cho các mục đích tấn công chủ động.

D.2 Các lỗ hổng và cuộc tấn công cụ thể đối với MFS từ xa

Thiết bị di động kết nối với một cổng MFS từ xa thông qua một mạng không dây.

Hình D.1 chỉ ra các thành phần chính của kiến trúc bảo mật tiêu chuẩn cho hoạt động của MFS từ xa. Mục tiêu là thiết lập một kênh giao tiếp bảo mật giữa ứng dụng lưu trú trong thiết bị di động và máy chủ của Tổ chức.

Hình D.1 - Kiến trúc điển hình cho việc cung cấp MFS từ xa

Để thực hiện thanh toán từ xa, thiết bị di động của người trả tiền được kết nối trực tiếp với cơ sở hạ tầng không dây, trong đó các điều khoản bảo mật chưa được thiết kế để hỗ trợ thanh toán. Lúc này, người trả tiền hoạt động độc quyền như một khách hàng được xác thực bởi nhà điều hành mạng.

Ví dụ, người trả tiền có thể chọn một ứng dụng thanh toán di động từ xa được lưu trữ trong môi trường an toàn của thiết bị di động. Nếu người trả tiền được xác thực thành công, họ sẽ được phép chọn một ứng dụng di động để khởi tạo yêu cầu kết nối với cổng dịch vụ thanh toán di động từ xa, sau đó sẽ tiến hành quy trình xác thực khách hàng cho ứng dụng thanh toán đã chọn.

So với các giao dịch thanh toán không tiếp xúc gần, thanh toán di động từ xa đặt ra những vấn đề rủi ro khác. Trong khi các mối quan tâm chính đối với thanh toán NFC là skimming và nghe lén, thì mối đe dọa chính đối với thanh toán di động từ xa là nhu cầu triển khai xác thực người dùng mạnh, tính bảo mật và tính toàn vẹn của các tin nhắn đã trao đổi và cần tạo ra một bằng chứng đồng ý mạnh mẽ.

Kênh bảo mật từ ứng dụng tài chính di động đến MFSP dài hơn và nằm ngoài tầm kiểm soát của MFSP. Thứ hai, không thể xác thực vật lý người trả tiền và cần có quy trình xác thực trực tuyến mạnh để xác minh danh tính đã yêu cầu và cấp quyền dịch vụ. Điều này có nghĩa là thông tin xác thực sẽ được truyền qua các mạng không bảo mật.

Ngoài ra, cho đến nay, nhiều triển khai tại hiện trường đều dựa trên phần mềm và sử dụng GSM chung hoặc các dịch vụ nhắn tin ngắn tiêu chuẩn khác. Những kẻ gian lận đã tiếp tục phát triển và triển khai các phương pháp tinh vi, hiệu quả và độc hại hơn để xâm phạm các cơ chế xác thực và truy cập trái phép vào tài khoản trực tuyến của khách hàng. Trong bối cảnh này, ít nhất hai trường hợp sử dụng khác nhau cần được phân tích:

a) Người trả tiền kết nối với MFSP của mình trực tiếp hoặc qua trung gian thanh toán của bên thứ ba;

B) Người trả tiền được kết nối với MFSP trong một giao dịch thương mại di động. Trong trường hợp này, người nhận tiền là một nhà bán lẻ trực tuyến.

D.3 Các lỗ hổng và tấn công vào ngân hàng di động

Thông thường, hoạt động ngân hàng di động liên quan đến việc trao đổi dữ liệu giữa các "thực thể" có sự tồn tại riêng biệt và khác biệt có thể được xác định duy nhất. Chủ tài khoản ngân hàng, tổ chức tài chính, nhà điều hành hệ thống trực tuyến, các bên đáng tin cậy và thậm chí là cơ quan chính phủ là các ví dụ về các thực thể này.

Các dịch vụ ngân hàng di động khác nhau và các giao dịch liên quan đại diện cho các rủi ro khác nhau đối với các tổ chức tài chính và khách hàng. Những rủi ro này cần được giải quyết khác nhau theo các điều khoản của chính sách bảo mật toàn cầu. Việc ủy quyền cho một hoạt động ngân hàng từ xa yêu cầu xác thực trước của người dùng. Do đó, xác thực người dùng và ngân hàng là các quy trình bảo mật quan trọng cho dịch vụ ngân hàng di động.

Giao dịch ngân hàng di động có ý định kết nối khách hàng với máy chủ ngân hàng, sau một số quy trình xác thực. Nếu quy trình không yêu cầu chủ thẻ xác thực máy chủ ngân hàng, các lỗ hổng sau sẽ xảy ra:

a) Người dùng có thể không được kết nối với một máy chủ web chính hãng - do đó, có thể bị chuyển hướng sai.

b) Một máy chủ web chính hãng (nhưng gian lận) có thể chuyển hướng sai trình duyệt của người dùng.

c) Chuyển hướng sai có thể có nghĩa là người dùng sẽ tiết lộ dữ liệu xác thực.

Các tổ chức tài chính triển khai hệ thống xác thực mạnh và hệ thống quản lý gian lận cho ngân hàng trực tuyến sẽ xem xét tác động đến khả năng sử dụng. Tỷ lệ từ chối sai quá cao khi xác thực có thể gây ra sự gia tăng đột biến các cuộc gọi dịch vụ khách hàng và khiến khách hàng khó chịu.

 

Thư mục tài liệu tham khảo

[1] Bank for International Settlements (2003), Risk Management Principles for Electronic Banking

[2] European Payments Service Directive (2007/64/EC)

[3] ENISA: Smartphones: Information Security risks, opportunities and recommendations for users. December 2010

[4] European Central Bank: Electronic Money System Security Objectives May 2003

[5] The World Bank - Committee in Payment and Settlement Systems. General principles for international remittance services. January 2007

[6] Global Platform-TEE Secure Element API Specification v1.0

[7] Global Platform-TEE System Architecture v1.0

[8] Payment Card Industry (PCI) Payment Application Data Security Standard Requirements and Security Assessment Procedures Version 2.0 October 2010

[9] ISO/TR 14742, Financial services - Recommendations on cryptographic algorithms and their use

[10] NIST. Draft NIST SP 800-78-4 Cryptographic Algorithms and Key Sizes for Personal Identity Verification available at http://csrc.nist.qov/publications/drafts/800-78-4/sp800 78-4 draft.pdf

[11] ENISA. Algorithms, Key Sizes and Parameters Report- 2013 recommendations v1.0 October 2013 available at http://www.enisa.europa.eu/

[12] EUROPEAN PAYMENTS COUNCIL. EPC342-08 Guidelines on algorithms usage and key management v3.0 available at http://www.europeanpaymentscouncil.eu/

[13] ISO/IEC JTC1 SC27 Standing Document 12 - Assessment of cryptographic algorithms and key lengths available http://www.jtc1sc27.din.de/sbe/SD12

[14] OECD Digital Economy paper no 204. Report on consumer protection in online & mobile payments. 2012

[15] Consumer Policy guidance on mobile & online payments. OECD February 2014

[16] Recommendation of the OECD Council concerning guidelines for consumer protection in the context of electronic commerce. OECD 1999

[17] W3C Recommendation (2008): “XML Signature Syntax and Processing”

[18] ETSI EN 319 102 Electronic Signatures and Infrastructures (ESI) - Procedures for Signature Creation and Validation

[19] FFIEC IT Examination Handbook

[20] BOGDANOV Andrey, KHOHRATOVICH Dmitry, RECHBERGER Christian (2011) “Biclique Cryptanalysis of the Full AES”

[21] Global Platform-Card Composition Model v1.1 (2012)

[22] OECD Consumer protection in e-commerce: OECD recommendation. Paris 2016

[23] ISO 15782, Certificate management for financial services

[24] ISO 16609, Financial services - Requirements for message authentication using symmetric techniques

[25] ISO 21188, Public key infrastructure for financial services - Practices and policy framework

[26] ISO/IEC 9796-2, Information technology - Security techniques - Digital signature schemes giving message recovery - Part 2: Integer factorization based mechanisms

[27] ISO/IEC 9796-3, Information technology - Security techniques - Digital signature schemes giving message recovery - Part 3: Discrete logarithm based mechanisms

[28] ISO/IEC 10118 (all parts), Information technology - Security techniques - Hash-functions

[29] ISO/IEC 17025, General requirements for the competence of testing and calibration laboratories

[30] ISO/IEC 17065, Conformity assessment - Requirements for bodies certifying products, processes and services

[31] ISO/IEC 18031, Information technology - Security techniques - Random bit generation

[32] ISO/IEC 18092, Information technology - Telecommunications and information exchange between systems - Near Field Communication - Interface and Protocol (NFCIP-1)

[33] ISO/IEC 24759, Information technology - Security techniques - Test requirements for cryptographic modules

[34] ISO TS 12812-4, Core banking - Mobile financial services - Part 4: Mobile payments-to-person

[35] ISO TS 12812-5, Core banking - Mobile financial services - Part 5: Mobile payments to business

[36] ISO/IEC 9797 (all parts), Information technology - Security techniques - Message Authentication Codes (MACs)

[37] ISO/IEC 14888 (all parts), Information technology - Security techniques - Digital signatures with appendix

[38] ISO/IEC 18033 (all parts), Information technology - Security techniques - Encryption algorithms

[39] ISO/IEC 29100, Information technology - Security techniques - Privacy framework

 

MỤC LỤC

Lời nói đầu

Lời giới thiệu

1 Phạm vi áp dụng

2 Tài liệu viện dẫn

3 Thuật ngữ và định nghĩa

4 Các thuật ngữ viết tắt

5 Tóm tắt tính chất kỹ thuật của các điều khoản

Bảng 1 mô tả tính chất kỹ thuật của các điều khoản, phân loại theo yêu cầu, khuyến nghị hoặc tài liệu mô tả

6 Cân nhắc về quản lý bảo mật

6.1 Tổng quan

6.2 Mô hình ba lớp để quản lý bảo mật cho các dịch vụ tài chính di động

6.2.1 Lớp quy trình

6.2.2 Lớp ứng dụng

6.2.3 Lớp cơ sở hạ tầng

7 Nguyên tắc bảo mật và yêu cầu tối thiểu đối với dịch vụ tài chính di động

7.1 Các khía cạnh kiến trúc bảo mật cần xem xét

7.2 Tổng quan về kỹ thuật tăng cường (hardening) bảo mật dịch vụ tài chính di động

7.2.1 Tổng quan

7.2.2 Tổng quan về các kỹ thuật tăng cường bảo mật thiết bị di động

7.2.3 Tổng quan về kỹ thuật tăng cường bảo mật mạng không dây

7.2.4 Quản lý từ xa bảo mật các thành phần thiết bị di động bằng OTA

7.2.5 Kỹ thuật tăng cường bảo mật ứng dụng tài chính di động

7.2.6 Dịch vụ bảo mật nền tảng

7.2.7 Dịch vụ bảo mật cấp ứng dụng cho các ứng dụng tài chính di động

7.2.8 Dịch vụ bảo mật quản lý ứng dụng

7.3 Bộ yêu cầu bảo mật tối thiểu cho các dịch vụ tài chính di động

7.3.1 Tổng quan

7.3.2 Yêu cầu truy cập MFS từ xa

7.3.3 Yêu cầu xử lý giao dịch

7.3.4 Bảo vệ dữ liệu nhạy cảm

7.3.5 Yêu cầu đối với thiết bị di động

7.3.6 Đào tạo khách hàng

7.4 Bộ yêu cầu bảo mật tối thiểu cho quản lý ứng dụng di động

7.4.1 Yêu cầu đăng ký và cung cấp cho khách hàng

7.4.2 Quản lý khóa

7.4.3 Trao đổi nhà cung cấp dịch vụ tài chính di động và người quản lý dịch vụ đáng tin cậy

7.4.4 Hủy kích hoạt ứng dụng

7.5 Tóm tắt: Yêu cầu đối với dịch vụ bảo mật cho dịch vụ tài chính di động

8 Yêu cầu bảo mật cho các thành phần mật mã được sử dụng cho MFS

8.1 Môi trường bảo mật cho thiết bị di động

8.1.1 Yêu cầu về thiết bị di động cho MFS

8.1.2 Môi trường bảo mật dựa trên phần mềm

8.1.3 Môi trường thực thi tin cậy (TEE)

8.1.4 Yêu cầu đối với phần tử bảo mật

8.1.5 Yêu cầu về phần tử bảo mật đối với dịch vụ chữ ký số

8.2 Yêu cầu bảo mật đối với các mô-đun mật mã sử dụng cho MFS

8.2.1 Tổng quan

8.2.2 Danh sách yêu cầu đối với các mô-đun phần cứng mật mã

8.2.3 Yêu cầu đối với mô-đun phần mềm mật mã

9 Các khía cạnh đánh giá và chứng nhận bảo mật

9.1 Khuyến nghị chung

9.2 Mô-đun mật mã

9.3 Mô-đun phần mềm

9.4 Khả năng tương tác của các chứng nhận bảo mật

9.5 Hướng dẫn đánh giá và chứng nhận bảo mật TEE

10 Yêu cầu bảo mật cho thanh toán di động gần

10.1 Khái quát chung

10.2 Yêu cầu bảo mật chung

11 Yêu cầu bảo mật cho các thanh toán di động từ xa

11.1 Khái quát chung

11.2 Yêu cầu bảo mật

12 Yêu cầu bảo mật cho dịch vụ ngân hàng di động

12.1 Khái quát chung

12.2 Cân nhắc về xác thực

12.3 Yêu cầu bảo mật

13 Tiền điện tử

13.1 Tổng quan

13.2 Yêu cầu về tính ẩn danh

13.3 Yêu cầu bảo mật

14 Yêu cầu bảo vệ dữ liệu

14.1 Cân nhắc chung và khuôn khổ pháp lý để tuân thủ

14.2 Yêu cầu và khuyến nghị về bảo vệ dữ liệu

14.3 Đánh giá quyền riêng tư

Phụ lục A (Tham khảo)

Phụ lục B (Tham khảo)

Phụ lục C (Tham khảo)

Phụ lục D (Tham khảo)

Thư mục Tài liệu tham khảo