Tiêu chuẩn TCVN 13468:2022 về Các kỹ thuật an toàn - Hồ sơ bảo vệ cho phần mềm ứng dụng

• Số hiệu: TCVN13468:2022
• Loại văn bản: Tiêu chuẩn Việt Nam
• Nơi ban hành: ***
• Người ký: ***
• Ngày ban hành: Năm 2022

TIÊU CHUẨN QUỐC GIA

TCVN 13468:2022

CÔNG NGHỆ THÔNG TIN - CÁC KỸ THUẬT AN TOÀN - HỒ SƠ BẢO VỆ CHO PHẦN MỀM ỨNG DỤNG

Information technology - Security techniques - Protection profile for Application Software

Lời nói đầu

TCVN 13468:2022 được xây dựng dựa trên cơ sở tham khảo Hồ sơ bảo vệ cho phần mềm ứng dụng (Protection Profile for Application Software), phiên bản 1.2 ngày 22/4/2016 của Hiệp hội đảm bảo thông tin quốc gia của Hoa Kỳ (NIAP).

TCVN 13468:2022 do Cục An toàn thông tin biên soạn, Bộ Thông tin và Truyền thông đề nghị, Tổng cục Tiêu chuẩn Đo lường Chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố.

CÔNG NGHỆ THÔNG TIN - CÁC KỸ THUẬT AN TOÀN - HỒ SƠ BẢO VỆ CHO PHẦN MỀM ỨNG DỤNG

...

...

...

1  Phạm vi áp dụng

Tiêu chuẩn này quy định các yêu cầu về chức năng an toàn và yêu cầu về đảm bảo an toàn của phần mềm ứng dụng trong Hồ sơ bảo vệ phù hợp với bộ tiêu chuẩn quốc gia TCVN 8709 (ba phần).

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

Các tài liệu viện dẫn sau đây là cần thiết để áp dụng tiêu chuẩn này. Đố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ả phiên bản sửa đổi, bổ sung).

TCVN 8709-1, “Công nghệ thông tin - Các kỹ thuật an toàn - Các tiêu chí đánh giá an toàn CNTT - Phần 1: Giới thiệu và mô hình tổng quát”.

TCVN 8709-2, “Công nghệ thông tin - Các kỹ thuật an toàn - Các tiêu chí đánh giá an toàn CNTT - Phần 2: Các thành phần chức năng an toàn”.

TCVN 8709-3, “Công nghệ thông tin - Các kỹ thuật an toàn - Các tiêu chí đánh giá an toàn CNTT - Phần 2: Các thành phần đảm bảo an toàn”.

RFC 2560, “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP” (Giao thức trạng thái chứng chỉ trực tuyến của Cơ sở hạ tầng Khóa công khai trên Internet X.509).

RFC 2818, “HTTP Over TLS” (HTTP qua TLS).

...

...

...

RFC 5259, “Internet Message Access Protocol - CONVERT Extension” (Giao thức truy cập thông điệp trên Internet - Mở rộng CONVERT).

RFC 5280, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile” (Hồ sơ Chứng chỉ cơ sở hạ tầng khóa công khai X.509 và Danh sách thu hồi chứng chỉ CRL).

RFC 5289, “TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)” (Bộ hệ mật Đường cong elliptic của TLS với SHA-256/384 và kiểu đếm Galois GCM).

RFC 6066, “Transport Layer Security (TLS) Extensions: Extension Definitions” (Mở rộng Bảo mật tầng giao vận TLS: các định nghĩa mở rộng).

RFC 6125, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)” (Biểu diễn và xác minh nhận dạng dịch vụ ứng dụng dựa trên miền trong Cơ sở hạ tầng khóa công khai trên Internet sử dụng các chứng chỉ X.509 (PKIX) trong ngữ cảnh của bảo mật tầng giao vận TLS).

RFC 6347, “Datagram Transport Layer Security Version 1.2” (Gói dữ liệu cho Giao thức bảo mật tầng giao vận Phiên bản 1.2).

RFC 6460, “Suite B Profile for Transport Layer Security (TLS)” (Hồ sơ Bộ mã hóa B cho Giao thức bảo mật tầng giao vận TLS).

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

Trong tiêu chuẩn này sử dụng các thuật ngữ và định nghĩa sau:

...

...

...

Tiêu chí chung (Common Criteria - CC)

Tiêu chí chung để đánh giá an toàn công nghệ thông tin.

3.2

Phương pháp đánh giá chung (Common Evaluation Methodology - CEM)

Phương pháp đánh giá chung để đánh giá an toàn công nghệ thông tin.

3.3

Hồ sơ bảo vệ (Protection Profile - PP)

Tập hợp các yêu cầu an toàn cho một chủng loại sản phẩm độc lập về mặt thực thi.

CHÚ THÍCH: Thuật ngữ Hồ sơ bảo vệ trong tiêu chuẩn này phù hợp với thuật ngữ trong TCVN 8709-1.

...

...

...

Đích an toàn (Security Target - ST)

Tập hợp yêu cầu an toàn cho một sản phẩm cụ thể phụ thuộc về mặt thực thi.

CHÚ THÍCH: Thuật ngữ Đích an toàn trong tiêu chuẩn này phù hợp với thuật ngữ trong TCVN 8709-1.

3.5

Đích đánh giá (Target of Evaluation - TOE)

Các sản phẩm được đánh giá. Trong tiêu chuẩn này là phần mềm ứng dụng và tài liệu hỗ trợ.

CHÚ THÍCH: Thuật ngữ Đích đánh giá trong tiêu chuẩn này phù hợp với thuật ngữ trong TCVN 8709-1.

3.6

Chức năng an toàn của TOE (TOE Security Funtionality - TSF)

...

...

...

CHÚ THÍCH: Thuật ngữ Chức năng an toàn của TOE trong tiêu chuẩn này phù hợp với thuật ngữ trong TCVN 8709-1.

3.7

Đặc tả tóm tắt của TOE (TOE Summary Specification - TSS)

Mô tả về cách Đích đánh giá thỏa mãn các Yêu cầu chức năng an toàn trong một Đích an toàn.

3.8

Yêu cầu chức năng an toàn (Security Functional Requirement - SFR)

Yêu cầu an toàn bắt buộc bởi TOE.

3.9

Yêu cầu đảm bảo an toàn (Security Assurance Requirement - SAR)

...

...

...

3.10

Ngẫu nhiên hóa cách bố trí không gian địa chỉ (Address Space Layout Randomization - ASLR)

Tính năng chống khai thác bằng cách tải ánh xạ bộ nhớ vào vị trí không thể đoán được. ASLR gây khó khăn hơn cho kẻ tấn công khi chuyển điều khiển đến đoạn mã tương ứng với không gian địa chỉ của tiến trình ứng dụng.

3.11

Ứng dụng (app)

Phần mềm và các tài liệu hỗ trợ của nó chạy trên một nền tảng nào đó để thực hiện nhiệm vụ của người sử dụng hoặc người sở hữu của nền tảng đó. Thuật ngữ Đích đánh giá (TOE) và ứng dụng có nghĩa như nhau trong tiêu chuẩn này.

3.12

Giao diện lập trình ứng dụng (Application Programming Interface - API)

Đặc tả kỹ thuật của các hàm, cấu trúc dữ liệu, các lớp đối tượng và các biến cho phép ứng dụng sử dụng các dịch vụ được cung cấp bởi các thành phần khác của phần mềm như thư viện. Các API thường được cung cấp bởi bộ các thư viện cho các nền tảng khác nhau.

...

...

...

Ủy nhiệm (credential)

Dữ liệu thiết lập định danh của người dùng, ví dụ khóa mật mã hoặc mật khẩu.

3.14

Ngăn chặn thực thi dữ liệu (Data Execution Prevention - DEP)

Tính năng chống khai thác của các hệ điều hành mới, thực thi trên các phần cứng máy tính hiện đại thực hiện yêu cầu cấm thực thi trên các trang trong bộ nhớ. DEP ngăn chặn các trang của bộ nhớ chứa cả dữ liệu và các lệnh, làm cho các kẻ tấn công sẽ gặp khó khăn hơn khi đưa vào và thực thi mã.

3.15

Bên phát triển (developer)

Người viết phần mềm ứng dụng. Trong tiêu chuẩn này, bên bán và người lập trình đều được xem như bên phát triển.

3.16

...

...

...

Phần mềm được truyền từ một hệ thống từ xa để thực hiện trong một môi trường thực thi hạn chế trên hệ thống cục bộ. Thông thường, sẽ không yêu cầu cài đặt và việc thực thi sẽ bắt đầu mà không cần sự đồng ý của người dùng hoặc thậm chí là thông báo. Ví dụ về công nghệ mã di động bao gồm JavaScript, Java applet, Adobe Flash, và Microsoft Silverlight.

3.17

Hệ điều hành (Operating System - OS)

Phần mềm quản lý tài nguyên phần cứng và cung cấp các dịch vụ cho các ứng dụng.

3.18

Thông tin định danh (Personally Identifiable Information - PII)

Mọi thông tin về một cá nhân được duy trì bởi một cơ quan, ví dụ như giáo dục, giao dịch tài chính, lịch sử y khoa, lịch sử phạm tội hoặc quá trình làm việc... và thông tin có thể được dùng để phân biệt hoặc theo dõi định danh của cá nhân như tên, số an sinh xã hội, ngày và nơi sinh, tên của nữ trước khi kết hôn (nước ngoài), thông tin sinh trắc học... bao gồm cả thông tin cá nhân khác có liên kết hoặc có thể liên kết đến một cá nhân.

3.19

Nền tảng (platform)

...

...

...

3.20

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

Dữ liệu nhạy cảm có thể gồm tất cả dữ liệu của người dùng hoặc doanh nghiệp hoặc có thể là dữ liệu của ứng dụng cụ thể như email, tin nhắn, tài liệu, lịch, danh bạ... Dữ liệu nhạy cảm chứa ít nhất một trong các loại thông tin có thể định danh PII, các chứng chỉ và các khóa. Dữ liệu nhạy cảm sẽ được tác giả của đích an toàn xác định trong TSS của ứng dụng.

3.21

Cookie ngăn xếp (stack cookie)

Tính năng chống khai thác thực hiện việc đặt một giá trị trên ngăn xếp (stack) lúc bắt đầu gọi hàm và kiểm tra giá trị đó có giống hay không lúc kết thúc gọi hàm. Tính năng này còn được gọi là bảo vệ ngăn xếp (Stack Guard) hoặc Giá trị ngẫu nhiên bí mật của ngăn xếp (Stack Canaries).

3.22

Bên bán (vendor)

Bên bán phần mềm ứng dụng. Trong tiêu chuẩn này, bên bán và bên phát triển là như nhau. Bên bán có trách nhiệm duy trì và cập nhật phần mềm ứng dụng.

...

...

...

ADB

Phần mềm ADB của Android chạy trên Windows

Android Debug Bridge

AES

Chuẩn mã hóa tiên tiến

Advanced Encryption Standard

ANSI

Viện Tiêu chuẩn Quốc gia Hoa Kỳ

American National Standards Institute

...

...

...

Giao diện lập trình ứng dụng

Application Programming Interface

APK

Gói ứng dụng cho Android

Android Application Package

APPX

Gói ứng dụng đa dụng cho Windows

Windows Universal Application Package

ASLR

...

...

...

Address Space Layout Randomization

BAR

Gói ứng dụng cho Blackberry

Blackberry Application Package

BIOS

Hệ thống vào ra cơ bản

Basic Input/Output System

CDSA

Kiến trúc an toàn dữ liệu chung

...

...

...

CESG

Nhóm an toàn Truyền thông - Điện tử

Communications-Electronics Security Group

CMC

Quản lý chứng chỉ qua CMS

Certificate Management over CMS

CMS

Cú pháp thông điệp mật mã

Cryptographic Message Syntax

...

...

...

Tên thông dụng

Common Names

CRL

Danh sách thu hồi chứng chỉ

Certificate Revocation List

CSA

Luật an toàn máy tính

Computer Security Act

DEP

...

...

...

Data Execution Prevention

DES

Chuẩn mã hóa dữ liệu

Data Encryption Standard

DHE

Khóa tạm thời Diffie-Hellman

Diffie-Hellman Ephemeral

DMG

Ảnh đĩa của Apple

...

...

...

DNS

Hệ thống tên miền

Domain Name System

DPAPI

Giao diện lập trình ứng dụng bảo vệ dữ liệu

Data Protection Application Programming Interface

DRBG

Bộ phát bit ngẫu nhiên bất định

Deterministic Random Bit Generator

...

...

...

Chuẩn chữ ký số

Digital Signature Standard

DT

Vec-tơ ngày/giờ

Date/Time Vector

DTLS

Bảo mật tầng giao vận của datagram

Datagram Transport Layer Security

EAP

...

...

...

Extensible Authentication Protocol

ECDHE

Hệ mật Diffie-Hellman trên đường cong elliptic

Elliptic Curve Diffie-Hellman Ephemeral

ECDSA

Thuật toán chữ ký số trên đường cong elliptic

Elliptic Curve Digital Signature Algorithm

EMET

Công cụ hỗ trợ ngăn chặn khai thác lỗ hổng bảo mật của Windows

...

...

...

EST

Đăng ký qua tầng giao vận an toàn

Enrollment over Secure Transport

FIPS

Tiêu chuẩn xử lý thông tin của Liên bang (Hoa Kỳ)

Federal Information Processing Standards

GPS

Hệ thống định vị toàn cầu

Global Positioning System

...

...

...

Mã xác thực thông điệp dựa trên hàm băm

Hash-based Message Authentication Code

HTTP

Giao thức truyền tin siêu văn bản

Hypertext Transfer Protocol

HTTPS

Giao thức truyền tin siêu văn bản an toàn

Hypertext Transfer Protocol Secure

IANA

...

...

...

Internet Assigned Number Authority

IEC

Ủy ban Kỹ thuật điện Quốc tế

International Electrotechnical Commission

IETF

Nhóm đặc trách về kỹ thuật Internet

Internet Engineering Task Force

IP

Giao thức mạng

...

...

...

IPA

Lưu trữ gói iOS

iOS Package archive

IR

Số nguyên trung gian

Intermediate Integer

ISO

Tổ chức Tiêu chuẩn hóa Quốc tế

International Organization for Standardization

...

...

...

Công nghệ thông tin

Information Technology

ITSEF

Cơ sở đánh giá an toàn công nghệ thông tin

Information Technology Security Evaluation Facility

JNI

Giao diện gốc Java

Java Native Interface

LDAP

...

...

...

Lightweight Directory Access Protocol

MIME

Mở rộng thư Internet đa mục đích

Multi-purpose Internet Mail Extensions

MPKG

Gói Meta

Meta Package

MSI

Bộ cài đặt của Microsoft

...

...

...

NFC

Truyền thông/giao tiếp trường gần

Near Field Communication

NIAP

Hiệp hội đảm bảo thông tin quốc gia (Hoa Kỳ)

National Information Assurance Partnership

NIST

Viện Tiêu chuẩn và Công nghệ Quốc gia (Hoa Kỳ)

National Institute of Standards and Technology

...

...

...

Giao thức trạng thái chứng chỉ trực tuyến

Online Certificate Status Protocol

OID

Bộ nhận dạng đối tượng

Object Identifier

OMB

Văn phòng quản lý và ngân sách

Office of Management and Budget

OS

...

...

...

Operating System

PDF

Định dạng tài liệu lưu động

Portable Document Format

PID

Bộ nhận dạng tiến trình

Process Identifier

PII

Thông tin định danh cá nhân

...

...

...

PKG

Tệp đóng gói

Package file

PKI

Hạ tầng khóa công khai

Public Key Infrastructure

PP

Hồ sơ bảo vệ

Protection Profile

...

...

...

Hệ mật khóa công khai RSA

Rivest-Shamir-Adleman

RBG

Bộ tạo bit ngẫu nhiên

Random Bit Generator

RFC

Khuyến cáo chuẩn của IETF

Request for Comment

RNG

...

...

...

Random Number Generator

RNGVS

Hệ thống xác thực bộ sinh số ngẫu nhiên

Random Number Generator Validation System

SAN

Tên thay thế của chủ thể

Subject Alternative Name

SAR

Yêu cầu đảm bảo an toàn

...

...

...

SE

Nâng cao bảo mật/an toàn

Security Enhancements

SFR

Yêu cầu chức năng an toàn

Security Functional Requirement

SHA

Thuật toán hàm băm an toàn SHA

Secure Hash Algorithm

...

...

...

Giao thức mở rộng thư điện tử Internet đa mục đích an toàn

Secure/Multi-purpose Internet Mail Extensions

SIP

Giao thức khởi tạo phiên

Session Initiation Protocol

SP

Ấn phẩm đặc biệt

Special Publication

SSH

...

...

...

Secure Shell

SWID

Nhận dạng phần mềm

Software Identification

TLS

An toàn tầng giao vận

Transport Layer Security

UI

Giao diện người dùng

...

...

...

URI

Bộ định danh tài nguyên thống nhất

Uniform Resource Identifier

URL

Bộ định vị tài nguyên thống nhất

Uniform Resource Locator

USB

Chuẩn kết nối tuần tự đa dụng

Universal Serial Bus

...

...

...

Biểu mẫu mô tả danh sách kiểm tra cấu hình có thể mở rộng

eXtensible Configuration Checklist Description Format

XOR

Phép XOR

Exclusive OR

5  Ranh giới của TOE

Ứng dụng, phần mềm được cung cấp bởi bên cung cấp, sẽ được cài đặt vào hệ thống tệp tin được cung cấp bởi hệ điều hành. Nó được thực hiện trên nền tảng, có thể là hệ điều hành (Hình 1), như là môi trường thực thi, hoặc là kết hợp của chúng (Hình 2). Một số hoạt động đảm bảo được chỉ định cho các nền tảng cụ thể mà ứng dụng thi hành để cung cấp sự chính xác và khả năng lặp lại. Các hoạt động kiểm tra được chủ động thực hiện từ các nhà cung cấp nền tảng để kiểm soát hoàn toàn và chính xác toàn bộ nền tảng khi có thể. Điều này sẽ cho phép chứng nhận các ứng dụng trên các nền tảng đó.

Ứng dụng bao gồm nhiều loại phần mềm như các ứng dụng văn phòng, ứng dụng trên máy trạm, các trình đọc PDF, và các ứng dụng cho điện thoại thông minh có thể tải về. TOE gồm các phần mềm trong gói cài đặt ứng dụng, thậm chí là những phần có thể mở rộng chức năng của nền tảng cơ bản như các trình điều khiển của nhân (kernel). Nhiều nền tảng khi cung cấp đã được tích hợp trong các ứng dụng như trình duyệt web, ứng dụng email và các bộ phát media và những ứng dụng đó cũng là đối tượng phải được xem xét theo các yêu cầu đã định nghĩa trong tiêu chuẩn này. BIOS và các phần sụn (firmware) khác, nhân của hệ điều hành, và các phần mềm hệ thống khác (và các trình điều khiển) được cung cấp như là một phần của nền tảng nằm ngoài phạm vi của tiêu chuẩn này.

...

...

...

Hình 2 - TOE là ứng dụng chạy trong môi trường thực thi có mã gốc

6  Yêu cầu tuân thủ

6.1  Tuyên bố tuân thủ

Để phù hợp với PP này, một ST phải chứng minh tuân thủ chính xác (Exact Conformance), một tập con của tuân thủ nghiêm ngặt (Strict Conformance) như đã được định nghĩa trong phần 1 của CC (ASE_CCL). ST phải bao gồm tất cả các thành phần trong PP này là:

- vô điều kiện (luôn luôn được yêu cầu);

- dựa trên lựa chọn (được yêu cầu khi các lựa chọn cụ thể được chọn trong các yêu cầu vô điều kiện), và có thể bao gồm các thành phần là:

- tùy chọn, hoặc

- mục tiêu.

...

...

...

6.2  Yêu cầu phù hợp với CC

Tiêu chuẩn này phù hợp với TCVN 8709-2, TCVN 8709-3.

6.3  Yêu cầu phù hợp với PP

Tiêu chuẩn này không tuyên bố sự phù hợp với bất kỳ hồ sơ bảo vệ nào khác.

6.4  Yêu cầu phù hợp với gói ứng dụng

Tiêu chuẩn này không yêu cầu phù hợp bất kỳ gói ứng dụng nào.

7  Xác định vấn đề an toàn

7.1  Các mối đe dọa

- Mối đe dọa tấn công mạng (T.NETWORK_ATTACK): Kẻ tấn công được định vị trên kênh liên lạc hoặc ở bất kỳ đâu trên hạ tầng mạng. Kẻ tấn công có thể giao tiếp với phần mềm ứng dụng hoặc tạo ra các kết nối giữa phần mềm ứng dụng với các thiết bị đầu cuối khác để xâm phạm nó.

...

...

...

- Mối đe dọa tấn công cục bộ (T.LOCAL_ATTACK): Kẻ tấn công có thể hành động thông qua phần mềm không có đặc quyền trên cùng nền tảng máy tính mà ứng dụng thực thi. Kẻ tấn công có thể đưa vào đầu vào ứng dụng các định dạng độc hại ở dạng các các tập tin hoặc các kết nối cục bộ khác.

- Mối đe dọa từ truy cập vật lý (T.PHYSICAL_ACCESS): Kẻ tấn công có thể cố truy cập dữ liệu nhạy cảm lưu trú trong máy tính.

7.2  Các giả định

- Giả định nền tảng (A. PLATFORM): TOE dựa trên một nền tảng máy tính tin cậy để thực thi. Điều này bao gồm nền tảng cơ bản và bất kỳ môi trường thực thi nào cung cấp cho TOE.

- Giả định người dùng phù hợp (A.PROPER_USER): Người sử dụng phần mềm ứng dụng không phải là cố ý lơ là hoặc chống đối, sử dụng phần mềm tuân thủ chính sách bảo mật đang áp dụng của doanh nghiệp.

- Giả định quản trị viên phù hợp (A.PROPER_ADMIN): Quản trị viên của phần mềm ứng dụng không phải là người bất cẩn, cố ý lơ là hoặc chống đối, quản lý phần mềm tuân thủ chính sách bảo mật đang áp dụng của doanh nghiệp.

7.3  Chính sách bảo mật của tổ chức

Không có chính sách bảo mật của tổ chức cho ứng dụng.

8  Mục tiêu an toàn

...

...

...

- MỤC TIÊU TOÀN VẸN (O.INTEGRITY): Các TOE tuân thủ đảm bảo tính toàn vẹn của gói cài đặt và cập nhật của chúng, đồng thời tận dụng các biện pháp giảm thiểu tác hại dựa trên môi trường thực thi. Phần mềm hiếm khi được phát hành mà không có lỗi, và khả năng triển khai các bản vá lỗi và các bản cập nhật đảm bảo tính toàn vẹn là rất quan trọng đối với an toàn mạng doanh nghiệp. Các nhà sản xuất bộ vi xử lý, các nhà phát triển trình biên dịch, các nhà cung cấp môi trường thực thi và các nhà cung cấp hệ điều hành đã phát triển các biện pháp nhằm giảm thiểu tác hại dựa trên môi trường thực thi để tăng phí tổn cho kẻ tấn công bằng cách thêm sự phức tạp vào nhiệm vụ xâm hại hệ thống. Phần mềm ứng dụng thường có thể tận dụng các cơ chế này bằng cách sử dụng các API được cung cấp bởi môi trường thực thi hoặc bằng cách bật cơ chế thông qua các tùy chọn của các trình biên dịch hoặc các trình liên kết

Giải quyết bằng: FDP_DEC_EXT.1 (9.1.2), FMT_CFG_EXT.1 (9.1.3), FPT_AEX_EXT.1 (9.1.5), FPT_TUD_EXT.1 (9.1.5).

- MỤC TIÊU CHẤT LƯỢNG (O.QUALITY): Để đảm bảo chất lượng thực hiện, các TOE phù hợp tận dụng các dịch vụ và các API được cung cấp bởi môi trường thực thi phù hợp hơn là triển khai các phiên bản riêng của các dịch vụ này và các API này. Điều này đặc biệt quan trọng đối với các dịch vụ mật mã và các hoạt động phức tạp khác như phân tích cú pháp tập tin và phương tiện truyền thông (media). Tận dụng hành vi nền tảng này dựa trên việc chỉ sử dụng các API được lập thành tài liệu và được hỗ trợ.

Giải quyết bằng: FMT_MEC_EXT.1 (9.1.3), FPT_API_EXT.1 (9.1.5), FPT_LIB_EXT.1 (9.1.5).

- MỤC TIÊU QUẢN LÝ (O.MANAGEMENT): Để tạo thuận lợi cho việc quản lý bởi người dùng và doanh nghiệp, các TOE phù hợp sẽ cung cấp các giao diện nhất quán và được hỗ trợ cho việc cấu hình và bảo trì có liên quan đến an toàn thông tin của họ. Điều này bao gồm việc triển khai ứng dụng và cập nhật ứng dụng thông qua việc sử dụng các cơ chế và định dạng triển khai nền tảng được hỗ trợ, cũng như cung cấp cơ chế để cấu hình. Điều này cũng bao gồm việc cung cấp quyền kiểm soát cho người dùng về việc tiết lộ PII (thông tin có thể định danh cá nhân) bất kỳ.

Giải quyết bằng: FMT_SMF.1 (9.1.3), FPT_IDV_EXT.1 (Điều C.3 Phụ lục C), FPT_TUD_EXT.1.5 (9.1.5), FPR_ANO_EXT.1 (9.1.4).

- MỤC TIÊU BẢO VỆ LƯU TRỮ (O.PROTECTED_STORAGE): Để giải quyết vấn đề mất tính bí mật của dữ liệu người dùng trong trường hợp mất kiểm soát vật lý của phương tiện lưu trữ, các TOE phù hợp sẽ sử dụng bảo vệ dữ liệu ở phần còn lại. Điều này liên quan đến mã hóa dữ liệu và các khóa được lưu trữ bởi TOE để ngăn chặn truy cập trái phép vào dữ liệu này. Điều này cũng bao gồm khả năng các kết nối mạng không cần thiết có thể gây hậu quả làm mất dữ liệu.

Giải quyết bằng: FDP_DAR_EXT.1 (9.1.2), FDP_DAR_EXT.1 (9.1.2), FCS_STO_EXT.1 (9.1.1), FCS_RBG_EXT.1 (9.1.1).

- MỤC TIÊU BẢO VỆ TRUYỀN THÔNG (O.PROTECTED_COMMS): Để giải quyết các mối đe dọa tấn công mạng thụ động (nghe trộm) và tích cực (sửa đổi gói tin), các TOE phù hợp sẽ sử dụng một kênh tin cậy cho dữ liệu nhạy cảm. Dữ liệu nhạy cảm bao gồm khóa mật mã, mật khẩu và bất kỳ dữ liệu khác cụ thể với ứng dụng mà không được tiết lộ ra bên ngoài ứng dụng.

...

...

...

8.2  Mục tiêu an toàn cho môi trường hoạt động

Các mục tiêu an toàn sau đây cho môi trường hoạt động hỗ trợ TOE trong việc cung cấp đúng chức năng an toàn của nó. Những mục tiêu này bám sát các giả định về môi trường.

- NỀN TẢNG CỦA MÔI TRƯỜNG HOẠT ĐỘNG (OE.PLATFORM): TOE dựa vào một nền tảng máy tính tin cậy để thực hiện nó. Điều này bao gồm hệ điều hành bên dưới và bất kỳ môi trường thực thi rời rạc nào được cung cấp cho TOE.

- NGƯỜI DÙNG PHÙ HỢP CỦA MÔI TRƯỜNG HOẠT ĐỘNG (OE.PROPER_USER): Người sử dụng phần mềm ứng dụng không phải là người cố ý lơ là hoặc chống đối, và sử dụng phần mềm tuân thủ chính sách bảo mật đang áp dụng của doanh nghiệp.

- QUẢN TRỊ VIÊN PHÙ HỢP CỦA MÔI TRƯỜNG HOẠT ĐỘNG (OE.PROPER_ADMIN): Quản trị viên của phần mềm ứng dụng không phải là người bất cẩn, cố ý lơ là hoặc chống đối, quản lý phần mềm tuân theo chính sách bảo mật đang áp dụng của doanh nghiệp.

8.3  Lý do mục tiêu an toàn

Điều này mô tả các giả định, các mối đe dọa và các chính sách bảo mật của tổ chức tương ứng với các mục tiêu an toàn.

Mối đe dọa, giả định hoặc chính sách bảo mật của tổ chức

Mục tiêu an toàn

...

...

...

T.NETWORK_ATTACK

O.PROTECTED_COMMS, O.INTEGRITY, O.MANAGEMENT

Nguy cơ T.NETWORK_ATTACK được đáp trả bởi O.PROTECTED_COMMS vì nó cung cấp tính toàn vẹn của dữ liệu được truyền.

Nguy cơ T.NETWORK_ATTACK được đáp trả bởi O.INTEGRTY vì nó cung cấp tính toàn vẹn của phần mềm được cài đặt trên hệ thống từ mạng.

Nguy cơ T.NETWORK_ATTACK được đáp trả bởi O.MANAGEMENT vì nó cung cấp khả năng cấu hình ứng dụng để chống lại các tấn công mạng.

T.NETWORK_EAVESDROP

O.PROTECTED_COMMS, O.QUALITY, O.MANAGEMENT

Nguy cơ T.NETWORK_EAVESDROP được đáp trả bởi O.PROTECTED_COMMS vì nó cung cấp tính bảo mật của dữ liệu được truyền.

Mục tiêu O.QUALITY đảm bảo sử dụng các cơ chế cung cấp bảo vệ chống lại các tấn công dựa vào mạng.

...

...

...

T.LOCAL_ATTACK

O.QUALITY

Mục tiêu O.QUALITY giúp chống lại việc sử dụng các cơ chế làm yếu TOE liên quan đến các tấn công bởi các phần mềm khác.

T.PHYSICAL_ACCESS

O.PROTECTED_STORAGE

Mục tiêu O.PROTECTED_STORAGE giúp chống lại các nỗ lực truy cập trái phép vào việc lưu trữ vật lý được sử dụng bởi TOE.

A. PLATFORM

OE.PLATFORM

Mục tiêu môi trường hoạt động OE.PLATFORM được thực hiện thông qua A.PLATFORM.

...

...

...

OE.PROPER_USER

Mục tiêu môi trường hoạt động OE.PROPER_USER được thực hiện thông qua A.PROPER_USER.

A.PROPER_ADMIN

OE.PROPER_ADMIN

Mục tiêu môi trường hoạt động OE.PROPER_ADMIN được thực hiện thông qua A.PROPER_ADMIN.

9  Các yêu cầu an toàn

Phần này mô tả về những yêu cầu an toàn mà TOE phải thực hiện, bao gồm những thành phần chức năng từ Phần 2 [2] và những thành phần đảm bảo ở Phần 3 [2] của CC. Những ký hiệu dưới đây được dùng là:

- Tinh chỉnh (hiển thị bằng chữ in đậm): được dùng để thêm chi tiết cho 1 yêu cầu, do đó hạn chế hơn yêu cầu.

- Lựa chọn (hiển thị bằng chữ in nghiêng): được dùng để chọn 1 hay nhiều tùy chọn được cung cấp bởi CC khi ra yêu cầu.

...

...

...

- Lặp lại: được xác định với 1 số bên trong ngoặc đơn (ví dụ “(1)”).

9.1  Yêu cầu chức năng an toàn

Những yêu cầu chức năng an toàn trong phần này được xuất phát từ Phần 2 của Tiêu chí chung Đánh giá an toàn công nghệ thông tin, phiên bản 3.1 - sửa đổi lần 4, với các thành phần chức năng được mở rộng thêm.

9.1.1  Hỗ trợ bằng mật mã (FCS)

9.1.1.1  FCS_RBG_EXT.1 Dịch vụ sinh bit ngẫu nhiên

FCS_RBG_EXT.1.1

Ứng dụng sẽ [lựa chọn:

không dùng chức năng DRBG,

gọi chức năng DRBG được nền tảng cung cấp,

...

...

...

] cho các thuật toán mật mã của nó.

Lưu ý khi thực hiện: Nếu chọn Thực hiện chức năng DRBG, sau đó các phần tử FCS_RBG_EXT.2 (Phụ lục B) thêm vào sẽ được bao gồm trong ST. Trong yêu cầu này, các thuật toán mật mã bao gồm tạo / dẫn xuất/ thỏa thuận khóa mật mã, các IV (cho những chế độ nhất định), cũng như những giá trị ngẫu nhiên của giao thức chỉ định.

Hoạt động đảm bảo:

Nếu chọn Không dùng chức năng không DRBG, người đánh giá sẽ kiểm tra ứng dụng và tài liệu của bên phát triển và xác minh ứng dụng không cần dịch vụ sinh bit ngẫu nhiên.

Nếu chọn Thực hiện chức năng DRBG, người đánh giá sẽ đảm bảo rằng những phần tử FCS_RBG_EXT.2 (Phụ lục B) thêm vào sẽ được bao gồm trong ST.

Nếu chọn Gọi chức năng DRBG được nền tảng cung cấp, người đánh giá thể hiện những hoạt động sau. Người đánh giá sẽ khảo sát TSS để xác nhận rằng nó xác định tất cả các chức năng (như được mô tả bởi các SFR trong ST) để có những số ngẫu nhiên từ nền tảng RBG. Người đánh giá sẽ xác định rằng cho mỗi một chức năng này, TSS sẽ xác định giao diện nền API nào được dùng để có các số ngẫu nhiên. Người đánh giá sẽ phải xác nhận rằng mỗi một giao diện này tương ứng với những giao diện có thể được chấp nhận trong danh sách cho mỗi nền tảng bên dưới. Người đánh giá sẽ phải dịch ngược ứng dụng dạng nhị phân bằng cách dùng các trình dịch ngược thích hợp cho ứng dụng (TOE). Người đánh giá sẽ phải tìm đầu ra của trình dịch ngược để xác định rằng, với mỗi API được liệt kê trong TSS, API sẽ xuất hiện trong đầu ra. Nếu đại diện của API không phản hồi trực tiếp tới các chuỗi trong danh sách sau, người đánh giá sẽ phải cung cấp một bản tương quan giữa những từ ngữ trong trình dịch ngược sang API tương ứng, với mô tả tại sao những văn bản của API không tương ứng trực tiếp với văn bản dịch ngược và chứng minh rằng văn bản dịch ngược tương ứng với API liên quan.

Cần lưu ý là không kỳ vọng rằng người đánh giá có xác nhận rằng các API đang được dùng “đúng” cho những chức năng được xác định trong TSS; hoạt động này là để liệt kê các API đã sử dụng và sau đó để kiểm tra sự tồn tại thông qua việc dịch ngược.

Dưới đây là danh sách các API được chấp nhận cho mỗi nền tảng:

Đối với Blackberry: người đánh giá sẽ phải xác nhận rằng ứng dụng sẽ gọi Security Builder Crypto GSE.

...

...

...

javax.crypto.KeyGenerator hay lớp java.security.SecureRandom hay /dev/random hay /dev/urandom.

Đối với Window: người đánh giá sẽ phải xác nhận rằng API BCryptGenRandom hay CryptGenRandom được dùng cho ứng dụng máy tính bàn truyền thống. Người đánh giá sẽ phải xác thực rằng API System.Random được dùng cho các Ứng dụng Nhiều nền tảng của Windows (Windows Universal Applications). Trong các phiên bản tương lai của tiêu chuẩn này, CryptGenRandom có thể bị loại bỏ như là một tùy chọn vì nó không còn là một API được ưa thích cho tài liệu của nhà cung cấp.

Đối với iOS: người đánh giá sẽ phải xác nhận rằng ứng dụng sẽ gọi SecRandomCopyBytes hoặc sẽ trực tiếp dùng /dev/random để có ngẫu nhiên.

Đối với Linux: người đánh giá sẽ phải xác nhận rằng ứng dụng thu thập ngẫu nhiên từ /dev/random hay /dev/urandom.

Đối với Solaris: người đánh giá sẽ phải xác nhận rằng ứng dụng thu thập ngẫu nhiên từ /dev/random.

Đối với Mac OS X: người đánh giá sẽ phải xác nhận rằng ứng dụng dùng /dev/random để thu thập ngẫu nhiên.

Nếu việc gọi chức năng được nền tảng cung cấp được thực hiện bằng cách khác, người đánh giá sẽ phải đảm bảo TSS mô tả cách thực hiện và nó tương đương với các phương pháp đã liệt kê ở đây như thế nào (ví dụ API mức cao hơn gọi xác thực API mức thấp).

9.1.1.2  FCS_STO_EXT.1 Lưu trữ các chứng chỉ

FCS_STO_EXT.1.1

...

...

...

không lưu trữ bất cứ chứng chỉ nào,

gọi chức năng cung cấp bởi nền tảng để lưu trữ an toàn [chỉ định: danh sách các chứng chỉ], thực hiện chức năng lưu trữ an toàn [chỉ định: danh sách các chứng chỉ]

] vào bộ nhớ ổn định (non-volatile memory).

Lưu ý khi thực hiện: Yêu cầu này đảm bảo rằng về các chứng chỉ ổn định (các khóa bí mật, các khóa riêng của hạ tầng khóa công khai PKI, hay các mật khẩu) được lưu trữ một cách an toàn.

Hoạt động đảm bảo này hàm ý hạn chế những lựa chọn có thể được thực hiện trên cơ sở của từng nền tảng. Ví dụ nếu nền tảng cung cấp bảo vệ phần cứng để lưu trữ các chứng chỉ thì không được chỉ định lựa chọn thứ ba.

Nếu chọn thực hiện chức năng lưu trữ an toàn các chứng chỉ thì các thành phần sau đây phải được bao gồm trong ST: FCS_COP.1(1) (Điều B.5 Phụ lục B). Nếu các thuật toán mật mã khác được dùng để thực hiện lưu trữ an toàn các chứng chỉ thì các yêu cầu tương ứng cũng phải được bao gồm trong ST.

Hoạt động đảm bảo:

Người đánh giá sẽ phải kiểm tra TSS để đảm bảo rằng nó sẽ liệt kê tất cả các chứng chỉ ổn định (các khóa bí mật, các khóa riêng của hạ tầng khóa công khai PKI, hay các mật khẩu) cần để đáp ứng những yêu cầu trong ST. Với mỗi mục này, người đánh giá sẽ phải xác nhận rằng TSS liệt kê mục đích sử dụng, và cách thức lưu trữ.

Với tất cả các chứng chỉ mà ứng dụng gọi từ chức năng được nền tảng cung cấp, người đánh giá sẽ phải thực hiện các hành động sau tùy theo từng nền tảng:

...

...

...

Đối với Android: Người đánh giá sẽ phải xác nhận rằng ứng dụng dùng KeyStore của Android hay KeyChain của Android để lưu trữ các chứng chỉ.

Đối với Windows: Người đánh giá sẽ phải xác nhận rằng mọi chứng chỉ được lưu trữ tại Windows Certificate Store. Người đánh giá sẽ phải xác nhận những chứng chỉ khác như mật mã được lưu trữ tại Windows Credential Manager hay được lưu sử dụng API Bảo vệ Dữ liệu (DPAPI - Data Protection API). Đối với các Ứng dụng Nhiều nền tảng của Windows (Windows Universal Application), người đánh giá sẽ phải xác nhận rằng ứng dụng đang dùng lớp ProtectData và lưu trữ các chứng chỉ trong IsolatedStorage.

Đối với iOS: Người đánh giá sẽ phải xác nhận rằng tất cả các chứng chỉ được lưu trữ trong Keychain.

Đối với Linux: Người đánh giá sẽ phải xác nhận rằng tất cả khóa được lưu bằng cách dùng keyrings của Linux.

Đối với Solaris: Người đánh giá sẽ phải xác nhận rằng tất cả các khóa được lưu trữ bằng cách dùng Key Management Framework (KMF) của Solaris.

Đối với Mac OS X: Người đánh giá sẽ phải xác nhận rằng tất cả các chứng chỉ được lưu trữ trong Keychain.

9.1.2  Bảo vệ dữ liệu người dùng (FDP)

9.1.2.1  FDP_DEC_EXT.1 Truy cập đến tài nguyên của nền tảng

FDP_DEC_EXT.1.1

...

...

...

không tài nguyên phần cứng,

kết nối mạng,

camera,

microphone,

dịch vụ định vị,

NFC,

USB,

Bluetooth,

[Chỉ định: danh sách các tài nguyên phần cứng bổ sung]

...

...

...

Lưu ý khi thực hiện: Mục đích là để người đánh giá đảm bảo rằng sự lựa chọn sẽ áp dụng cho tất cả tài nguyên phần cứng mà ứng dụng truy cập, và lựa chọn đó được hạn chế cho những người đã được xác minh. Trên một số nền tảng, ứng dụng phải có xin phép rõ ràng để có quyền truy cập vào tài nguyên phần cứng. Việc xin phép như vậy ngay cả khi ứng dụng không sử dụng tài nguyên phần cứng về sau vẫn phải được quan tâm khi truy cập. Các lựa chọn nên được hiển thị theo cách nhất quán với ứng dụng hiển thị các nhu cầu truy cập của nó đến nền tảng bên dưới. Ví dụ nền tảng có thể cung cấp dịch vụ định vị dựa trên khả năng sử dụng nhiều nguồn tài nguyên phần cứng (như bộ thu vệ tinh, WiFi, vô tuyến di động) khi dịch vụ định vị là lựa chọn phù hợp. Điều này là do việc sử dụng những tài nguyên này có thể được suy luận, nhưng cũng bởi vì việc sử dụng thực tế có thể khác nhau dựa trên các nền tảng cụ thể. Các tài nguyên không cần phải xác định rõ ràng là những tài nguyên được sử dụng thông thường bởi bất kỳ ứng dụng nào như các bộ vi xử lý, bộ nhớ chính, màn hình, thiết bị đầu vào (như bàn phím, chuột) và các thiết bị lưu trữ liên tục do nền tảng cung cấp.

Hoạt động đảm bảo:

Người đánh giá sẽ thực hiện những hành động cụ thể theo từng nền tảng bên dưới và kiểm tra tài liệu hướng dẫn sử dụng để xác định quyền truy cập của ứng dụng đối với tài nguyên phần cứng. Người đánh giá sẽ bảo đảm rằng điều này là phù hợp với những lựa chọn đã được chỉ định. Người đánh giá sẽ phải xem xét lại các tài liệu do bên phát triển ứng dụng cung cấp và cho mỗi tài nguyên mà nó truy cập, xác định lý do tại sao yêu cầu truy cập.

Đối với BlackBerry: Người đánh giá sẽ phải cài đặt ứng dụng và chạy nó lần đầu. Người đánh giá sẽ phải xác nhận rằng lựa chọn sẽ thu thập tất cả các tài nguyên phần cứng mà nó muốn truy cập. Lưu ý: Nếu người dùng vào: App permissions > Settings > Security và Privacy > Application Permissions > Select application in question, nó sẽ liệt kê tài nguyên nào của nền tảng cần được duyệt/ từ chối và có thể thay đổi.

Đối với Android: Người đánh giá sẽ phải kiểm tra các quyền lúc cài đặt (từ Android 5.1 trở xuống) hoặc được phép truy cập (on-access) (từ Android 6.0 trở lên) đối với mỗi tài nguyên phần cứng mà ứng dụng dự định truy cập.

Đối với Windows: Đối với các Ứng dụng Nhiều nền tảng của Windows (Windows Universal Applications), người đánh giá sẽ phải kiểm tra tệp WMAppManifest.xml để biết danh sách các khả năng phần cứng được yêu cầu. Người đánh giá sẽ phải xác nhận rằng người dùng đã nhận thức được các khả năng phần cứng được yêu cầu khi ứng dụng được cài đặt lần đầu. Điều này bao gồm sự cho phép của ID_CAP_ISV_CAMERA, ID_CAP_LOCATION, ID_CAP NETWORKING, ID_CAP_MICROPHONE, ID_CAP_PROXIMITY, ... Danh sách hoàn chỉnh của Windows App permissions có thể xem tại: http://msdn.microsoft.com/en-US/library/windows/apps/jj206936.aspx

Đối với Các ứng dụng trên máy tính để bàn của Windows (Windows Desktop Applications), người đánh giá sẽ phải xác định danh sách các kho thông tin nhạy cảm được yêu cầu hoặc của phần mềm ứng dụng hoặc của tài liệu của nó.

Đối với iOS: Người đánh giá sẽ phải xác nhận hoặc là ứng dụng hoặc tài liệu cung cấp danh sách các tài nguyên phần cứng mà nó truy cập.

Đối với Linux: Người đánh giá sẽ phải xác nhận hoặc là ứng dụng hoặc tài liệu cung cấp danh sách các tài nguyên phần cứng mà nó truy cập.

...

...

...

Đối với Mac OS X: Người đánh giá sẽ phải xác nhận hoặc là ứng dụng hoặc tài liệu cung cấp danh sách các tài nguyên phần cứng mà nó truy cập.

FDP_DEC_EXT.1.2

Ứng dụng sẽ hạn chế truy cập đến [lựa chọn:

không có các kho thông tin nhạy cảm,

sổ địa chỉ,

lịch,

danh sách cuộc gọi,

các nhật ký hệ thống,

[Chỉ định: danh sách những kho thông tin nhạy cảm bổ sung]

...

...

...

Lưu ý khi thực hiện: Những kho chứa thông tin nhạy cảm được định nghĩa là những bộ thu thập dữ liệu nhạy cảm có thể được chia sẻ giữa một số ứng dụng, người dùng hay vai trò của người dùng, nhưng không phải tất cả chúng đều yêu cầu truy cập.

Hoạt động đảm bảo:

Người đánh giá sẽ phải thực hiện các hoạt động trên các nền tảng cụ thể như bên dưới và kiểm tra tài liệu hướng dẫn sử dụng để xác định quyền truy cập của ứng dụng vào các kho thông tin nhạy cảm. Người đánh giá sẽ phải đảm bảo rằng điều này phù hợp với các lựa chọn được chỉ định. Người đánh giá sẽ phải xem lại các tài liệu do nhà phát triển ứng dụng cung cấp và cho mỗi kho thông tin nhạy cảm mà nó truy cập, xác định lý do tại sao yêu cầu truy cập.

Đối với BlackBerry: Người đánh giá sẽ phải cài đặt ứng dụng và chạy nó lần đầu. Người đánh giá sẽ phải xác định những kho thông tin nhạy cảm mà cần yêu cầu truy cập.

Đối với Android: Người đánh giá sẽ phải kiểm tra các cho phép trong khi cài đặt (từ Android 5.1 trở xuống) hoặc được phép truy cập (on-access) (Android 6.0 trở lên) cho từng kho thông tin nhạy cảm mà ứng dụng định truy cập.

Đối với Windows: Đối với các Ứng dụng Nhiều nền tảng của Windows (Windows Universal Applications), người đánh giá sẽ phải kiểm tra tệp WMAppManifest.xml để biết danh sách các khả năng được yêu cầu. Người đánh giá sẽ phải xác nhận những kho thông tin được yêu cầu khi ứng dụng được cài đặt lần đầu. Điều này bao gồm các cho phép như ID_CAP_CONTACTS, ID_CAP_APPOINTMENTS, ID_CAP_MEDIALIB, ... Danh sách hoàn chỉnh của những cho phép của ứng dụng Windows có thể tham khảo: http://msdn.microsoft.com/en-US/library/windows/apps/jj206936.aspx

Đối với các Ứng dụng trên máy tính để bàn của Windows (Windows Desktop Applications), người đánh giá sẽ phải xác định danh sách các kho thông tin nhạy cảm mà nó truy cập hoặc của phần mềm ứng dụng hoặc của tài liệu của nó.

Đối với iOS: Người đánh giá sẽ phải xác nhận hoặc là phần mềm ứng dụng hoặc là tài liệu của nó cung cấp danh sách các kho thông tin nhạy cảm mà nó truy cập.

Đối với Linux: Người đánh giá sẽ phải xác nhận hoặc là phần mềm ứng dụng hoặc là tài liệu của nó cung cấp danh sách các kho thông tin nhạy cảm mà nó truy cập.

...

...

...

Đối với Mac OS X: Người đánh giá sẽ phải xác nhận hoặc là phần mềm ứng dụng hoặc là tài liệu của nó cung cấp danh sách các kho thông tin nhạy cảm mà nó truy cập.

9.1.2.2  FDP_NET_EXT.1 Các giao tiếp mạng

FDP_NET_EXT.1.1

Ứng dụng sẽ giới hạn giao tiếp mạng để [lựa chọn:

không giao tiếp mạng,

giao tiếp khởi tạo của người dùng cho [chỉ định: danh sách những tính năng mà người dùng có thể khởi tạo giao tiếp mạng],

phản hồi đến [chỉ định: danh sách giao tiếp khởi tạo từ xa],

[chỉ định: danh sách giao tiếp mạng được ứng dụng khởi tạo]

].

...

...

...

Hoạt động đảm bảo:

Người đánh giá sẽ phải thực hiện những kiểm tra sau:

- Kiểm tra 1: Người đánh giá sẽ phải chạy ứng dụng. Trong khi ứng dụng đang chạy, người đánh giá sẽ phải thu lưu lượng mạng, bỏ qua tất cả lưu lượng truy cập liên quan không phải của ứng dụng và xác nhận rằng bất kỳ giao tiếp mạng làm bằng chứng đều được ghi lại trong TSS hoặc do người dùng khởi tạo.

- Kiểm tra 2: Người đánh giá sẽ phải chạy ứng dụng. Sau khi ứng dụng được khởi tạo, người đánh giá sẽ phải quét cổng mạng để xác định xem có cổng nào đã mở bởi ứng dụng đã được trong ST cho lựa chọn thứ ba và các chỉ định của nó. Điều này bao gồm các giao thức dựa trên kết nối (như TCP, DCCP) cũng như những giao thức không kết nối (như UDP).

Đối với Android: Nếu chọn “không giao tiếp mạng”, người đánh giá sẽ phải bảo đảm rằng tập tin AndroidManifest.xml của ứng dụng không chứa tag <uses-permission> hoặc <uses-permission-sdk-23> chứa android:name=“android.permission.INTERNET”. Trong trường hợp này, không nhất thiết phải thực hiện Kiểm tra 1 và Kiểm tra 2 ở trên, vì nền tảng sẽ không cho phép ứng dụng thực hiện bất kỳ giao tiếp mạng nào.

9.1.2.3  FDP_DAR_EXT.1 Mã hóa dữ liệu ứng dụng nhạy cảm

FDP_PAR_EXT.1.1

Ứng dụng sẽ [lựa chọn:

sử dụng chức năng được nền tảng cung cấp để mã hóa dữ liệu nhạy cảm,

...

...

...

không lưu bất kỳ dữ liệu nhạy cảm nào

] trong bộ nhớ ổn định (non-volatile memory).

Lưu ý khi thực hiện: Nếu chọn thực hiện chức năng mã hóa dữ liệu nhạy cảm thì việc đánh giá sẽ được yêu cầu đối với Gói mở rộng cho hồ sơ bảo vệ phần mềm ứng dụng: Mã hóa tập tin [6]. Bất kỳ tập tin nào có tiềm năng chứa dữ liệu nhạy cảm (bao gồm cả các tập tin tạm thời) sẽ được bảo vệ. Ngoại lệ duy nhất là nếu người dùng chủ đích xuất dữ liệu nhạy cảm cho những tập tin không được bảo vệ.

Hoạt động đảm bảo:

Người đánh giá sẽ phải khám phá vị trí hệ thống tập tin mà ứng dụng có thể ghi dữ liệu. Người đánh giá sẽ phải chạy ứng dụng và thử lưu dữ liệu nhạy cảm. Người đánh giá sẽ phải kiểm tra lại những khu vực của hệ thống tập tin để ghi chú nơi dữ liệu được lưu trữ (nếu có), và xác định nó có được mã hóa hay không.

Nếu chọn không lưu bất kỳ dữ liệu nhạy cảm nào, người đánh giá sẽ phải kiểm tra TSS và bảo đảm rằng nó mô tả cách thức dữ liệu nhạy cảm không thể được ghi vào bộ nhớ ổn định. Người đánh giá cũng sẽ phải bảo đảm rằng điều này phù hợp với hệ thống tập tin đã kiểm tra ở trên.

Nếu chọn thực hiện chức năng mã hóa dữ liệu nhạy cảm thì việc đánh giá được yêu cầu đối với Gói mở rộng cho hồ sơ bảo vệ phần mềm ứng dụng: Mã hóa tập tin [6]. Người đánh giá sẽ phải đảm bảo đánh giá đang được thực hiện.

Nếu chọn sử dụng chức năng được nền tảng cung cấp, hoạt động đánh giá sẽ được thực hiện như các yêu cầu dưới đây, tùy theo từng nền tảng:

Đối với BlackBerry: Người đánh giá sẽ phải kiểm tra TSS và bảo đảm rằng nó mô tả cách thức ứng dụng sử dụng API Bảo vệ Nâng cao phần không hoạt động của Dữ liệu (Advanced Data at Rest Protection) và cách thức ứng dụng dùng tên vùng phù hợp để lưu trữ và bảo vệ mỗi tập tin dữ liệu.

...

...

...

Đối với Windows: Nền tảng Windows hiện tại không cung cấp dịch vụ mã hóa dữ liệu mà phụ thuộc vào việc kêu gọi các bên phát triển ứng dụng. Người đánh giá sẽ phải xác nhận rằng Hướng dẫn Người dùng Vận hành tạo ra nhu cầu để kích hoạt nền tảng mã hóa, như là BitLocker hoặc Encrypting File System (EFS), rõ ràng cho người dùng cuối.

Đối với iOS: Người đánh giá sẽ phải kiểm tra TSS và đảm bảo rằng nó mô tả cách thức ứng dụng dùng Complete Protection (Bảo vệ Hoàn chỉnh), Protected Unless Open (Được bảo vệ trừ phi mở), hay Protected Until First User Authentication Data Protection Class (Được bảo vệ cho đến khi người dùng đầu tiên xác thực lớp Bảo vệ Dữ liệu) cho mỗi tệp dữ liệu được lưu cục bộ.

Đối với Linux: Nền tảng Linux hiện tại không cung cấp dịch vụ mã hóa dữ liệu mà phụ thuộc vào việc kêu gọi các bên phát triển ứng dụng. Người đánh giá sẽ phải xác nhận rằng Hướng dẫn Người dùng Vận hành sẽ tạo ra nhu cầu để kích hoạt nền tảng mã hóa rõ ràng cho người dùng cuối.

Đối với Solaris: Nền tảng Solaris hiện tại không cung cấp dịch vụ mã hóa dữ liệu mà phụ thuộc vào việc kêu gọi các bên phát triển ứng dụng. Người đánh giá sẽ phải xác nhận rằng Hướng dẫn Người dùng Vận hành sẽ tạo ra nhu cầu để kích hoạt nền tảng mã hóa rõ ràng cho người dùng cuối.

Đối với Mac OS X: Nền tảng Mac OS X hiện tại không cung cấp dịch vụ mã hóa dữ liệu mà phụ thuộc vào việc kêu gọi các bên phát triển ứng dụng. Người đánh giá sẽ phải xác nhận rằng Hướng dẫn Người dùng Vận hành sẽ tạo ra nhu cầu để kích hoạt nền tảng mã hóa rõ ràng cho người dùng cuối.

9.1.3  Quản lý bảo mật (FMT)

9.1.3.1  FMT_MEC_EXT.1 Cơ chế hỗ trợ cấu hình

FMT_MEC_EXT.1.1

Ứng dụng sẽ gọi các cơ chế được nhà cung cấp nền tảng đề xuất để lưu và thiết lập các tùy chọn của cấu hình.

...

...

...

Hoạt động đảm bảo:

Người đánh giá sẽ phải xem lại TSS để xác định các tùy chọn cấu hình của ứng dụng (ví dụ các thiết lập) và xác định liệu rằng các điều này được lưu và thiết lập sử dụng các cơ chế được thiết lập bởi nền tảng. Tối thiểu TSS sẽ phải liệt kê các thiết lập liên quan đến bất kỳ SFR nào và bất kỳ thiết lập nào được chỉ định trong hướng dẫn vận hành để đáp ứng SFR. Phương pháp làm này thay đổi theo từng nền tảng khác nhau.

Đối với Blackberry: Người đánh giá sẽ phải chạy ứng dụng và tạo các thay đổi có liên quan bảo mật đối với cấu hình. Người đánh giá sẽ phải kiểm tra rằng ít nhất một tập tin trong thư mục của ứng dụng đang hoạt động đã được sửa đổi để phản ánh sự thay đổi đã được thực hiện.

Đối với Android: Người đánh giá sẽ phải chạy ứng dụng và tạo các thay đổi có liên quan bảo mật đối với cấu hình. Người đánh giá sẽ phải kiểm tra xem có ít nhất một tập tin XML tại vị trí /data/data/package/shared_prefs/ phản ánh những thay đổi được thực hiện cho cấu hình để xác nhận rằng ứng dụng đã dùng các lớp SharedPreferences và/hoặc PreferenceActivity cho việc lưu dữ liệu cấu hình, trong đó gói là gói Java của ứng dụng.

Đối với Windows: Người đánh giá sẽ phải xác định và xác nhận rằng các Ứng dụng Nhiều nền tảng của Windows (Windows Universal Applications) sử dụng không gian tên (namespace) Windows.UI.ApplicationSettings hoặc IsolatedStorageSettings cho việc lưu trữ những cài đặt cụ thể của ứng dụng. Đối với các ứng dụng cho Máy tính bàn Truyền thống, người đánh giá sẽ phải chạy ứng dụng trong khi giám sát nó với công cụ ProcMon của SysInternal và tạo các thay đổi trong cấu hình của nó. Người đánh giá sẽ phải xác nhận rằng các nhật ký (log) của ProcMon cho thấy những thay đổi tương ứng Registry của Windows.

Đối với iOS: Người đánh giá sẽ phải xác nhận rằng ứng dụng sử dụng user defaults system hoặc key-value store để lưu trữ mọi thiếp lập.

Đối với Linux: Người đánh giá sẽ phải chạy ứng dụng trong khi giám sát nó với tiện ích strace. Người đánh giá sẽ phải tạo ra những thay đổi liên quan bảo mật đến cấu hình của nó. Người đánh giá sẽ phải xác nhận rằng các nhật ký (log) của strace thay đổi tương ứng với các tệp cấu hình ở trong /etc (đối với cấu hình hệ thống cụ thể) hoặc trong thư mục chính (home) của người dùng (đối với cấu hình của người dùng cụ thể).

Đối với Solaris: Người đánh giá sẽ phải chạy ứng dụng trong khi giám sát nó với tiện ích dtrace. Người đánh giá sẽ phải tạo ra những thay đổi liên quan bảo mật đến cấu hình của nó. Người đánh giá sẽ phải xác nhận rằng các nhật ký (log) của dtrace thay đổi tương ứng với các tập tin cấu hình ở trong /etc (đối với cấu hình hệ thống cụ thể) hoặc trong thư mục chính (home) của người dùng (đối với cấu hình của người dùng cụ thể).

Đối với Mac OS X: Người đánh giá sẽ phải xác nhận rằng ứng dụng lưu và lấy các thiết lập sử dụng lớp NSUserDefaults.

...

...

...

FMT_CFG_EXT.1.1

Ứng dụng sẽ cung cấp chỉ những chức năng đủ để thiết lập các chứng chỉ mới khi được cấu hình với những chứng chỉ mặc định hoặc không chứng chỉ nào.

Lưu ý khi thực hiện: Các chứng chỉ mặc định là những chứng chỉ (ví dụ mật khẩu, các khóa) tự động (không có tương tác của người dùng) được tải lên nền tảng trong khi cài đặt ứng dụng. Các chứng chỉ được tạo trong khi cài đặt bằng cách sử dụng những yêu cầu đặt ra trong FCS_RBG_EXT.1 (9.1.1) không được xem là các chứng chỉ mặc định.

Hoạt động đảm bảo:

Người đánh giá sẽ phải kiểm tra TSS để xác định ứng dụng có yêu cầu bất cứ dạng chứng chỉ nào không và ứng dụng có cài đặt với các chứng chỉ mặc định không. Nếu ứng dụng có dùng bất kỳ chứng chỉ mặc định nào, người đánh giá sẽ phải thực hiện các kiểm tra sau:

- Kiểm tra 1: Người đánh giá sẽ phải cài đặt và chạy ứng dụng mà không tạo hoặc tải những chứng chỉ mới và xác nhận rằng chỉ các chức năng tối thiểu của ứng dụng được yêu cầu để thiết lập các chứng chỉ mới là có sẵn.

- Kiểm tra 2: Người đánh giá sẽ phải thử xóa tất cả các chứng chỉ và xác nhận rằng chỉ các chức năng tối thiểu của ứng dụng được yêu cầu để thiết lập các chứng chỉ mới là có sẵn.

- Kiểm tra 3: Người đánh giá sẽ phải chạy ứng dụng, thiết lập những chứng chỉ mới và xác nhận rằng những chứng chỉ mặc định ban đầu không còn được quyền truy cập vào ứng dụng.

FMT_CFG_EXT.1.2

...

...

...

Lưu ý khi thực hiện: Các yêu cầu chính xác về quyền truy cập tập tin thay đổi tùy theo mỗi nền tảng nhưng mục đích chung là một ranh giới tin cậy sẽ bảo vệ ứng dụng và dữ liệu của nó.

Hoạt động đảm bảo:

Người đánh giá sẽ phải cài đặt và chạy ứng dụng. Người đánh giá sẽ phải kiểm tra hệ thống tập tin của nền tảng (cho phạm vi có thể mở rộng) cho bất kỳ tập tin nào do ứng dụng tạo ra và đảm bảo rằng các quyền của chúng là đủ để bảo vệ chúng. Phương pháp thực hiện sẽ khác nhau đối với từng nền tảng.

Đối với Blackberry: Người đánh giá sẽ phải chạy ls -alR \ grep -E '^……. (r | -w | --x) ' bên trong các thư mục dữ liệu của ứng dụng để đảm bảo tất cả các tập tin không được truy cập đại trà (đọc, ghi, hay thi hành). Lệnh sẽ không in cho bất cứ tập tin nào. Người đánh giá cũng sẽ phải xác nhận rằng không có dữ liệu nhạy cảm nào được ghi vào các bộ lưu trữ bên ngoài, dễ bị đọc hoặc sửa đổi bởi ứng dụng khác.

Đối với Android: Người đánh giá sẽ phải chạy ls -alR \ grep -E '^……. (r | -w | --x) ' bên trong các thư mục dữ liệu của ứng dụng để đảm bảo tất cả các tập tin không được truy cập đại trà (đọc, ghi, hay thi hành). Lệnh sẽ không in cho bất cứ tập tin nào. Người đánh giá cũng sẽ phải xác nhận rằng không có dữ liệu nhạy cảm nào được ghi vào các bộ lưu trữ bên ngoài, dễ bị đọc hoặc thay đổi bởi ứng dụng khác có chứa các quyền READ_EXTERNAL_STORAGE và/ hoặc WRITE_EXTERNAL_STORAGE.

Đối với Windows: Người đánh giá sẽ phải chạy các công cụ Process Monitor và Access Check trong bộ SysInternals, (hoặc công cụ có khả năng tương đương như icacls.exe) cho các ứng dụng trên máy tính để bàn truyền thống để xác nhận rằng các tập tin được ghi vào đĩa trong khi cài đặt ứng dụng có quyền đúng với tập tin, rằng một người dùng chuẩn không thể sửa đổi ứng dụng hoặc các tệp dữ liệu của nó. Đối với các Ứng dụng Nhiều nền tảng của Windows (Windows Universal Applications), người đánh giá sẽ phải xem xét yêu cầu được đáp ứng bởi các sandbox chứa các ứng dụng (AppContainer sandbox).

Đối với iOS: Người đánh giá sẽ phải xác định xem ứng dụng nếu ứng dụng có thúc đẩy Lớp Bảo vệ Dữ liệu (Data Protection Class) phù hợp cho mỗi tệp dữ liệu được lưu cục bộ hay không.

Đối với Linux: Người đánh giá sẽ phải chạy lệnh find . -perm /007 bên trong các thư mục dữ liệu của ứng dụng để đảm bảo tất cả các tập tin không được truy cập đại trà (đọc, ghi, hay thi hành). Lệnh sẽ không in cho bất cứ tập tin nào.

Đối với Solaris: Người đánh giá sẽ phải chạy lệnh find . \( -perm -001 -o -perm -002 -o -perm -004 \) bên trong các thư mục dữ liệu của ứng dụng để đảm bảo tất cả các tập tin không được truy cập đại trà (đọc, ghi, hay thi hành). Lệnh sẽ không in cho bất cứ tập tin nào.

...

...

...

9.1.3.3  FMT_SMF.1 Đặc tính của các chức năng quản trị

FMT_SMF.1.1

TSF sẽ có khả năng thực hiện những chức năng quản trị sau [lựa chọn:

không có các chức năng quản trị,

bật / tắt việc truyền tải bất kỳ thông tin nào mô tả phần cứng, phần mềm hoặc cấu hình của hệ thống,

bật /tắt việc truyền tải bất kỳ PII nào,

bật/ tắt việc truyền tải bất kỳ thông tin trạng thái nào của ứng dụng (ví dụ crashdump),

bật / tắt tính năng sao lưu mạng đến [chỉ định: danh sách các hệ thống sao lưu cloud của doanh nghiệp hoặc thương mại]

[chỉ định: danh sách các tính năng quản lý khác do TSF cung cấp]

...

...

...

Lưu ý khi thực hiện: Yêu cầu này quy định rằng một ứng dụng cần cung cấp khả năng bật / tắt chỉ những chức năng mà nó thực hiện. Ứng dụng không chịu trách nhiệm kiểm soát hành vi của nền tảng hoặc các ứng dụng khác.

Hoạt động đảm bảo:

Người đánh giá sẽ phải xác nhận rằng mọi chức năng quản trị được ủy quyền của PP là được mô tả trong hướng dẫn vận hành và mô tả sẽ chứa thông tin cần thiết để thực hiện các nhiệm vụ quản trị liên quan đến chức năng quản lý. Người đánh giá cần phải kiểm tra khả năng của ứng dụng để cung cấp các chức năng quản trị bởi việc cấu hình ứng dụng và kiểm tra từng lựa chọn bên trên. Người đánh giá được kỳ vọng sẽ kiểm tra các chức năng này bằng mọi cách, trong đó tình trạng cấu hình của ST và tài liệu hướng dẫn có thể quản lý được.

9.1.4  Sự riêng tư

FPR_ANO_EXT.1 Người dùng chấp thuận cho việc truyền thông tin nhận dạng cá nhân

FPR_ANO_EXT.1.1

Ứng dụng sẽ [lựa chọn:

không truyền PII qua mạng,

yêu cầu người dùng xác nhận trước khi thực thi [chỉ định: danh sách của các chức năng truyền PII qua mạng]

...

...

...

Lưu ý khi thực hiện: Yêu cầu này áp dụng chỉ với PII được ứng dụng yêu cầu cụ thể; nó không áp dụng nếu người dùng tự nguyện cung cấp PII mà không cần nhắc từ ứng dụng vào một trường dữ liệu chung (hoặc không phù hợp). Một hộp thoại thông báo ý định gởi PII sẽ phải được hiển thị cho người dùng vào thời điểm ứng dụng bắt đầu đáp ứng yêu cầu này.

Hoạt động đảm bảo:

Người đánh giá sẽ phải kiểm tra tài liệu TSS để xác định tính năng nào trong ứng dụng mà PII có thể được truyền và thực hiện theo kiểm tra bên dưới.

- Kiểm tra 1: người đánh giá sẽ phải chạy ứng dụng và thực hiện chức năng có trách nhiệm truyền PII và xác nhận rằng chấp thuận của người dùng phải được yêu cầu trước khi truyền PII.

9.1.5  Bảo vệ của TSF (FPT)

9.1.5.1  FPT_API_EXT.1 Sử dụng các dịch vụ và API được hỗ trợ

FPT_API_EXT.1.1

Ứng dụng sẽ chỉ dùng các API của nền tảng đã tài liệu hóa.

Lưu ý khi thực hiện: Định nghĩa của tài liệu hóa có thể khác nhau tùy thuộc vào việc ứng dụng được cung cấp bởi một bên thứ ba (bên dựa vào các API của nền tảng được tài liệu hóa) hoặc bởi một nhà cung cấp nền tảng - người có thể đảm bảo hỗ trợ cho các API nền tảng.

...

...

...

Người đánh giá sẽ phải xác minh rằng TSS liệt kê các API nền tảng được sử dụng trong ứng dụng. Người đánh giá sẽ phải so sánh danh sách với các API được hỗ trợ (có sẵn thông qua các tài khoản của nhà phát triển, các nhóm phát triển nền tảng) và đảm bảo rằng tất cả các API được liệt kê trong TSS đều được hỗ trợ.

9.1.5.2  FPT_AEX_EXT.1 Khả năng chống khai thác

FPT_AEX_EXT-1.1

Ứng dụng sẽ không yêu cầu ánh xạ bộ nhớ tại một địa chỉ cụ thể ngoại trừ cho [chỉ định: danh sách của các ngoại lệ rõ ràng].

Lưu ý khi thực hiện: Yêu cầu việc ánh xạ bộ nhớ ở một địa chỉ rõ ràng sẽ thay đổi ASLR (address space layout randomization - bố trí không gian địa chỉ ngẫu nhiên).

Hoạt động đảm bảo:

Người đánh giá sẽ phải đảm bảo rằng TSS mô tả các cờ biên dịch được dùng để cho phép ASLR khi ứng dụng được biên dịch. Người đánh giá sẽ phải thực hiện hoặc phân tích tĩnh hoặc phân tích động để xác định rằng không có các ánh xạ bộ nhớ được đặt ở một địa chỉ rõ ràng và nhất quán. Phương pháp làm sẽ khác nhau cho mỗi nền tảng.

Đối với Blackberry: Người đánh giá sẽ phải chạy ứng dụng giống nhau trên hai hệ thống BlackBerry khác nhau và chạy một công cụ để liệt kê các địa chỉ ánh xạ bộ nhớ cho ứng dụng. Người đánh giá sau đó sẽ phải xác minh hai trường hợp khác nhau chia sẻ các vị trí không tương ứng nhau.

Đối với Android: Người đánh giá sẽ phải chạy ứng dụng giống nhau trên hai hệ thống Android khác nhau. Kết nối qua ADB và kiểm tra /proc/PID/maps. Đảm bảo rằng hai trường hợp khác nhau sẽ chia sẻ các vị trí không tương ứng nhau.

...

...

...

Đối với iOS: Người đánh giá sẽ phải thực hiện phân tích tĩnh để tìm các lệnh gọi mmap (hoặc API gọi mmap), và đảm bảo rằng không có đối số nào cung cấp yêu cầu đó ánh xạ ở một địa chỉ cố định.

Đối với Linux: Người đánh giá sẽ phải chạy ứng dụng giống nhau trên hai hệ thống Linux khác nhau. Người đánh giá sau đó sẽ phải so sánh bản đồ bộ nhớ của chúng sử dụng pmap -x PID để đảm bảo hai trường hợp khác nhau sẽ chia sẻ các vị trí không tương ứng nhau.

Đối với Solaris: Người đánh giá sẽ phải chạy ứng dụng giống nhau trên hai hệ thống Solaris khác nhau. Người đánh giá sau đó sẽ phải so sánh bản đồ bộ nhớ của chúng sử dụng pmap -x PID để đảm bảo hai trường hợp khác nhau sẽ chia sẻ các vị trí không tương ứng nhau.

Đối với Mac OS X: Người đánh giá sẽ phải chạy ứng dụng giống nhau trên hai hệ thống Mac OS X khác nhau. Người đánh giá sau đó sẽ phải so sánh bản đồ bộ nhớ của chúng sử dụng vmmap PID để đảm bảo hai trường hợp khác nhau sẽ chia sẻ các vị trí không tương ứng nhau.

FPT_AEX_EXT.1.2

Ứng dụng sẽ [lựa chọn:

không định vị bất cứ vùng nào của bộ nhớ với cả hai quyền ghi và thực thi,

định vị các vùng bộ nhớ với quyền ghi và đọc chỉ cho [chỉ định: danh sách của các chức năng thực hiện biên dịch đúng thời điểm]

].

...

...

...

Hoạt động đảm bảo:

Người đánh giá sẽ phải xác nhận rằng không có các yêu cầu lập bản đồ bộ nhớ nào được tạo với quyền ghi và thực thi. Phương pháp làm sẽ khác nhau với mỗi nền tảng.

Đối với Blackberry: Người đánh giá sẽ phải thực hiện phân tích tĩnh trên ứng dụng để xác thực rằng

- mmap không bao giờ được gọi với cả hai quyền PROT_WRITE và PROT_EXEC, và

- mprotect không bao giờ được gọi.

Đối với Android: Người đánh giá sẽ phải thực hiện phân tích tĩnh trên ứng dụng để xác thực rằng

- mmap không bao giờ được gọi với cả hai quyền PROT_WRITE và PROT_EXEC, và

- mprotect không bao giờ được gọi.

Đối với Windows: Người đánh giá sẽ phải dùng một công cụ như Bộ phân tích Nhị phân BinScope của Microsoft để xác nhận rằng ứng dụng qua được NXCheck. Người đánh giá có thể cũng phải đảm bảo rằng cờ /NXCOMPAT được dùng trong khi biên dịch để xác thực rằng các bảo vệ của DEP được bật cho ứng dụng.

...

...

...

Đối với Linux: Người đánh giá sẽ phải thực hiện phân tích tĩnh trên ứng dụng để xác thực rằng cả

- mmap không bao giờ được gọi với cả hai quyền PROT_WRITE và PROT_EXEC, và

- mprotect không bao giờ được gọi với quyền PROT_EXEC.

Đối với Solaris: Người đánh giá sẽ phải thực hiện phân tích tĩnh trên ứng dụng để xác thực rằng cả

- mmap không bao giờ được gọi với cả hai quyền PROT_WRITE và PROT_EXEC, và

- mprotect không bao giờ được gọi với quyền PROT_EXEC.

Đối với Mac OS X: Người đánh giá sẽ phải thực hiện phân tích tĩnh trên ứng dụng để xác thực rằng mprotect không bao giờ được gọi với quyền PROT_EXEC.

FPT_AEX_EXT.1.3

Ứng dụng sẽ phải tương thích với các chức năng an toàn của nền tảng cung cấp.

...

...

...

Hoạt động đảm bảo:

Người đánh giá sẽ phải cấu hình nền tảng theo cách được chỉ định và thực hiện cho các phép thử quy định sau:

Đối với Blackberry: Người đánh giá sẽ phải đảm bảo rằng ứng dụng có thể chạy thành công trên phiên bản hệ điều hành của BlackBerry mới nhất.

Đối với Android: Người đánh giá sẽ phải đảm bảo rằng ứng dụng có thể chạy thành công trên phiên bản Android mới nhất.

Đối với Windows: Cho cả máy tính để bàn truyền thống hoặc Windows Universal Applications, người đánh giá sẽ phải cấu hình phiên bản mới mất của Enhanced Mitigation Experience Toolkit (EMET) của Microsoft để bảo vệ ứng dụng. Người đánh giá sau đó chạy ứng dụng và xác nhận rằng ứng dụng không bị lỗi khi được EMET bảo vệ.

Đối với iOS: Người đánh giá sẽ phải đảm bảo rằng ứng dụng có thể chạy thành công trên phiên bản iOS mới nhất.

Đối với Linux: Người đánh giá sẽ phải đảm bảo rằng ứng dụng có thể chạy thành công trên hệ thống cho phép và thi hành SELinux.

Đối với Solaris: Người đánh giá sẽ phải đảm bảo rằng ứng dụng có thể chạy với Solaris Trusted Extensions được bật và đang thi hành.

Đối với Mac OS X: Người đánh giá sẽ phải đảm bảo rằng ứng dụng có thể chạy thành công trên phiên bản OS X mới nhất.

...

...

...

Ứng dụng sẽ không ghi các tập tin mà người dùng có thể thay đổi vào thư mục chứa các tập tin thực thi, trừ khi được người dùng hướng dẫn làm như vậy.

Lưu ý khi thực hiện: Các tập tin thực thi và tập tin người dùng có thể thay đổi sẽ không cùng một thư mục cha nhưng có thể chia sẻ cùng thư mục trên của thư mục cha.

Hoạt động đảm bảo:

Người đánh giá sẽ phải chạy ứng dụng và xác định xem nơi ghi các tập tin của nó. Đối với các tập tin mà người dùng không chọn đích lưu, người đánh giá sẽ phải kiểm tra liệu thư mục đích có chứa các tập tin thực thi hay không. Việc này sẽ khác nhau cho từng nền tảng.

Đối với Blackberry: Người đánh giá sẽ phải xem xét yêu cầu đã đáp ứng chưa vì nền tảng buộc các các ứng dụng phải ghi tất cả dữ liệu vào trong thư mục làm việc của ứng dụng (sandbox).

Đối với Android: Người đánh giá sẽ phải chạy chương trình, bắt chước cách dùng thông thường, và lưu ý nơi lưu các tập tin. Người đánh giá sẽ phải đảm bảo rằng không có tập tin thực thi nào được lưu trong /data/data/package/, vị trí của gói Java của ứng dụng.

Đối với Windows: Đối với các Ứng dụng Nhiều nền tảng của Windows (Windows Universal Applications), người đánh giá sẽ phải xem xét yêu cầu đã đáp ứng chưa vì nền tảng buộc các ứng dụng phải ghi tất cả dữ liệu trong thư mục làm việc của ứng dụng (sandbox). Đối với các Ứng dụng cho máy tính bàn của Windows (Windows Desktop Application), người đánh giá sẽ phải chạy chương trình, bắt chước cách sử dụng bình thường và chú ý nơi lưu các tập tin. Người đánh giá sẽ phải đảm bảo rằng không có tập tin thực thi nào được lưu cùng thư mục mà ứng dụng đã ghi và không có tập tin dữ liệu nào trong thư mục cài đặt của ứng dụng.

Đối với iOS: Người đánh giá sẽ phải xem xét yêu cầu đã đáp ứng chưa vì nền tảng này buộc các ứng dụng phải ghi tất cả dữ liệu trong thư mục làm việc của ứng dụng (sandbox).

Đối với Linux: Người đánh giá sẽ phải chạy chương trình, bắt chước cách sử dụng bình thường và chú ý nơi lưu các tập tin. Người đánh giá sẽ phải đảm bảo rằng không có tập tin thực thi nào được lưu cùng thư mục mà ứng dụng đã ghi.

...

...

...

Đối với Mac OS X: Người đánh giá sẽ phải chạy chương trình, bắt chước cách sử dụng bình thường và chú ý nơi lưu các tập tin. Người đánh giá sẽ phải đảm bảo rằng không có tập tin thực thi nào được lưu cùng thư mục mà ứng dụng đã ghi.

FPT_AEX_EXT.1.5

Ứng dụng sẽ phải được biên dịch với cơ chế bảo vệ tràn bộ đệm dựa trên stack (stack-based buffer overflow protection) được bật.

Hoạt động đảm bảo:

Người đánh giá sẽ phải đảm bảo rằng phiên TSS của ST sẽ mô tả cờ biên dịch được dùng để bật cơ chế bảo vệ tràn bộ đệm dựa trên stack trong ứng dụng. Người đánh giá sẽ phải thực hiện hiện phân tích tĩnh để xác nhận rằng có cơ chế bảo vệ tràn bộ đệm dựa trên stack. Phương pháp thực hiện là khác nhau với mỗi nền tảng:

Đối với Blackberry: Người đánh giá sẽ phải đảm bảo rằng ứng dụng có sử dụng các cờ -fstack-protector-strong hoặc -fstack-protector-all. Cờ -fstack-protector-all được ưa chuộng hơn nhưng cờ -fstack-protector-strong cũng có thể chấp nhận được.

Đối với Android: Ứng dụng toàn Java chạy trong máy Java và không cần cơ chế bảo vệ stack truyền thống. Với các ứng dụng sử dụng Java Native Interface (JNI), người đánh giá phải đảm bảo rằng có sử dụng các cờ -fstack-protector-strong hoặc -fstack-protector-all. Cờ -fstack-protector-all được ưa chuộng hơn nhưng cờ -fstack-protector-strong cũng có thể chấp nhận được.

Đối với Windows: Người đánh giá sẽ phải xem xét TSS và xác nhận rằng cờ /GS được dùng trong khi biên dịch. Người đánh giá sẽ phải chạy một công cụ như BinScope để xác nhận việc dùng đúng của /GS.

Đối với iOS: Nếu ứng dụng dùng GCC hoặc Xcode để biên dịch, người đánh giá sẽ phải đảm bảo rằng có sử dụng các cờ -fstack-protector-strong hoặc -fstack-protector-all. Cờ -fstack-protector-all được ưa chuộng hơn nhưng cờ -fstack-protector-strong cũng có thể chấp nhận được. Nếu ứng dụng sử dụng các trình biên dịch khác để xây dựng thì người đánh giá sẽ phải xác định rằng cơ chế bảo vệ stack phù hợp phải được dùng trong cả tiến trình xây dựng.

...

...

...

Đối với Solaris: Nếu ứng dụng dùng GCC để biên dịch, người đánh giá sẽ phải đảm bảo rằng có sử dụng các cờ -fstack-protector-strong hoặc -fstack-protector-all. Cờ -fstack-protector-all được ưa chuộng hơn nhưng cờ -fstack-protector-strong cũng có thể chấp nhận được. Nếu ứng dụng sử dụng clang để xây dựng, nó phải được biên dịch và kết nối với cờ -fsanitize=address. Nếu ứng dụng sử dụng các trình biên dịch khác để xây dựng thì người đánh giá sẽ phải xác định rằng cơ chế bảo vệ stack phù hợp phải được dùng trong cả tiến trình xây dựng.

Đối với Mac OS X: Nếu ứng dụng dùng GCC hoặc Xcode để biên dịch, người đánh giá sẽ phải đảm bảo rằng có sử dụng các cờ -fstack-protector-strong hoặc -fstack-protector-all. Cờ - fstack-protector-all được ưa chuộng hơn nhưng cờ -fstack-protector-strong cũng có thể chấp nhận được. Nếu ứng dụng sử dụng các trình biên dịch khác để xây dựng thì người đánh giá sẽ phải xác định rằng cơ chế bảo vệ stack phù hợp phải được dùng trong cả tiến trình xây dựng.

9.1.5.3  FPT_TUD_EXT.1 Toàn vẹn đối với Cài đặt và Cập nhật

FPT_TUD_EXT.1.1

Ứng dụng sẽ [lựa chọn: cung cấp khả năng, thúc đẩy nền tảng] để kiểm tra các cập nhật và vá lỗi cho phần mềm ứng dụng.

Lưu ý khi thực hiện: yêu cầu này là về khả năng “kiểm tra” các các cập nhật. Việc cài đặt thực tế của một vài cập nhật nên được thực hiện bởi nền tảng. Yêu cầu này nhằm đảm bảo rằng ứng dụng có thể kiểm tra các bản cập nhật được cung cấp bởi nhà phát triển, do các cập nhật cung cấp từ nguồn khác có thể chứa mã độc.

Hoạt động đảm bảo:

Người đánh giá sẽ phải kiểm tra một cập nhật sử dụng thủ tục được mô tả trong tài liệu và xác thực rằng ứng dụng không phát hành lỗi. Nếu nó được cập nhật hoặc nó báo cáo rằng không có sẵn bản cập nhật thì yêu cầu này được xem như đáp ứng.

FPT_TUD_EXT.1.2

...

...

...

Hoạt động đảm bảo:

Người đánh giá sẽ phải xác nhận rằng các cập nhật của ứng dụng được phân phối trong định dạng được nền tảng hỗ trợ. Việc này sẽ khác nhau cho từng nền tảng:

Đối với BlackBerry: Người đánh giá sẽ phải đảm bảo rằng ứng dụng được đóng gói theo khuôn dạng của Blackberry (BAR).

Đối với Android: Người đánh giá sẽ phải đảm bảo rằng ứng dụng được đóng gói theo dạng gói ứng dụng của Android APK (Android application package).

Đối với Windows: Người đánh giá sẽ phải đảm bảo rằng ứng dụng được đóng gói theo định dạng bộ cài đặt Windows (Windows Installer) (.MSI) hoặc định dạng Phần mềm Ứng dụng của Windows (Windows Application Software) (.EXE) được ký bởi tiến trình Chứng thực của Microsoft (Microsoft Authenticode), hoặc gói Ứng dụng Đa nền tảng của Windows (Windows Universal Application) (.APPX). Tham khảo chi tiết về ký chứng thực tại https://msdn.microsoft.com/en-us/library/ms537364(v=vs.85).aspx.

Đối với iOS: Người đánh giá sẽ phải đảm bảo rằng ứng dụng được đóng gói theo dạng IPA.

Đối với Linux: Người đánh giá sẽ phải đảm bảo rằng ứng dụng được đóng gói theo dạng hạ tầng quản lý gói của phân phối được chọn. Ví dụ, ứng dụng chạy trong Red Hat và các biến thể của Red Hat nên được đóng gói theo dạng RPM. Ứng dụng chạy trên Debian và các biến thể của Debian nên được đóng gói theo dạng deb.

Đối với Solaris: Người đánh giá sẽ phải đảm bảo rằng ứng dụng được đóng gói theo dạng PKG.

Đối với Mac OS X: Người đánh giá sẽ phải đảm bảo rằng ứng dụng được đóng gói theo dạng DMG, PKG, hoặc MPKG.

...

...

...

Ứng dụng sẽ được đóng gói sao cho khi tiến hành gỡ bỏ, ứng dụng sẽ được xóa hoàn toàn, ngoại trừ các thiết lập cấu hình, các tập tin xuất ra, và các nhật ký sự kiện.

Lưu ý khi thực hiện: Ứng dụng được đóng gói với ảnh của hệ thống/phần sụn không phải là đối tượng của yêu cầu này nếu người dùng không thể gỡ bỏ ứng dụng bằng các phương tiện của hệ điều hành cung cấp.

Hoạt động đảm bảo:

Người đánh giá sẽ phải ghi lại đường dẫn của mỗi tập tin trong toàn bộ hệ thống tập tin trước khi cài đặt ứng dụng, tiếp đến cài đặt và chạy ứng dụng. Người đánh giá sau đó sẽ phải gỡ bỏ ứng dụng, và so sánh kết quả hệ thống tập tin với ghi nhận ban đầu để xác nhận rằng không có tập tin nào được thêm vào hệ thống tập tin, ngoại trừ các tập tin cấu hình, các tệp xuất ra hoặc các tập tin kiểm tra/nhật ký.

FPT_TUD_EXT.1.4

Ứng dụng sẽ không tải về, thay đổi, thay thế hay cập nhật mã nhị phân riêng của nó.

Lưu ý khi thực hiện: yêu cầu này áp dụng cho mã của ứng dụng; nó không áp dụng cho công nghệ mã di động được thiết kế để tải và thi hành bởi ứng dụng.

Hoạt động đảm bảo:

Người đánh giá sẽ phải xác nhận rằng các tập tin thi hành của ứng dụng không được thay đổi bởi ứng dụng. Người đánh giá sẽ phải hoàn thành những kiểm tra sau:

...

...

...

Người đánh giá sau đó sẽ phải so sánh mỗi tập tin thi hành hoặc là với các mã băm đã lưu hoặc với các bản sao của tệp. Người đánh giá sẽ phải xác nhận rằng chúng là như nhau.

FPT_TUD_EXT.1.5

Ứng dụng sẽ [lựa chọn, ít nhất 1 trong số: cung cấp khả năng, thúc đẩy nền tảng] để hỏi phiên bản hiện tại của phần mềm ứng dụng.

Hoạt động đảm bảo:

Người đánh giá sẽ phải hỏi ứng dụng về phiên bản hiện tại của phần mềm theo hướng dẫn người dùng vận hành (AGD_OPE.1) và sẽ phải xác thực rằng phiên bản hiện tại có phù hợp với phiên bản được kiểm chứng và cài đặt không.

FPT_TUP_EXT.1.6

Gói cài đặt ứng dụng và các cập nhật của nó sẽ được ký số sao cho nền tảng có thể xác thực bằng mật mã trước khi cài đặt.

Lưu ý khi thực hiện: Chi tiết của việc xác thực các gói cài đặt và các cập nhật sẽ liên quan đến các yêu cầu trên nền tảng (không phải ứng dụng), nên chúng không được chỉ rõ ở đây.

Hoạt động đảm bảo:

...

...

...

9.1.5.4  FPT_LIB_EXT.1 Sử dụng thư viện bên thứ ba

FPT_LIB_EXT.1.1

Ứng dụng sẽ phải được đóng gói chỉ với [chỉ định: danh sách các thư viện của bên thứ ba].

Lưu ý khi thực hiện: Mục đích của yêu cầu này là để người đánh giá phát hiện và ghi nhận liệu ứng dụng đó có chứa các thư viện không cần thiết hoặc không mong đợi của bên thứ ba hay không. Điều này bao gồm các thư viện phần mềm quảng cáo có thể gây ra mối nguy hại riêng tư, cũng như đảm bảo tài liệu của các thư viện đó trong trường hợp các lỗ hổng được phát hiện sau này.

Hoạt động đảm bảo:

Người đánh giá sẽ phải cài đặt ứng dụng và khảo sát thư mục cài đặt đối với thư viện động. Người đánh giá sẽ phải xác nhận rằng các thư viện được tìm thấy đó có được đóng gói cùng hoặc được sử dụng bởi ứng dụng là bị hạn chế.

9.1.6  Đường dẫn / Kênh Tin cậy (FTP)

9.1.6.1  FTP_DIT_EXT.1 Bảo vệ dữ liệu khi truyền

FTP_DIT_EXT.1.1

...

...

...

không truyền bất cứ dữ liệu nào,

không truyền bất cứ dữ liệu nhạy cảm nào,

mã hóa tất cả dữ liệu nhạy cảm được truyền với [lựa chọn, ít nhất một trong số: HTTPS, TLS, DTLS, SSH phù hợp với Gói Mở rộng cho Shell An toàn (tham khảo [7])],

mã hóa tất cả các dữ liệu được truyền với [lựa chọn, ít nhất một trong số: HTTPS, TLS, DTLS, SSH]

] giữa chính nó và một sản phẩm IT tin cậy khác.

Lưu ý khi thực hiện: Các gói mở rộng có thể ghi đè yêu cầu này để cung cấp các giao thức khác. Mã hóa là không bắt buộc cho các ứng dụng truyền dữ liệu không nhạy cảm.

Nếu TLS được chọn thì đánh giá các yếu tố từ FCS_TLSC_EXT.1 (Điều B.9 Phụ lục B) là bắt buộc.

Nếu HTTPS được chọn thì đánh giá các yếu tố từ FCS_HTTPS_EXT.1 (Điều B.13 Phụ lục B) là bắt buộc.

Nếu DTLS được chọn thì đánh giá các yếu tố từ FCS_DTLS_EXT.1 (Điều B.12 Phụ lục B) là bắt buộc.

...

...

...

Hoạt động đảm bảo:

Người đánh giá sẽ phải thực hiện những kiểm tra sau:

- Kiểm tra 1: Người đánh giá sẽ phải kiểm tra ứng dụng (thử truyền dữ liệu; ví dụ bằng cách kết nối với hệ thống hoặc trang web từ xa) trong khi bắt các gói tin từ ứng dụng. Người đánh giá sẽ phải xác nhận rằng các gói tin bắt từ lưu lượng được mã hóa với HTTPS, TLS hay DTLS để phù hợp với sự lựa chọn trong ST.

- Kiểm tra 2: Người đánh giá sẽ phải kiểm tra ứng dụng (thử truyền dữ liệu; ví dụ bằng cách kết nối với hệ thống hoặc trang web từ xa) trong khi bắt các gói tin từ ứng dụng. Người đánh giá sẽ phải xem lại gói tin bắt được và xác nhận rằng không có dữ liệu nhạy cảm nào được truyền bằng dạng rõ.

- Kiểm tra 3: Người đánh giá sẽ phải xem xét TSS để xác định các khóa của người dùng có được truyền hay không. Nếu các khóa được truyền, người đánh giá sẽ phải thiết lập khóa thành thành giá trị đã biết. Người đánh giá sẽ phải bắt các gói tin từ ứng dụng trong khi các khóa được truyền như mô tả trong TSS. Người đánh giá sẽ phải thực hiện tìm chuỗi ký tự trong các gói được bắt trên mạng và xác nhận rằng không thấy các khóa dạng bản rõ (plaintext) do người đánh giá thiết lập trước đó.

Đối với Android: Nếu chọn “không truyền kỳ dữ liệu nào”, người đánh giá sẽ phải đảm bảo rằng tập tin AndroidManifest.xml của ứng dụng không chứa tag <uses-permission> hay <uses-permission-sdk-23> chứa android:name=“android.permission.INTERNET”. Trong trường hợp này, không cần phải thực hiện những kiểm tra 1, 2, hay 3, khi nền tảng không cho phép ứng dụng thực hiện bất kỳ giao tiếp mạng nào.

Đối với iOS: Nếu chọn “mã hóa tất cả dữ liệu truyền”, người đánh giá sẽ phải đảm bảo rằng tập tin Info.plist của ứng dụng không chứa các khóa NSAllowsArbitraryLoads hay NSExceptionAllowsInsecureHTTPLoads, khi những phím này vô hiệu hóa tính năng Bảo mật Truyền của ứng dụng (Application Transport Security) của iOS.

9.2  Yêu cầu đảm bảo an toàn

Mục tiêu an toàn đối với TOE trong Điều 9 được thiết kế để định vị những mối đe dọa được xác định trong Điều 7.1. Các SFR trong Điều 9.1 là sự thể hiện chính thức của các Mục tiêu an toàn. Hồ sơ bảo vệ PP xác định những yêu cầu đảm bảo an toàn (SAR) để đánh giá mức độ mà người đánh giá có thể áp dụng cho việc đánh giá và thực hiện các kiểm tra độc lập.

...

...

...

Mô hình tổng quát để đánh giá các TOE so với các ST được viết để phù hợp với PP này như sau:

Sau khi ST được duyệt để đánh giá, tổ chức đánh giá an toàn công nghệ thông tin (ITSEF) (Information Technology Security Evaluation Facility) sẽ nhận TOE, môi trường IT hỗ trợ, và tài liệu hướng dẫn quản trị/người dùng cho TOE. ITSEF dự kiến sẽ thực hiện những hành động quy định bởi phương pháp đánh giá chung (CEM) cho các SAR ASE và ALC. ITSEF cũng thực hiện những hoạt động đảm bảo được đề cập trong Điều 9, nhằm mục đích giải thích các yêu cầu đảm bảo của CEM khác khi chúng áp dụng kỹ thuật cụ thể được thuyết minh trong TOE. Những Hoạt động Đảm bảo được đề cập trong Điều 9 cũng cung cấp sự giải thích cho những gì mà bên phát triển cần cung cấp để chứng minh TOE phù hợp với PP.

9.2.1  Lớp ASE: Mục tiêu an toàn

Như hoạt động của từng ASE được định nghĩa trong CEM [5] - Phương pháp đánh giá chung.

9.2.2  Lớp ADV: Phát triển

Thông tin về TOE được chứa trong tài liệu hướng dẫn có sẵn cho người dùng cuối cũng như phần TSS của ST. Bên phát triển TOE phải đồng ý với mô tả sản phẩm được chứa trong TSS khi nó liên quan tới các yêu cầu chức năng. Các hoạt động đảm bảo trong Điều 9.1 cần cung cấp cho các tác giả ST đầy đủ thông tin để xác định nội dung thích hợp cho phần TSS.

ADV_FSP.1 Thông số tính năng cơ bản (ADV_FSP.1)

Phần tử hành động của nhà phát triển:

ADV_FSP.1.1D

...

...

...

ADV_FSP.1.2D

Nhà phát triển sẽ cung cấp truy vết từ đặc tả chức năng này tới các SFR.

Lưu ý khi thực hiện: Như đã nêu trong giới thiệu của phần này, đặc tả chức năng bao gồm các thông tin trong tài liệu AGD_OPE và AGD_PRE. Nhà phát triển có thể tham khảo một trang web có thể truy cập được đối với các nhà phát triển ứng dụng và người đánh giá. Các hoạt động đảm bảo trong những yêu cầu chức năng chỉ ra bằng chứng cần có trong tài liệu và phần TSS; vì đây là những kết nối trực tiếp với các SFR, việc truy tìm trong phần tử ADV_FSP.1.2D đã được thực hiện hoàn toàn và không cần tài liệu bổ sung.

Các phần tử nội dung và trình bày:

ADV_FSP.1.1C

Đặc tả chức năng sẽ mô tả mục đích và phương pháp sử dụng cho mỗi TSFI tuân thủ-SFR và hỗ trợ-SFR.

ADV_FSP.1.2C

Đặc tả chức năng sẽ xác định tất cả các tham số liên quan đến mỗi TSFI tuân thủ-SFR và hỗ trợ-SFR.

ADV_FSP.1.3C

...

...

...

ADV_FSP.1.4C

Việc truy tìm phải chứng minh rằng các SFR theo dõi đến các TSFI trong đặc tả chức năng.

Phần tử hành động của người đánh giá:

ADV_FSP.1.1E

Người đánh giá sẽ phải xác nhận rằng thông tin được cung cấp đáp ứng tất cả yêu cầu về nội dung và trình bày dẫn chứng.

ADV_FSP.1.2E

Người đánh giá sẽ phải xác định rằng đặc tả chức năng là một bản khởi tạo chính xác và đầy đủ của các SFR.

Hoạt động đảm bảo:

Không có hoạt động đảm bảo cụ thể nào liên quan đến các SAR này, ngoại trừ việc đảm bảo thông tin phải được cung cấp. Tài liệu đặc tả chức năng được cung cấp để hỗ trợ các hoạt động đánh giá được mô tả trong Điều 9.1 và các hoạt động khác được mô tả cho các lớp AGD, ATE, và AVA của SAR. Yêu cầu về nội dung của thông tin đặc tả chức năng được ngầm đánh giá dựa trên các hoạt động đảm bảo khác đang được thực hiện; nếu người đánh giá không thể thực hiện một hoạt động vì không có đủ thông tin về giao diện thì vẫn chưa được xem là đã cung cấp một đặc tả chức năng đầy đủ.

...

...

...

Các tài liệu hướng dẫn sẽ được cung cấp cùng với ST. Hướng dẫn phải gồm mô tả cách nhân viên IT xác minh rằng Môi trường Vận hành có thể thực hiện vai trò của nó đối với chức năng an toàn. Tài liệu hướng dẫn không nên quá hình thức và các nhân viên IT có thể đọc được. Hướng dẫn phải được cung cấp cho mọi hệ điều hành mà sản phẩm hỗ trợ như tuyên bố trong ST. Hướng dẫn này sẽ bao gồm các chỉ dẫn để cài đặt thành công TSF trong môi trường đó; và các chỉ dẫn để quản lý bảo mật của TSF như một sản phẩm và như là một thành phần của hệ điều hành. Hướng dẫn liên quan đến chức năng an toàn cụ thể cũng có thể được cung cấp; các yêu cầu về hướng dẫn như vậy được bao gồm trong các hoạt động đảm bảo được xác định với mỗi yêu cầu.

9.2.3.1  AGD_OPE.1 Hướng dẫn Người dùng Vận hành (AGD_OPE.1)

Phần tử hành động của nhà phát triển:

AGD_OPE.1.1D

Bên phát triển sẽ cung cấp hướng dẫn người dùng vận hành.

Lưu ý khi thực hiện: Hướng dẫn người dùng vận hành không phải chỉ được chứa trong một tài liệu duy nhất. Hướng dẫn cho người dùng, quản trị viên và bên phát triển ứng dụng có thể được đặt trong các tài liệu hoặc các trang web. Khi thích hợp, tài liệu hướng dẫn được thể hiện trong định dạng mô tả bảng kiểm tra cấu hình mở rộng (XCCDF - eXtensible Configuration Checklist Description Format) để hỗ trợ tự động bảo mật. Thay vì lặp lại thông tin ở đây, bên phát triển nên xem lại các hoạt động đảm bảo cho thành phần này để xác định các chi tiết cụ thể của hướng dẫn mà người đánh giá sẽ kiểm tra. Điều này sẽ cung cấp các thông tin cần thiết cho việc chuẩn bị hướng dẫn có thể chấp nhận được.

Các phần tử nội dung và trình bày:

AGD_OPE.1.1C

Với mỗi vai trò người sử dụng, hướng dẫn người dùng vận hành sẽ mô tả các chức năng và đặc quyền truy cập người dùng cần được kiểm soát trong môi trường xử lý bảo mật, bao gồm các cảnh báo thích hợp.

...

...

...

AGD_OPE.1.2C

Với mỗi vai trò người sử dụng, hướng dẫn người dùng vận hành sẽ mô tả cách thức sử dụng các giao diện sẵn có được cung cấp bởi TOE một cách an toàn.

AGD_OPE.1.3C

Với mỗi vai trò người sử dụng, hướng dẫn người dùng vận hành sẽ mô tả các chức năng và các giao diện sẵn có, đặc biệt là tất cả các tham số bảo mật dưới sự kiểm soát của người dùng, chỉ ra các giá trị an toàn khi thích hợp.

AGD_OPE.1.4C

Với mỗi vai trò người sử dụng, hướng dẫn người dùng vận hành sẽ phải trình bày rõ ràng từng loại sự kiện an toàn liên quan đến các chức năng có thể truy cập của người dùng cần phải được thực hiện, bao gồm thay đổi các đặc tính an toàn của các thực thể dưới sự kiểm soát của TSF.

AGD_OPE.1.5C

Hướng dẫn người dùng vận hành sẽ xác định tất cả các phương thức hoạt động của TOE (bao gồm cả hoạt động sau khi hư hỏng hoặc lỗi về hoạt động), hậu quả của chúng và những gợi ý để duy trì hoạt động an toàn.

AGD_OPE.1.6C

...

...

...

AGD_OPE.1.7C

Hướng dẫn người dùng vận hành phải rõ ràng và hợp lý.

Phần tử hành động của người đánh giá:

AGD_OPE.1.1E

Người đánh giá sẽ phải xác nhận rằng thông tin được cung cấp sẽ đáp ứng tất cả yêu cầu về nội dung và trình bày của bằng chứng.

Hoạt động đảm bảo:

Một số nội dung của hướng dẫn vận hành sẽ phải được xác minh bằng các hoạt động đảm bảo trong Điều 9.1 và đánh giá TOE theo CEM [5] - Phương pháp đánh giá chung về an toàn CNTT. Thông tin bổ sung bên dưới cũng được yêu cầu. Nếu các tính năng mật mã được cung cấp bởi TOE, hướng dẫn vận hành sẽ gồm các hướng dẫn để cấu hình công cụ mã hóa liên quan đến cấu hình đánh giá của TOE. Nó sẽ cung cấp cảnh báo cho quản trị viên rằng việc sử dụng các công cụ mật mã khác chưa được đánh giá cũng như chưa kiểm tra trong khi đánh giá các CC của TOE. Tài liệu phải mô tả quá trình xác nhận cập nhật TOE bằng cách xác minh chữ ký số được thực hiện bởi TOE hoặc nền tảng bên dưới. Người đánh giá sẽ phải xác nhận rằng quá trình sẽ gồm các bước sau: các hướng dẫn để tự cập nhật. Việc này sẽ gồm các hướng dẫn để tạo cho cập nhật có thể truy cập tới TOE (ví dụ: đặt trong một thư mục cụ thể). Các hướng dẫn để khởi tạo quá trình cập nhật, cũng như phân biệt rõ liệu quá trình này có thành công hay không. Điều này bao gồm cả việc tạo ra chữ ký mã băm hoặc chữ ký số. TOE sẽ chứa chức năng bảo mật không thuộc phạm vi thẩm định theo PP này. Hướng dẫn vận hành sẽ làm rõ cho quản trị viên rằng chức năng bảo mật được bao gồm trong các hoạt động đánh giá.

9.2.3.2  AGD_PRE.1 Các thủ tục Chuẩn bị (AGD_PRE.1)

Phần tử hành động của nhà phát triển:

...

...

...

Nhà phát triển phải cung cấp TOE, gồm cả các thủ tục chuẩn bị của nó.

Lưu ý khi thực hiện: Cũng như hướng dẫn vận hành, nhà phát triển nên chú trọng hoạt động đảm bảo để xác định nội dung yêu cầu đối với các thủ tục chuẩn bị.

Các phần tử nội dung và trình bày:

AGD_PRE.1.1C

Các thủ tục chuẩn bị sẽ phải mô tả tất cả các bước cần thiết đối với việc chấp nhận an toàn của TOE đã chuyển để phù hợp với các thủ tục chuyển giao của nhà phát triển.

AGD_PRE.1.2C

Các thủ tục chuẩn bị sẽ phải mô tả tất cả các bước cần thiết cho việc cài đặt an toàn của TOE và cho việc chuẩn bị an toàn của môi trường vận hành phù hợp với các mục tiêu an toàn của môi trường vận hành như được mô tả trong ST.

Phần tử hành động của người đánh giá:

AGD_PRE.1.1E

...

...

...

AGD_PRE.1.2E

Người đánh giá sẽ phải áp dụng các thủ tục chuẩn bị để xác nhận rằng TOE có thể được chuẩn bị an toàn cho hoạt động.

Hoạt động đảm bảo:

Như đã nêu trong phần giới thiệu ở trên, có nhiều kỳ vọng đối với tài liệu - đặc biệt là khi cấu hình môi trường vận hành để hỗ trợ các yêu cầu chức năng của TOE. Người đánh giá sẽ phải kiểm tra để đảm bảo rằng hướng dẫn được cung cấp cho TOE thỏa mãn tất cả các yêu cầu cho TOE trong ST của các nền tảng.

9.2.4  Lớp ALC: Hỗ trợ vòng dời

Ở mức đảm bảo cung cấp cho TOE phù hợp với PP này, hỗ trợ vòng đời chỉ giới hạn ở các khía cạnh có thể nhìn thấy của người dùng cuối trong vòng đời chứ không phải là kiểm tra quy trình quản lý phát triển và cấu hình của nhà cung cấp TOE. Điều này không có nghĩa là giảm bớt vai trò quan trọng của các hoạt động mà nhà phát triển đóng góp vào sự tin tưởng chung của sản phẩm; mà nó là sự phản ánh về việc sẵn sàng các thông tin cung cấp để đánh giá ở mức độ bảo đảm này.

9.2.4.1  ALC_CMC.1 Gắn nhãn của TOE (ALC_CMC.1)

Phần tử hành động của nhà phát triển:

ALC_CMC.1.1D

...

...

...

Các phần tử nội dung và trình bày:

ALC_CMC.1.1C

TOE phải được gắn nhãn với một tham chiếu duy nhất

Lưu ý khi thực hiện: Thông tin tham chiếu duy nhất bao gồm:

- Tên ứng dụng

- Phiên bản ứng dụng

- Mô tả ứng dụng

- Nền tảng chạy ứng dụng

- Các thẻ nhận dạng phần mềm (SWID nếu có.

...

...

...

ALC_CMC.1.1E

Người đánh giá sẽ phải xác nhận rằng thông tin được cung cấp đáp ứng tất cả yêu cầu đối với nội dung và trình bày của bằng chứng.

Hoạt động đảm bảo:

Người đánh giá sẽ phải kiểm tra ST để đảm bảo rằng nó có chứa một nhận dạng (như tên sản phẩm / số phiên bản) xác định cụ thể phiên bản đáp ứng yêu cầu của ST. Hơn nữa, người đánh giá sẽ phải kiểm tra hướng dẫn AGD và các mẫu TOE nhận được từ thử nghiệm để đảm bảo rằng số phiên bản phù hợp với ST. Nếu nhà cung cấp duy trì một trang web quảng bá TOE, người đánh giá sẽ phải kiểm tra thông tin trên trang web để đảm bảo rằng thông tin trong ST là đủ để phân biệt sản phẩm.

9.2.4.2  ALC_CMS.1 Quản lý cấu hình của TOE (ALC_CMS.1)

Phần tử hành động của nhà phát triển:

ALC_CMS.1.1D

Bên phát triển sẽ phải cung cấp danh sách cấu hình cho TOE.

Các phần tử nội dung và trình bày:

...

...

...

Danh sách cấu hình phải gồm có: TOE riêng; và bằng chứng đánh giá theo yêu cầu của các SAR.

ALC_CMS.1.2C

Danh sách cấu hình sẽ xác định duy nhất các mục cấu hình.

Phần tử hành động của người đánh giá:

ALC_CMS.1.1E

Người đánh giá sẽ phải xác nhận rằng thông tin được cung cấp đáp ứng tất cả yêu cầu đối với nội dung và trình bày bằng chứng.

Hoạt động đảm bảo:

“Các bằng chứng đánh giá yêu cầu bởi các SAR” trong PP này chỉ giới hạn ở thông tin trong ST cùng với hướng dẫn cung cấp cho các quản trị viên và người sử dụng theo yêu cầu của AGD. Bằng cách đảm bảo rằng TOE được xác định cụ thể và nhận dạng này thống nhất trong ST và trong hướng dẫn AGD (như được thực hiện trong hoạt động đảm bảo đối với ALC_CMC.1), người đánh giá ngầm xác nhận các thông tin theo yêu cầu của thành phần này. Hỗ trợ vòng đời là các mục tiêu của chu kỳ sống và các hướng dẫn của bên phát triển cho các nhà cung cấp ứng dụng cho các thiết bị của nhà phát triển chứ không phải là việc kiểm tra sâu về quy trình quản lý phát triển và cấu hình của nhà sản xuất TSF. Điều này không nhằm giảm bớt vai trò quan trọng của các hoạt động mà nhà phát triển đóng góp vào sự tin tưởng chung của sản phẩm; mà nó là sự phản ánh về việc sẵn sàng các thông tin để đánh giá.

Người đánh giá sẽ phải đảm bảo rằng nhà phát triển đã xác định (trong tài liệu hướng dẫn cho các nhà phát triển ứng dụng liên quan đến nền tảng mục tiêu) một hoặc nhiều môi trường phát triển thích hợp để sử dụng trong việc phát triển các ứng dụng cho nền tảng của nhà phát triển. Đối với từng môi trường phát triển này, nhà phát triển sẽ phải cung cấp thông tin về cách cấu hình môi trường để đảm bảo rằng có gọi đến cơ chế bảo vệ tràn bộ đệm trong môi trường (ví dụ: các cờ của trình biên dịch). Người đánh giá sẽ phải đảm bảo rằng tài liệu này cũng bao gồm một chỉ dẫn về việc bảo vệ được bật theo mặc định hay phải được bật cụ thể. Người đánh giá sẽ phải đảm bảo rằng TSF được xác định duy nhất (đối với các sản phẩm khác từ nhà cung cấp TSF) và tài liệu do nhà phát triển cung cấp cùng với yêu cầu trong ST là được liên kết với TSF sử dụng nhận dạng duy nhất này.

...

...

...

Phần tử hành động của nhà phát triển:

ALC_TSU_EXT.1.1D

Nhà phát triển sẽ phải cung cấp mô tả trong TSS về mức độ cập nhật bảo mật kịp thời cho TOE.

Lưu ý khi thực hiện: Nhà phát triển ứng dụng phải hỗ trợ cập nhật cho sản phẩm của họ với mục đích khắc phục các lỗ hổng bảo mật.

ALC_TSU_EXT.1.2D

Nhà phát triển sẽ phải cung cấp mô tả trong TSS về cách người dùng được thông báo khi cập nhật việc thay đổi các chức năng bảo mật hoặc cấu hình của sản phẩm.

Các phần tử nội dung và trình bày:

ALC_TSU_EXT.1.1C

Mô tả sẽ phải gồm quá trình tạo và triển khai các bản cập nhật bảo mật cho phần mềm TOE.

...

...

...

Mô tả sẽ trình bày cửa sổ thời gian theo độ dài thời gian, theo ngày, giữa việc công bố công khai lỗ hổng và sẵn sàng cho cộng đồng cập nhật bảo mật cho TOE.

ALC_TSU_EXT.1.3C

Mô tả sẽ phải gồm các cơ chế công khai sẵn có cho báo cáo các vấn đề bảo mật liên quan đến TOE.

Lưu ý khi thực hiện: Cơ chế báo cáo có thể gồm các trang web, các địa chỉ email, cũng như các phương tiện để bảo vệ bản chất nhạy cảm của báo cáo (ví dụ: khóa công khai có thể được dùng để mã hóa các chi tiết của khai thác minh chứng (proof-of-concept exploit)).

Phần tử hành động của người đánh giá:

ALC_TSU_EXT.1.1E

Người đánh giá sẽ phải xác nhận rằng thông tin được cung cấp đáp ứng tất cả yêu cầu đối với nội dung và trình bày của bằng chứng.

Hoạt động đảm bảo:

Người đánh giá sẽ phải xác nhận rằng TSS có chứa mô tả tiến trình cập nhật bảo mật kịp thời được nhà phát triển sử dụng để tạo và thực hiện các cập nhật bảo mật. Người đánh giá sẽ phải xác nhận rằng mô tả này sẽ dùng cho toàn bộ ứng dụng. Người đánh giá cũng sẽ phải xác nhận rằng, ngoài quy trình của nhà phát triển TOE, bất kỳ quá trình của bên thứ ba nào cũng được đề cập trong mô tả. Người đánh giá cũng sẽ phải xác nhận có mô tả cho mỗi cơ chế thực hiện các cập nhật bảo mật.

...

...

...

Người đánh giá sẽ phải xác nhận rằng mô tả này gồm các cơ chế công khai (bao gồm hoặc địa chỉ email hoặc trang web) cho việc báo cáo các vấn đề bảo mật liên quan đến TOE. Người đánh giá sẽ phải xác nhận rằng mô tả của cơ chế này phải có phương pháp về việc bảo vệ báo cáo bằng cách hoặc là sử dụng một khóa công khai để mã hóa email hoặc sử dụng kênh tin cậy cho trang web.

9.2.5  Lớp ATE: Kiểm tra

Việc kiểm tra được chỉ định cho các chức năng của hệ thống cũng như việc lợi dụng các điểm yếu của thiết kế hoặc khi triển khai. Trước đây được thực hiện thông qua họ ATE_IND, và sau này thông qua họ AVA_VAN. Ở mức độ đảm bảo được chỉ định trong PP này, việc kiểm tra dựa trên các chức năng được quảng cáo và các giao diện phụ thuộc vào sự sẵn có của thông tin thiết kế. Một trong những đầu ra chính của quá trình đánh giá là báo cáo kiểm tra như đã nêu trong các yêu cầu sau.

ATE_IND.1 Kiểm tra độc lập - Thích ứng (ATE_IND.1)

Phần tử hành động của nhà phát triển:

ATE_IND.1.1D

Nhà phát triển sẽ phải cung cấp TOE cho việc kiểm tra.

Các phần tử nội dung và trình bày:

ATE_IND.1.1C

...

...

...

Phần tử hành động của người đánh giá:

ATE_IND.1.1E

Người đánh giá sẽ phải xác nhận rằng thông tin được cung cấp đáp ứng tất cả yêu cầu đối với nội dung và trình bày của bằng chứng.

ATE_IND.1.2E

Người đánh giá sẽ phải kiểm tra một tập con của TSF để xác nhận rằng TSF hoạt động như được chỉ định.

Lưu ý khi thực hiện: Người đánh giá sẽ kiểm tra ứng dụng trên phiên bản hiện hành đã vá lỗi đầy đủ nhất của nền tảng.

Hoạt động đảm bảo:

Người đánh giá sẽ phải chuẩn bị kế hoạch kiểm tra và tài liệu báo cáo về các khía cạnh kiểm tra của hệ thống, bao gồm bất kỳ sự cố nào của ứng dụng trong quá trình kiểm tra. Người đánh giá sẽ phải xác định nguyên nhân gốc của bất kỳ sự cố nào của ứng dụng và phải có thông tin đó trong báo cáo. Kế hoạch kiểm tra bao gồm tất cả các hành động kiểm tra theo tham khảo [5] - Phương pháp Đánh giá Chung về an toàn CNTT [CEM] và phần chính của các Hoạt động đảm bảo của PP này.

Mặc dù không nhất thiết phải kiểm tra cho từng yêu cầu đã được liệt kê trong một Hoạt động Đảm bảo, người đánh giá phải ghi rõ trong kế hoạch kiểm tra rằng mỗi yêu cầu kiểm tra áp dụng trong ST đều được bảo đảm. Kế hoạch kiểm tra sẽ xác định các nền tảng được kiểm tra, và đối với những nền tảng không có trong kế hoạch kiểm tra nhưng có trong ST, kế hoạch kiểm tra phải thuyết minh một cho việc không kiểm tra các nền tảng đó. Thuyết minh này phải chỉ rõ sự khác biệt giữa nền tảng được kiểm tra và nền tảng chưa được kiểm tra, và khẳng định rằng sự khác biệt không ảnh hưởng đến việc thực hiện kiểm tra. Không chỉ đơn thuần khẳng định rằng sự khác biệt không ảnh hưởng mà phải cung cấp được lý do chính đáng. Nếu tất cả các nền tảng được yêu cầu trong ST được kiểm tra, thì không cần nêu lý do nữa. Kế hoạch kiểm tra sẽ mô tả các thành phần được kiểm tra của mỗi nền tảng và bất kỳ thiết lập cần thiết nào khác ngoài những gì đã có trong tài liệu AGD. Cần lưu ý rằng người đánh giá dự kiến sẽ làm theo các tài liệu AGD để cài đặt và thiết lập của mỗi nền tảng hoặc như là một phần của kiểm tra hoặc như là một điều kiện kiểm tra trước của tiêu chuẩn. Việc này có thể bao gồm kiểm tra đặc biệt các trình điều khiển (drivers) hoặc các công cụ (tools). Với mỗi trình điều khiển hoặc công cụ, phải cung cấp một đối số để trình điều khiển hoặc công cụ không ảnh hưởng xấu đến hiệu suất của các chức năng của TOE và nền tảng của nó.

...

...

...

Báo cáo kiểm tra (là một phiên bản chú giải của kế hoạch kiểm tra) sẽ chi tiết các hoạt động đã diễn ra khi các quy trình kiểm tra được thực hiện, và gồm các kết quả thực tế của các kiểm tra. Đây sẽ là một bản kê tích lũy cho tiến trình đánh giá, nếu có kiểm tra không thành công thì phải cài đặt bản sửa lỗi và tiến hành kiểm tra lại, báo cáo sẽ hiển thị kết quả “thất bại” và “đạt” (và các chi tiết hỗ trợ) chứ không chỉ là kết quả “đạt”.

9.2.6  Lớp AVA: Đánh giá lỗ hổng

Với phiên bản hiện tại của hồ sơ bảo vệ này, phòng thí nghiệm đánh giá dự kiến sẽ khảo sát các nguồn mở để khám phá những lỗ hổng đã được phát hiện trong các loại sản phẩm này. Trong hầu hết các trường hợp, những lỗ hổng này sẽ đòi hỏi sự phức tạp vượt quá sự phức tạp của kẻ tấn công mức độ cơ bản. Cho đến khi các công cụ xâm nhập được tạo ra và được phân phối cho các phòng thí nghiệm đánh giá, không kỳ vọng người đánh giá sẽ kiểm tra các lỗ hổng này trong TOE. Các phòng thí nghiệm sẽ bình luận về khả năng có những lỗ hổng này dựa trên tài liệu được cung cấp bởi nhà cung cấp. Thông tin này sẽ được sử dụng trong việc phát triển các công cụ kiểm tra thâm nhập và để phát triển các hồ sơ bảo vệ trong tương lai.

AVA_VAN.1 Khảo sát Lỗ hổng (AVA_VAN.1)

Phần tử hành động của nhà phát triển:

AVA_VAN.1.1D

Nhà phát triển sẽ phải cung cấp TOE cho đánh giá.

Các phần tử nội dung và trình bày:

AVA_VAN.1.1C

...

...

...

Lưu ý khi thực hiện: Tính phù hợp cho việc kiểm tra có nghĩa là không bị làm rối loạn hoặc bị đóng gói theo cách làm người đánh giá gián đoạn việc phân tích tĩnh hoặc động.

Phần tử hành động của người đánh giá:

AVA_VAN.1.1E

Người đánh giá sẽ phải xác nhận rằng thông tin được cung cấp đáp ứng tất cả yêu cầu đối với nội dung và trình bày của bằng chứng.

AVA_VAN.1.2E

Người đánh giá sẽ thực hiện tìm kiếm các nguồn tin công cộng để xác định các lỗ hổng tiềm ẩn trong TOE.

Lưu ý khi thực hiện: Các nguồn tin công cộng bao gồm từ điển CVE (Common Vulnerabilies and Exposures - Các lỗ hổng và phơi nhiễm thông dụng) cho các lỗ hổng công khai đã biết. Các nguồn tin công cộng cũng gồm các trang web cung cấp kiểm tra virus miễn phí cho các tập tin.

AVA_VAN.1.3E

Người đánh giá sẽ phải tiến hành kiểm tra xâm nhập dựa trên các lỗ hổng tiềm ẩn đã được xác định để xác nhận rằng TOE có khả năng chống lại các tấn công được thực hiện bởi kẻ tấn công có tiềm năng tấn công cơ bản.

...

...

...

Người đánh giá sẽ tạo một báo cáo để ghi lại những phát hiện của họ liên quan đến yêu cầu này. Báo cáo này có thể là một phần của báo cáo thử nghiệm tổng thể được đề cập trong ATE_IND hoặc một tài liệu riêng biệt. Người đánh giá sẽ thực hiện tìm kiếm thông tin công cộng để tìm các lỗ hổng đã được tìm thấy trong các ứng dụng tương tự, tập trung vào các giao thức mạng mà ứng dụng sử dụng và các định dạng tài liệu mà nó phân tích. Người đánh giá cũng sẽ phải chạy một trình quét virus với dữ liệu virus mới nhất cho các tệp ứng dụng và xác nhận rằng không có tệp nào bị gắn mã độc. Người đánh giá sẽ đưa các nguồn tin được tư vấn và các lỗ hổng được tìm thấy vào trong báo cáo.

Với mỗi lỗ hổng được phát hiện, người đánh giá hoặc là đưa ra một lý do về việc không áp dụng của nó, hoặc người đánh giá xây dựng một thử nghiệm (sử dụng các hướng dẫn được cung cấp trong ATE_IND) để xác nhận lỗ hổng nếu phù hợp. Việc phù hợp được xác định bằng cách đánh giá kiểu tấn công cần thiết để tận dụng lợi thế của lỗ hổng. Vi dụ nếu khai thác lỗ hổng đòi hỏi kỹ năng chuyên gia và kính hiển vi điện tử thì việc kiểm tra sẽ không phù hợp và phải biện minh phù hợp.

Phụ lục A

(Quy định)

Các yêu cầu không bắt buộc

Các yêu cầu cơ bản (những gì phải được thực hiện bởi TOE) phải được chứa trong phần thân của PP này. Ngoài ra, có ba loại yêu cầu khác nhau được quy định trong Phụ lục A, Phụ lục B và Phụ lục C. Loại đầu tiên (trong Phụ lục này) là các yêu cầu có thể có trong ST, nhưng không bắt buộc với TOE để yêu cầu phù hợp với PP này. Loại thứ hai (trong Phụ lục B) là các yêu cầu dựa trên các lựa chọn trong phần thân của PP: nếu các lựa chọn cụ thể được đưa ra, thì phải bao gồm các yêu cầu bổ sung trong phụ lục đó. Loại thứ ba (trong Phụ lục C) là các thành phần không bắt buộc để phù hợp với PP này, nhưng sẽ được bao gồm trong các yêu cầu cơ bản trong các phiên bản sắp tới của PP này, do đó khuyến khích các nhà cung cấp áp dụng. Lưu ý rằng tác giả của ST có trách nhiệm để đảm bảo rằng các yêu cầu có thể liên quan đến các yêu cầu trong Phụ lục A, Phụ lục B và Phụ lục C nhưng không được liệt kê (ví dụ các yêu cầu loại FMT) cũng được đưa vào ST.

A.1  FCS_CKM.1(2) Tạo khóa mật mã đối xứng

FCS_CKM.1.1(2)

...

...

...

128 bit,

256 bit

].

Lưu ý khi thực hiện: Các khóa đối xứng có thể được sử dụng để tạo các khóa theo chuỗi khóa.

Hoạt động đảm bảo:

TSS

Người đánh giá sẽ xem xét TSS để xác định rằng nó mô tả cách gọi chức năng được mô tả bởi FCS_RBG_EXT.1 (9.1.1).

Nếu ứng dụng dựa vào việc sinh bit ngẫu nhiên từ nền tảng của máy chủ, người đánh giá sẽ phải xác thực rằng TSS bao gồm tên / nhà sản xuất của RBG bên ngoài và mô tả chức năng gọi và các tham số được dùng khi gọi hàm DRBG bên ngoài. Nếu các RBG bên ngoài khác nhau được sử dụng cho các nền tảng khác nhau, người đánh giá sẽ phải xác thực rằng TSS sẽ xác định mỗi RBG cho mỗi nền tảng. Ngoài ra, người đánh giá sẽ phải xác thực rằng TSS bao gồm một mô tả ngắn về giả thuyết của nhà cung cấp cho số lượng của việc gieo entropy[1] DRBG bên ngoài. Người đánh giá sử dụng mô tả về chức năng RBG trong FCS_RBG_EXT hoặc tài liệu có sẵn cho môi trường hoạt động để xác định rằng kích thước khóa được yêu cầu giống với kích thước khóa và chế độ dùng cho việc mã hóa /giải mã dữ liệu người dùng.

A.2  FCS_TLSC_EXT.2 Giao thức máy khách của TLS

...

...

...

Ứng dụng sẽ hỗ trợ xác thực lẫn nhau sử dụng chứng chỉ X.509v3.

Lưu ý khi thực hiện: Việc sử dụng các chứng chỉ X.509v3 cho TLS được đề cập trong FIA_X509_EXT.2.1 (Điều B.15 Phụ lục B). Yêu cầu này cho bổ sung thêm rằng một máy khách phải có khả năng trình chứng chỉ cho máy chủ TLS để xác thực lẫn nhau TLS.

Hoạt động đảm bảo:

Người đánh giá sẽ phải đảm bảo rằng mô tả TSS được yêu cầu cho mỗi FIA_X509_EXT.2.1 (Điều B.15 Phụ lục B) bao gồm việc sử dụng các chứng nhận phía máy khách cho việc chứng thực lẫn nhau TLS.

Người đánh giá sẽ phải xác nhận rằng hướng dẫn AGD được yêu cầu cho mỗi FIA_X509_EXT.2.1 (Điều B.15 Phụ lục B) bao gồm các hướng dẫn để cấu hình các chứng chỉ phía máy khách cho việc chứng thực lẫn nhau TLS.

Người đánh giá cũng sẽ phải thực hiện kiểm tra sau:

- Kiểm tra 1: Người đánh giá sẽ phải thực hiện thay đổi sau cho lưu lượng:

• Cấu hình máy chủ để yêu cầu chứng thực lẫn nhau và sau đó sửa đổi một byte trong một trường CA trong thông điệp bắt tay Yêu cầu Chứng chỉ (Certificate Request) của Máy chủ. Trường CA đã sửa đổi không phải là CA được sử dụng để ký chứng chỉ của máy khách. Người đánh giá sẽ phải xác nhận kết nối là không thành công.

...

...

...

(Quy định)

Các yêu cầu dựa trên lựa chọn

Như đã nêu trong phần giới thiệu, các yêu cầu cơ bản (những gì phải được thực hiện bởi TOE hoặc nền tảng cơ bản của nó) phải được chứa trong phần thân của PP này. Có các yêu cầu bổ sung dựa trên các lựa chọn trong phần thân của PP: nếu các lựa chọn cụ thể được đưa ra, thì các yêu cầu bổ sung cần phải được đưa vào.

B.1  FCS_RBG_EXT.2 Tạo Bit ngẫu nhiên từ ứng dụng

FCS_RBG_EXT.2.1

Ứng dụng sẽ phải thực hiện tất cả các dịch vụ sinh bit ngẫu nhiên bất định (DRBG) theo SP 800-90A của NIST sử dụng [lựa chọn: Hash_DRBG (bất kỳ), HMAC_DRBG (bất kỳ), CTR_DRBG (AES)].

Yêu cầu này tùy thuộc vào chọn lựa trong FCS_RBG_EXT.1.1 (9.1.1).

Lưu ý khi thực hiện: Yêu cầu này sẽ phải được có trong các ST mà trong đó chọn implement DRBG functionality (thực hiện chức năng DRBG) trong FCS_RBG_EXT.1.1 (9.1.1). Tác giả ST nên chọn tiêu chuẩn mà các dịch vụ RBG tuân thủ (hoặc SP 800-90A [14] hoặc FIPS 140-2 [17] Phụ lục C).

SP 800-90A [14] chứa ba phương pháp tạo các số ngẫu nhiên khác nhau; một trong số chúng, phụ thuộc vào nguyên thủy mã hóa cơ bản (các hàm băm / các bản mã). Tác giả ST sẽ chọn chức năng được sử dụng (nếu SP 800-90A được chọn), và bao gồm các nguyên thủy mã hóa cơ bản được sử dụng trong yêu cầu hoặc trong TSS. Mặc dù các chức năng hàm băm được xác định (SHA-1, SHA-224, SHA-256, SHA-384, SHA-512) được phép sử dụng cho Hash_DRBG hoặc HMAC_DRBG, chỉ các thực hiện dựa trên AES cho CTR_DRBG là được phép.

...

...

...

Người đánh giá sẽ phải thực hiện các kiểm tra sau, tùy thuộc vào tiêu chuẩn mà RBG tuân thủ.

Thực hiện Phù hợp với FIPS 140-2 - Phụ lục C [17].

Tham chiếu cho các kiểm tra trong phần này là Hệ thống Xác thực Trình tạo Số ngẫu nhiên (RNGVS - The Random Number Generator Validation System). Người đánh giá sẽ phải thực hiện hai kiểm tra bên dưới. Lưu ý rằng “các giá trị mong đợi” được tạo ra bằng cách thực hiện tham chiếu của thuật toán được biết là chính xác. Bằng chứng về tính chính xác được để lại cho mỗi lưu đồ.

- Kiểm tra 1: Người đánh giá sẽ thực hiện Kiểm tra Hạt giống Biến thiên (Variable Seed Test). Người đánh giá sẽ phải cung cấp một bộ 128 cặp (Seed, DT) cho chức năng RBG của TSF, mỗi một trong chúng là 128 bit. Người đánh giá cũng phải cung cấp một khóa (chiều dài phù hợp với thuật toán AES) không đổi với tất cả các cặp 128 (Seed, DT). Giá trị DT được tăng lên 1 cho mỗi bộ. Giá trị hạt giống trong tập không được lặp lại. Người đánh giá đảm bảo rằng các giá trị trả về bởi TSF khớp với các giá trị mong đợi.

- Kiểm tra 2: Người đánh giá sẽ phải thực hiện một kiểm tra Monte Carlo. Đối với kiểm tra này, người đánh giá cung cấp một giá trị Hạt giống (Seed) và DT ban đầu cho chức năng RBG của TSF; mỗi một giá trị là 128 bit. Người đánh giá cũng phải cung cấp một khóa (chiều dài phù hợp với thuật toán AES) không đổi trong khi kiểm tra. Sau đó, người đánh giá sẽ gọi RBG của TSF 10.000 lần, với giá trị DT tăng thêm 1 cho mỗi lần lặp và hạt giống mới cho lần lặp tiếp theo được tạo theo chỉ định trong Khuyến nghị Bộ Sinh Số Ngẫu nhiên của NIST (NIST-Recommended Random Number Generator) dựa trên ANSI X9.31 - Phụ lục A.2.4 sử dụng các thuật toán DES và AES 3-Key Triple, Điều 3. Các bên đánh giá đảm bảo rằng giá trị thứ 10000 tạo ra phù hợp với giá trị kỳ vọng.

Thực hiện phù hợp với Ấn phẩm Đặc biệt 800-90A của NIST (tham khảo [14])

- Kiểm tra 1: Người đánh giá sẽ phải thực hiện 15 thử nghiệm cho việc thực hiện RNG. Nếu RNG có thể cấu hình được, người đánh giá sẽ phải thực hiện 15 thử nghiệm đối với mỗi cấu hình. Người đánh giá cũng sẽ phải xác nhận rằng hướng dẫn vận hành chứa các chỉ dẫn thích hợp để cấu hình chức năng RNG.

Nếu RNG bật cơ chế kháng dự báo, mỗi thử nghiệm bao gồm (1) thiết lập DRBG, (2) tạo ra khối đầu tiên các bit ngẫu nhiên (3) tạo ra một khối thứ hai của các bit ngẫu nhiên (4) giải thiết lập. Người đánh giá sẽ xác minh rằng khối thứ hai các bit ngẫu nhiên là giá trị dự kiến. Người đánh giá sẽ tạo ra tám giá trị đầu vào cho mỗi lần thử. Đầu tiên là bộ đếm (0-14). Ba giá trị tiếp theo là đầu vào entropy, nonce và chuỗi cá nhân hóa cho yêu cầu hoạt động. Hai giá trị tiếp là đầu vào bổ sung và entropy đầu vào cho lần gọi đầu tiên tạo ra. Hai giá trị cuối cùng là đầu vào bổ sung và entropy đầu vào cho lần gọi thứ hai tạo ra. Các giá trị này được tạo ngẫu nhiên. “Tạo một khối bit ngẫu nhiên” có nghĩa là tạo ra các bit ngẫu nhiên với số bit trả về bằng với Độ dài Khối Đầu ra (Output Block Length) (như được định nghĩa trong SP 800-90A của NIST).

Nếu RNG không có cơ chế kháng dự báo, mỗi thử nghiệm bao gồm (1) thiết lập DRBG, (2) tạo ra khối đầu tiên các bit ngẫu nhiên (3) chọn lại hạt giống (reseed), (4) tạo ra một khối thứ hai các bit ngẫu nhiên (5) giải thiết lập. Người đánh giá sẽ xác nhận rằng khối thứ hai các bit ngẫu nhiên là giá trị dự kiến. Người đánh giá sẽ tạo ra tám giá trị đầu vào cho mỗi thử nghiệm. Đầu tiên là bộ đếm (0-14). Ba giá trị tiếp theo là đầu vào entropy, nonce và chuỗi cá nhân hóa cho thao tác nhanh. Giá trị thứ năm là đầu vào bổ sung cho lần gọi đầu tiên tạo ra. Giá trị thứ sáu và thứ bảy là đầu vào bổ sung và entropy đầu vào cho lần gọi để chọn lại hạt giống. Giá trị cuối cùng là đầu vào bổ sung cho lần gọi thứ hai tạo ra.

...

...

...

Đầu vào Entropy: chiều dài của giá trị đầu vào entropy phải bằng với chiều dài hạt giống.

Nonce: Nếu một nonce được hỗ trợ (CTR_DRBG không có Derivation Function không sử dụng nonce), thì chiều dài bit nonce là một nửa chiều dài hạt giống.

Chuỗi cá nhân hóa: Chiều dài chuỗi cá nhân phải nhỏ hơn hoặc bằng chiều dài hạt giống. Nếu việc thực hiện chỉ hỗ trợ một độ dài của chuỗi cá nhân hóa, thì dùng độ dài như nhau cho cả hai giá trị. Nếu có hỗ trợ nhiều hơn một độ dài chuỗi, người đánh giá sẽ sử dụng các chuỗi cá nhân hóa có hai độ dài khác nhau. Nếu việc triển khai không sử dụng chuỗi cá nhân hóa thì không cần phải cung cấp giá trị.

Các đầu vào bổ sung: độ dài bit đầu vào bổ sung có cùng giá trị mặc định và các giới hạn với độ dài như chuỗi cá nhân hóa.

FCS_RBG_EXT.2.2

RBG xác định sẽ được gieo hạt bởi một nguồn entropy tích lũy entropy từ một DRBG của nền tảng và [lựa chọn:

một nguồn nhiễu dựa trên phần mềm,

không có nguồn nhiễu khác

] với tối thiểu [lựa chọn:

...

...

...

256 bit

] của entropy ít nhất bằng với độ mạnh bảo mật nhất (theo SP 800-57 [13] của NIST) của các khóa và hàm băm mà nó sẽ tạo ra.

Yêu cầu này tùy thuộc vào chọn lựa trong FCS_RBG_EXT.1.1 (9.1.1).

Lưu ý khi thực hiện: Yêu cầu này phải được bao gồm trong các ST, trong đó chọn “implement DRBG funtionality” (thực hiện chức năng DRBG) trong FCS_RBG_EXT.1.1 (9.1.1). Đối với lựa chọn đầu tiên trong yêu cầu này, tác giả ST chọn ‘nguồn nhiễu dựa trên phần mềm’ nếu dùng bất kỳ nguồn nhiễu bổ sung nào để nhập vào DRBG của ứng dụng. Lưu ý rằng ứng dụng phải sử dụng DRBG của nền tảng để gieo DRBG của nó.

Lựa chọn thứ hai trong yêu cầu này, tác giả ST chọn số bit thích hợp của entropy tương ứng với độ mạnh bảo mật nhất của các thuật toán trong ST. Độ mạnh bảo mật được định nghĩa trong bảng 2 và 3 của NIST SP 800-57 [13]. Ví dụ, nếu việc triển khai gồm RSA 2048 bit (độ mạnh bảo mật của 112 bit) và AES 256 (độ mạnh bảo mật 256 bit), thì tác giả ST sẽ chọn 256 bit.

Hoạt động đảm bảo:

Phải có tài liệu và người đánh giá sẽ phải thực hiện các hoạt động - theo Phụ lục D của tài liệu này - và tài liệu Đánh giá Entropy và tham khảo tài liệu Làm rõ về Tài liệu Entropy và Phụ lục đánh giá [8].

Trong tương lai, thử nghiệm thống kê cụ thể (phù hợp với SP 800-90B của NIST [15]) sẽ được yêu cầu để xác thực các ước lượng entropy.

B.2  FCS_CKM_EXT.1 Dịch vụ tạo khóa mật mã

...

...

...

Ứng dụng sẽ [lựa chọn:

không tạo ra khóa mật mã bất đối xứng,

gọi chức năng tạo khóa bất đối xứng của nền tảng cung cấp,

thực hiện tạo khóa bất đối xứng

].

Yêu cầu này tùy thuộc vào chọn lựa trong FCS_TLSC_EXT.1.1 (Điều B.9 Phụ lục B).

Lưu ý khi thực hiện: Nếu chọn thực hiện việc tạo khóa bất đối xứng hoặc gọi chức năng tạo khóa bất đối xứng của nền tảng cung cấp thì các thành phần FCS_CKM.1(1) (Điều B.9 Phụ lục B) bổ sung sẽ được đưa vào ST.

Hoạt động đảm bảo:

Người đánh giá sẽ phải kiểm tra ứng dụng và tài liệu dành cho nhà phát triển của nó để xác định xem ứng dụng có cần các dịch vụ tạo khóa bất đối xứng không. Nếu không, người đánh giá sẽ phải xác nhận lựa chọn không tạo ra khóa mật mã bất đối xứng là có trong ST. Ngược lại, các hoạt động đánh giá sẽ được thực hiện như đã nêu trong các yêu cầu dựa trên lựa chọn.

...

...

...

FCS_CKM.1.1(1)

Ứng dụng sẽ tạo ra các khóa mật mã bất đối xứng theo một thuật toán tạo khóa mật mã được chỉ định [lựa chọn:

[các lược đồ của RSA] sử dụng kích thức khóa mật mã là [2048-bit hoặc cao hơn] đáp ứng các yêu cầu sau: [lựa chọn:

FIPS PUB 186-4, “Tiêu chuẩn Chữ ký số (DSS)”, Điều B.3 Phụ lục B [19], ANSI X9.31-1998, Điều 4.1 [21]

] ,

[Các lược đồ của ECC] dùng [“NIST curves” P-256, P-384 và [lựa chọn: P-521, no other curves ] ] đáp ứng yêu cầu sau: [FIPS PUB 186-4, “Tiêu chuẩn Chữ ký số (DSS)”, Điều B.4 Phụ lục B [19]],

[Các lược đồ của FFC] sử dụng các khóa mật mã có kích thước [2048-bit hoặc cao hơn] đáp ứng các yêu cầu sau: [FIPS PUB 186-4, “Tiêu chuẩn Chữ ký Số (DSS)”, Điều B.1 Phụ lục B [19]]

].

Yêu cầu này tùy thuộc vào chọn lựa trong FCS_CKM_EXT.1.1.

...

...

...

Nếu TOE hoạt động như một người nhận trong lược đồ thiết lập khóa RSA, TOE không cần phải thực hiện việc tạo khóa RSA.

Tùy chọn ANSI X9.31-1998 sẽ bị bỏ khỏi lựa chọn trong ấn phẩm tương lai của tiêu chuẩn này. Hiện tại, việc lựa chọn không giới hạn ở các lựa chọn FIPS PUB 186-4 để cho phép ngành công nghiệp thêm thời gian để hoàn thành quá trình chuyển đổi sang tiêu chuẩn FIPS PUB 186-4 hiện đại.

Hoạt động đảm bảo:

Người đánh giá sẽ phải đảm bảo rằng TSS sẽ xác định kích thước khóa được hỗ trợ bởi TOE. Nếu ST chỉ định nhiều hơn một lược đồ, người đánh giá sẽ kiểm tra TSS để xác nhận rằng nó xác định cách sử dụng cho mỗi lược đồ.

Người đánh giá sẽ phải xác nhận rằng hướng dẫn của AGD chỉ dẫn quản trị viên cách cấu hình TOE để dùng (các) lược đồ tạo khóa và (các) kích thước của khóa đã chọn cho tất cả các sử dụng đã định nghĩa trong PP này.

Nếu ứng dụng gọi chức năng được nền tảng cung cấp cho việc tạo khóa bất đối xứng thì người đánh giá sẽ kiểm tra TSS để xác nhận rằng nó mô tả cách gọi chức năng tạo khóa.

Nếu ứng dụng thực hiện việc tạo khóa bất đối xứng thì phải thực hiện các hoạt động thử nghiệm sau.

Lưu ý về Hoạt động đảm bảo: Các kiểm tra dưới đây có thể yêu cầu nhà phát triển cung cấp quyền truy cập vào môi trường của bên phát triển cung cấp cho người đánh giá các công cụ thường có sẵn cho người dùng cuối của ứng dụng.

Tạo khóa cho lược đồ RSA của FIPS PUB 186-4

...

...

...

1. Các số nguyên tố ngẫu nhiên:

• Số nguyên tố có thể kiểm chứng được

• Số nguyên tố chắc chắn

2. Các số nguyên tố với điều kiện:

• Tất cả các số nguyên tố p1, p2, q1, q2, p và q đều là số nguyên tố có thể kiểm chứng được

• Các số nguyên tố p1, p2, q1, và q2 là các số nguyên tố có thể kiểm chứng và p và q là số nguyên tố chắc chắn

• Các số nguyên tố p1, p2, q1, q2, p và q đều là số nguyên tố chắc chắn.

Để kiểm tra phương pháp tạo khóa cho phương pháp các Số nguyên tố có thể Kiểm chứng Ngẫu nhiên và cho tất cả các phương pháp Số nguyên tố với Điều kiện, người đánh giá phải cấy hàm tạo khóa TSF với dữ liệu đủ để xác định: chính xác cặp khóa RSA. Việc này bao gồm (các) hạt ngẫu nhiên, số mũ công cộng của khóa RSA, và chiều dài khóa mong muốn. Với mỗi độ dài khóa được hỗ trợ, người đánh giá sẽ phải có TSF tạo ra 25 cặp khóa. Người đánh giá sẽ phải xác nhận tính chính xác của việc thực hiện của TSF bằng cách so sánh các giá trị tạo ra bởi TSF với các giá trị được tạo ra từ một thực hiện tốt đã biết.

Nếu có thể, phương pháp Số nguyên tố có thể kiểm chứng ngẫu nhiên cũng nên được xác nhận lại so với một thực hiện tốt đã biết như được mô tả ở trên. Nếu không, người đánh giá sẽ phải có TSF tạo ra 10 cặp khóa cho mỗi độ dài khóa nlen và xác nhận:

...

...

...

• p và q có thể là số nguyên tố theo các thử nghiệm Miller-Rabin,

• GCD(p-1,e) = 1,

• GCD(q-1,e) = 1,

• 2^16 <= e <= 2^256 và e là một số lẻ,

• |p-q| > 2^(nlen/2 - 100),

• p >= bình phương của (2)*( 2^(nlen/2-1) ),

• q >= bình phương của (2)*( 2^(nlen/2 -1) ),

• 2^(nlen/2) < d < LCM(p-1,q-1),

• e*d = 1 mod LCM(p-1,q-1).

...

...

...

Nếu TSF thực hiện lược đồ ANSI X9.31-1998, người đánh giá sẽ phải kiểm tra để đảm bảo rằng TSS sẽ mô tả cách tạo cặp khóa. Để thấy rằng việc thực hiện TSF đáp ứng ANSI X9.31-1998, người đánh giá sẽ phải đảm bảo rằng TSS sẽ chứa các thông tin sau:

- TSS sẽ phải liệt kê tất cả các phần của tiêu chuẩn mà TOE tuân thủ;

- Đối với mỗi phần áp dụng được liệt kê trong TSS, với tất cả các phát biểu không phải là “sẽ” (có nghĩa là “sẽ không”, “nên”, và “không nên”), nếu TOE thực hiện các lựa chọn như vậy thì nó sẽ được mô tả trong TSS. Nếu chức năng được bao gồm được chỉ báo là “sẽ không” hoặc “không nên” trong tiêu chuẩn, TSS sẽ cung cấp lý do tại sao điều này sẽ không ảnh hưởng xấu đến chính sách bảo mật do TOE thực hiện;

- Đối với mỗi phần áp dụng của Phụ lục B, phải mô tả bất kỳ sự thiếu sót nào về chức năng liên quan đến các câu “sẽ” hoặc “nên”.

Tạo khóa với ECC (Elliptic Curve Cryptography - mật mã đường cong elliptic)

Thử nghiệm tạo khóa ECC FIPS 186-4 cho mỗi đường cong NIST được hỗ trợ, tức P-256, P-384 và P-521, người đánh giá sẽ phải yêu cầu việc thực hiện đang được thử nghiệm (UIT - implementation under test) tạo ra 10 cặp khóa riêng / công khai. Khóa riêng sẽ được tạo ra bằng cách dùng một bộ sinh bit ngẫu nhiên (RBG) đã được chấp thuận. Để xác định tính chính xác, người đánh giá sẽ gửi các cặp khóa đã tạo đến chức năng xác minh khóa công khai (PKV - public key verification) của một thực hiện tốt đã biết.

Thử nghiệm xác minh khóa công khai (PKV) của FIPS 186-4 cho mỗi đường cong NIST được hỗ trợ như là P-256, P-384 và P-521, người đánh giá sẽ tạo ra 10 cặp khóa riêng / khóa công khai sử dụng chức năng tạo khóa của một thực hiện tốt đã biết và sửa đổi các giá trị khóa công khai của năm khóa để chúng không chính xác, để lại năm khóa không thay đổi giá trị. Người đánh giá sẽ phải nhận được phản hồi một bộ 10 giá trị PASS / FAIL (ĐẠT/THẤT BẠI).

Tạo khóa với FFC (Finite-Field Cryptography - mật mã trường hữu hạn)

Người đánh giá sẽ phải xác thực việc thực hiện tạo các thông số và tạo khóa cho FFC bởi TOE sử dụng thử nghiệm Tạo Thông số và Tạo Khóa. Thử nghiệm này xác minh khả năng của TSF tạo chính xác ra các giá trị cho số nguyên tố trường p, nguyên tố mật mã q (chia p-1), bộ tạo nhóm mật mã g, và tính toán khóa riêng x và khóa công khai y. Việc tạo thông số sẽ chỉ rõ 2 cách (hoặc phương pháp) để tạo ra số nguyên tố mật mã q và số nguyên tố trường p:

...

...

...

- Các số nguyên tố q và p đều là số nguyên tố có thể kiểm chứng được

- Số nguyên tố q và số nguyên tố trường p đều là số nguyên tố chắc chắn và hai cách để tạo ra bộ tạo nhóm mật mã g:

Bộ Tạo nhóm mật mã (Cryptographic Group Generator):

- Bộ tạo g được xây dựng thông qua một tiến trình có thể kiểm chứng được

- Bộ tạo g được xây dựng thông qua một tiến trình không thể kiểm chứng được.

Việc tạo khóa chỉ rõ 2 cách để tạo ra khóa riêng x: Khóa Riêng:

- len(q) bit đầu ra của RBG trong đó 1 <= x <= q-1

- len (q) + 64 bit đầu ra của RBG, được theo bởi toán hạng mod q-1 với 1 <= x <= q-1.

Độ mạnh bảo mật của RBG phải ít nhất là độ mạnh bảo mật được cung cấp bởi bộ tham số của FFC. Để kiểm tra phương pháp tạo số nguyên tố mật mã và số nguyên tố trường cho phương pháp các số nguyên tố có thể kiểm chứng được và/hoặc bộ tạo nhóm g cho một tiến trình có thể kiểm chứng được, người đánh giá cần cấy hàm tạo thông số TSF với đầy đủ dữ liệu để tạo theo cách đã định sẵn tập dữ liệu. Với mỗi độ dài khóa trợ, người đánh giá sẽ có TSF tạo 25 bộ tham số và cặp khóa. Người đánh giá sẽ phải xác nhận tính chính xác của việc thực hiện TSF bằng cách so sánh các giá trị tạo ra bởi TSF với các giá trị được tạo ra từ một thực hiện tốt đã biết. Việc xác thực cũng phải xác nhận:

...

...

...

- q chia p-1

- g ^ q mod p = 1

- g ^ x mod p = y

cho mỗi bộ tham số và cặp khóa FFC.

B.4  FCS_CKM.2 Thiết lập khóa mật mã

FCS_CKM.2.1

Ứng dụng sẽ [lựa chọn: gọi chức năng được cung cấp bởi nền tảng, thực hiện chức năng] để thực hiện thiết lập khóa mật mã theo một phương pháp thiết lập khóa mật mã đã được chỉ định:

[Lược đồ thiết lập khóa dựa trên RSA] đáp ứng: [SP 800-56B của NIST, “Khuyến nghị cho các Lược đồ Thiết lập Khóa Cặp bằng cách sử dụng mật mã phần tử số nguyên” [12]] và [lựa chọn:

[Các lược đồ thiết lập khóa dựa trên đường cong elliptic] đáp ứng: [SP 800-56A của NIST, “Khuyến nghị cho các Lược đồ Thiết lập Khóa Cặp bằng cách sử dụng mật mã Lô-ga-rít rời rạc” [11]],

...

...

...

Không lược đồ nào khác

].

Yêu cầu này tùy thuộc vào lựa chọn trong FCS_TLSC_EXT.1.1 (Điều B.9 Phụ lục B).

Lưu ý khi thực hiện: Tác giả ST sẽ chọn tất cả các lược đồ thiết lập khóa dùng cho các giao thức mật mã được chọn. FCS_TLSC_EXT.1 (Điều B.9 Phụ lục B) yêu cầu các bộ mã hóa sử dụng các lược đồ thiết lập khóa dựa trên RSA.

Các lược đồ thiết lập khóa dựa trên RSA được mô tả trong Phần 9 của SP 800-56B của NIST. Tuy nhiên, Phần 9 dựa vào việc thực hiện của các phần khác trong SP 800-56B. Nếu TOE hoạt động như nơi nhận trong lược đồ thiết lập khóa RSA, TOE không cần phải thực hiện việc tạo khóa RSA.

Các đường cong elliptic được sử dụng cho lược đồ thiết lập khóa sẽ tương quan với các đường cong được chỉ định trong FCS_CKM.1.1(1) (Điều B.3 Phụ lục B).

Các thông số miền được dùng cho lược đồ thiết lập khóa dựa trên trường hữu hạn được chỉ định bởi việc tạo khóa theo FCS_CKM.1.1(1) (Điều B.3 Phụ lục B).

Hoạt động đảm bảo:

Người đánh giá sẽ phải đảm bảo rằng các lược đồ thiết lập khóa được hỗ trợ tương ứng với các lược đồ thiết lập khóa được xác định trong FCS_CKM.1.1 (Điều B.3 Phụ lục B). Nếu ST chỉ định nhiều hơn một lược đồ, người đánh giá sẽ phải kiểm tra TSS để xác nhận rằng nó xác định cách dùng cho mỗi lược đồ.

...

...

...

Lưu ý Hoạt động đảm bảo: Các kiểm tra sau yêu cầu nhà phát triển cung cấp truy cập vào một nền tảng thử nghiệm để cung cấp cho người đánh giá các công cụ thường không có trên các sản phẩm thị trường.

Các lược đồ thiết lập khóa

Người đánh giá sẽ phải xác minh việc thực hiện các lược đồ thiết lập khóa được hỗ trợ bởi TOE bằng cách sử dụng các kiểm tra có thể áp dụng bên dưới.

Các Lược đồ Thiết lập Khóa của SP800-56A [11]

Người đánh giá sẽ phải xác minh việc thực hiện các lược đồ thỏa thuận khóa SP800-56A của TOE bằng cách sử dụng các kiểm tra Chức năng và Sự Hợp lệ sau đây. Các kiểm tra xác thực này cho mỗi lược đồ thỏa thuận khóa xác nhận rằng TOE đã triển khai các thành phần của lược đồ thỏa thuận khóa theo các đặc tính trong Khuyến nghị. Các thành phần này bao gồm tính toán các nguyên tố DLC (giá trị bí mật chia sẻ Z) và tính toán vật liệu khóa có nguồn gốc (DKM - Derived Keying Material) thông qua Chức năng Nguồn gốc Khóa (KDF - Key Derivation Function). Nếu việc xác nhận khóa được hỗ trợ, người đánh giá cũng sẽ phải xác nhận rằng các thành phần của xác nhận khóa đã được thực hiện đúng, sử dụng các thủ tục kiểm tra mô tả bên dưới. Điều này bao gồm việc phân tích DKM, tạo ra MACdata và tính toán MACtag.

Kiểm tra chức năng

Kiểm tra chức năng sẽ xác minh khả năng TOE thực hiện các lược đồ thỏa thuận khóa một cách chính xác. Để tiến hành kiểm tra này, người đánh giá sẽ phải tạo hoặc lấy các vectơ kiểm tra các lược đồ được hỗ trợ TOE từ một thực hiện tốt đã biết. Với mỗi kết hợp giữa lược đồ thỏa thuận khóa - vai trò thỏa thuận khóa được hỗ trợ, loại KDF, và nếu được hỗ trợ thêm là sự kết hợp giữa vai trò xác nhận khóa - loại xác nhận khóa, người kiểm tra sẽ phải tạo 10 bộ vectơ kiểm tra. Tập dữ liệu bao gồm một bộ giá trị thông số miền (FFC) hoặc đường cong được chấp thuận của NIST (ECC) trên 10 bộ khóa công khai. Các khóa này là tĩnh, không phù hợp hoặc cả hai tùy thuộc vào lược đồ đang được kiểm tra.

Người đánh giá sẽ nhận DKM, khóa công khai của TOE tương ứng (tĩnh và / hoặc tạm thời), thẻ MAC và bất kỳ đầu vào nào được sử dụng trong KDF, chẳng hạn như các trường Thông tin Khác (OtherInfo) và id của TOE.

Nếu TOE không sử dụng KDF đã định nghĩa trong SP 800-56A [11], người đánh giá sẽ chỉ nhận được các khóa công khai và giá trị băm (hash) của khóa bí mật được chia sẻ.

...

...

...

Nếu xác nhận khóa được hỗ trợ, TSF sẽ thực hiện như trên cho mỗi thuật toán MAC đã được chấp thuận thực hiện.

Kiểm tra hợp lệ

Kiểm tra hợp lệ sẽ xác minh khả năng TOE nhận biết kết quả thỏa thuận khóa hợp lệ và không hợp lệ của các bên khác có hoặc không có xác nhận khóa. Để thực hiện kiểm tra này, Người đánh giá sẽ phải có một danh sách các chức năng mật mã hóa hỗ trợ bao gồm trong việc thực thi thỏa thuận khóa theo SP800-56A [11] để xác định những lỗi nào TOE có thể nhận ra. Người đánh giá sẽ tạo ra một bộ 24 (FFC) hoặc 30 (ECC) vectơ kiểm tra gồm các bộ dữ liệu gồm các giá trị tham số miền hoặc các đường cong được chấp thuận của NIST, khóa công khai của người đánh giá, các cặp khóa công khai / riêng của TOE, MACTag và bất kỳ đầu vào nào được sử dụng trong KDF như các trường OtherInfo và id của TOE.

Người đánh giá sẽ chèn một lỗi vào trong các vectơ kiểm tra để kiểm tra rằng TOE nhận ra các kết quả thỏa thuận khóa không hợp lệ gây ra do các trường sau không chính xác: giá trị bí mật chia sẻ Z, DKM, trường OtherInfo, dữ liệu MACed, hoặc MACTag được tạo. Nếu TOE chứa toàn bộ hoặc một phần (chỉ ECC) xác thực khóa công khai, người đánh giá cũng sẽ chèn lỗi vào các khóa công khai tĩnh của cả hai bên, các khóa công khai tạm thời của cả hai bên và khóa riêng tĩnh của TOE để đảm bảo TOE phát hiện lỗi trong chức năng xác thực khóa công khai và / hoặc chức năng xác thực khóa một phần (chỉ trong ECC). Ít nhất hai trong số các vec tơ kiểm tra sẽ phải không thay đổi và vì vậy sẽ nhận kết quả thỏa thuận khóa hợp lệ (chúng phải đạt yêu cầu).

TOE sẽ phải sử dụng các vectơ kiểm tra đã sửa đổi này để mô phỏng lược đồ thỏa thuận khóa bằng cách dùng các tham số tương ứng. Người đánh giá sẽ phải so sánh các kết quả của TOE với kết quả của một thực hiện tốt đã biết để xác nhận rằng TOE phát hiện ra các lỗi này.

Các Lược đồ Thiết lập Khóa của SP800-56B [12]

Người đánh giá sẽ phải xác nhận rằng TSS mô tả liệu TOE có hoạt động như một người gửi, người nhận hoặc cả hai với các lược đồ thiết lập khóa dựa trên RSA.

Nếu TOE hoạt động như là người gửi, hoạt động đảm bảo sau đây sẽ phải được thực hiện để đảm bảo hoạt động thích hợp của mỗi sự kết hợp được hỗ trợ bởi TOE của lược đồ thiết lập khóa dựa trên RSA:

Để tiến hành kiểm tra này, người đánh giá sẽ phải tạo ra hoặc lấy các vectơ kiểm tra từ một thực hiện tốt đã biết các lược đồ được hỗ trợ bởi TOE. Với mỗi sự kết hợp của lược đồ thiết lập khóa được hỗ trợ và các tùy chọn của nó (có hoặc không có xác nhận khóa nếu được hỗ trợ, với mỗi chức năng MAC xác nhận khóa nếu xác nhận khóa được hỗ trợ và với mỗi chức năng tạo mặt nạ được hỗ trợ nếu KTS-OAEP được hỗ trợ), người kiểm tra sẽ phải tạo 10 bộ vectơ kiểm tra. Mỗi vectơ kiểm tra sẽ phải có khóa công khai RSA, vật liệu khóa bản rõ (KeyData), bất kỳ tham số đầu vào bổ sung nào nếu có thể áp dụng, MacKey và MacTag nếu xác nhận khóa được kết hợp, và bản mã xuất ra. Đối với mỗi vectơ kiểm tra, người đánh giá sẽ phải thực hiện một hoạt động mã hóa thiết lập khóa trên TOE với cùng đầu vào (trong các trường hợp xác nhận khóa được kết hợp, kiểm tra sẽ phải dùng MacKey từ vectơ kiểm tra thay vì MacKey được tạo ngẫu nhiên trong hoạt động thông thường) và đảm bảo rằng các bản mã xuất ra tương đương với các bản mã trong vectơ kiểm tra.

...

...

...

Để tiến hành kiểm tra này, người đánh giá sẽ phải tạo ra hoặc lấy các vectơ kiểm tra từ một thực hiện tốt đã biết các lược đồ được hỗ trợ bởi TOE. Với mỗi sự kết hợp của lược đồ thiết lập khóa được hỗ trợ và các tùy chọn của nó (có hoặc không có xác nhận khóa nếu được hỗ trợ, với mỗi chức năng MAC xác nhận khóa nếu xác nhận khóa được hỗ trợ và với mỗi chức năng tạo mặt nạ được hỗ trợ nếu KTS-OAEP được hỗ trợ), người kiểm tra sẽ phải tạo 10 bộ vectơ kiểm tra. Mỗi vectơ kiểm tra sẽ phải có khóa riêng RSA, vật liệu khóa bản rõ (KeyData), bất kỳ tham số đầu vào bổ sung nào nếu có thể, MacTag trong các trường hợp nơi xác nhận khóa được kết hợp, và bản mã xuất ra. Đối với mỗi vectơ kiểm tra, người đánh giá sẽ phải thực hiện hoạt động giải mã thiết lập khóa trên TOE và đảm bảo rằng vật liệu khóa bản rõ (plaintext) được xuất ra (KeyData) là tương đương với vật liệu khóa bản rõ trong vectơ kiểm tra. Trong trường hợp xác nhận khóa được kết hợp, người đánh giá sẽ phải thực hiện các bước xác nhận khóa và đảm bảo rằng MacTag đã xuất ra là tương đương với MacTag trong vectơ kiểm tra.

Người đánh giá sẽ phải đảm bảo rằng TSS mô tả cách TOE xử lý các lỗi giải mã. Theo SP 800-56B của NIST, TOE không được tiết lộ lỗi cụ thể đã xảy ra, hoặc thông qua nội dung của bất kỳ thông báo lỗi được xuất ra hay được ghi vào log hoặc thông qua các thay đổi về thời gian. Nếu KTS-OAEP được hỗ trợ, người đánh giá sẽ phải tạo các giá trị bản mã riêng biệt - gây nên bởi mỗi trong ba kiểm tra lỗi giải mã được mô tả trong Điều 7.2.2.3 của SP 800-56B - NIST, đảm bảo rằng mỗi nỗ lực giải mã dẫn đến lỗi và đảm bảo rằng bất kỳ thông báo lỗi được xuất ra hoặc được ghi log nào cũng giống nhau. Nếu KTS-KEM-KWS được hỗ trợ, người đánh giá sẽ phải tạo các giá trị bản mã riêng biệt - gây nên bởi mỗi một trong ba kiểm tra lỗi giải mã được mô tả trong Điều 7.2.3.3 của SP 800-56B - NIST, đảm bảo rằng mỗi nỗ lực giải mã dẫn đến lỗi, và đảm bảo rằng bất kỳ thông báo lỗi được xuất ra hoặc được ghi log là giống hệt nhau.

B.5  FCS_COP.1(1) Hoạt động mật mã - Mã hóa / Giải mã

FCS_COP.1.1(1)

Ứng dụng sẽ phải thực hiện mã hóa/ giải mã theo thuật toán mật mã cụ thể:

- Phương thức AES-CBC (như định nghĩa trong SP 800-38A [9] của NIST);

và [lựa chọn:

AES-GCM (như định nghĩa trong SP 800-38D [10] của NIST),

Không có phương thức khác

...

...

...

Yêu cầu này tùy thuộc vào lựa chọn trong FCS_TLSC_EXT.1.1 (Điều B.9 Phụ lục B), FCS_STO_EXT.1.1 (9.1.1).

Lưu ý khi thực hiện: Đối với lựa chọn đầu tiên, tác giả ST nên chọn một hoặc các phương thức trong đó AES hoạt động. Đối với lựa chọn thứ hai, tác giả ST nên chọn các kích thước khóa được hỗ trợ bởi chức năng này. Nếu được chọn, yêu cầu kích thước khóa là 128-bit để tuân thủ FCS_TLSC_EXT.1 (Điều B.9 Phụ lục B) và FCS_CKM.1(1) (Điều B.3 Phụ lục B).

Hoạt động đảm bảo:

Người đánh giá sẽ kiểm tra các tài liệu AGD để xác định rằng bất kỳ cấu hình nào cần được thực hiện để cấu hình các chức năng cho các phương thức yêu cầu và các kích cỡ khóa là có. Người đánh giá sẽ phải thực hiện tất cả các kiểm tra sau cho mỗi thuật toán được thực hiện bởi TSF và được dùng để đáp ứng các yêu cầu của PP này:

Các Kiểm tra Trả lời Đã biết AES-CBC (Known Answer Tests)

Có bốn Kiểm tra Trả lời Đã biết (KAT) được mô tả bên dưới. Trong tất cả các KAT, bản rõ, các bản mã, và các giá trị IV sẽ là các khối 128-bit. Các kết quả từ mỗi lần kiểm tra có thể thu được hoặc trực tiếp từ người đánh giá hoặc bằng cách cung cấp đầu vào cho người thực hiện và nhận kết quả trả lời. Để xác định tính chính xác, người đánh giá sẽ phải so sánh các giá trị kết quả với các giá trị đã đạt được đó bằng cách nhập các đầu vào tương tự cho nơi thực hiện tốt đã biết.

- KAT-1. Để kiểm tra chức năng mã hóa của AES-CBC, người đánh giá sẽ phải cung cấp một tập hợp gồm 10 giá trị bản rõ và nhận giá trị bản mã khi mã hóa AES-CBC của bản rõ sử dụng một giá trị khóa toàn số không và một IV của toàn số không. Năm giá trị bản rõ phải được mã hóa bằng khóa 128 bit toàn không, và năm giá trị còn lại sẽ được mã hóa bằng khóa bằng khóa 256 bit toàn không. Để kiểm tra chức năng giải mã của AES-CBC, người đánh giá sẽ phải thực hiện cùng một cách kiểm tra như mã hóa, sử dụng 10 giá trị bản mã như đầu vào và giải mã AES-CBC.

- KAT-2. Để kiểm tra chức năng mã hóa của AES-CBC, người đánh giá sẽ phải cung cấp một bộ 10 giá trị khóa và nhận giá trị bản mã từ việc mã hóa AES-CBC của một bản rõ toàn số không dùng giá trị khóa đã cho và một IV toàn số không. Năm trong số các khóa sẽ là các khóa 128-bit, còn năm khóa kia sẽ là khóa 256-bit. Để kiểm tra chức năng giải mã của AES-CBC, người đánh giá sẽ phải thực hiện cùng một kiểm tra giống như đối với mã hóa, sử dụng một giá trị mã hóa toàn số không ở đầu vào và giải mã AES-CBC.

- KAT-3. Để kiểm tra chức năng mã hóa của AES-CBC, người đánh giá sẽ phải cung cấp hai bộ giá trị khóa được mô tả bên dưới và nhận được giá trị bản mã là kết quả mã hóa AES của một bản rõ toàn số không sử dụng giá trị khóa đã cho và một IV toàn số không. Bộ khóa đầu tiên sẽ phải có 128 khóa 128-bit, và bộ thứ hai sẽ phải có 256 khóa 256-bit. Khóa i trong mỗi bộ sẽ có i bit bên trái nhất là các số một và N-i bit bên phải nhất là số không, với i trong [1, N]. Để kiểm tra chức năng giải mã của AES-CBC, người đánh giá sẽ phải cung cấp hai bộ các cặp khóa và giá trị bản mã được mô tả bên dưới và nhận giá trị bản rõ từ việc giải mã AES-CBC của một bản mã đã cho sử dụng khóa đã cho và một IV toàn số không. Bộ đầu tiên của cặp khóa / bản mã phải có 128 cặp khóa / bản mã 128-bit, và bộ thứ hai của các cặp khóa/bản mã phải có 256 cặp khóa / bản mã 256-bit. Khóa i trong mỗi bộ sẽ phải có các i bit bên trái nhất là các số một và các N-i bit bên phải nhất là các số không, với i trong [1, N]. Giá trị bản mã trong mỗi cặp sẽ phải có kết quả là bản rõ toàn số không khi giải mã với khóa tương ứng của nó.

...

...

...

Để kiểm tra chức năng giải mã của AES-CBC, người đánh giá sẽ phải thực hiện kiểm tra giống như mã hóa, sử dụng các giá trị bản mã của cùng một mẫu như bản rõ trong kiểm tra mã như đầu vào và giải mã AES-CBC.

Kiểm tra thông điệp đa khối AES-CBC (Multi-Block Message Test)

Người đánh giá sẽ phải kiểm tra chức năng mã hóa bằng cách mã hóa thông điệp i-khối, trong đó 1 < i <= 10. Người đánh giá sẽ phải chọn một khóa, một IV và một thông điệp bản rõ có độ dài i khối và mã hóa thông điệp, sử dụng phương thức kiểm tra, với khóa được chọn và IV. Bản mã sẽ được so sánh với kết quả của việc mã hóa cùng một thông điệp bản rõ với khóa và IV giống nhau, sử dụng của nơi thực hiện tốt đã biết. Người đánh giá cũng sẽ phải kiểm tra chức năng giải mã cho mỗi phương thức bằng cách giải mã một thông điệp i-khối, trong đó 1 < i <= 10. Người đánh giá sẽ phải chọn một khóa, một IV và một thông điệp bản mã có độ dài i khóa và giải mã thông điệp, sử dụng phương thức được kiểm tra, với khóa và IV được chọn. Bản rõ sẽ được so sánh với kết quả của việc giải mã cùng một thông điệp bản mã với cùng một khóa và IV sử dụng một thực hiện tốt đã biết.

Kiểm tra Monte Carlo AES-CBC

Người đánh giá sẽ phải kiểm tra chức năng mã hóa bằng cách sử dụng một bộ 200 bản rõ, IV và khóa 3 phần tử (3-tuple). 100 trong số này sẽ sử dụng các khóa 128 bit, và 100 sẽ sử dụng các khóa 256 bit. Các bản rõ và giá trị IV sẽ phải là khối 128-bit. Đối với mỗi 3-phần tử, 1000 vòng lặp sẽ được chạy như sau:

Bản mã được tính trong lần lặp thứ 1.000 (tức CT [1.000]) là kết quả của thử nghiệm đó. Kết quả này sẽ phải được so sánh với kết quả của việc chạy lặp lại 1.000 lần với các giá trị như vậy của một thực hiện tốt đã biết.

Người đánh giá sẽ kiểm tra chức năng giải mã bằng cách sử dụng cùng một thử nghiệm như mã hóa, trao đổi CT và PT và thay thế AES-CBC-Encrypt bằng AES-CBC-Decrypt.

Kiểm tra Monte Carlo AES-GCM

...

...

...

- Các khóa 128 bit và 256 bit

- Hai độ dài bản rõ. Một trong những độ dài bản rõ phải là số nguyên không phải là số không của 128 bit, nếu được hỗ trợ. Một độ dài bản mã rõ khác không phải là một số nguyên của 128 bit, nếu được hỗ trợ.

- Ba chiều dài AAD. Một chiều dài AAD sẽ là 0, nếu được hỗ trợ. Một chiều dài AAD phải là số nguyên không phải là số không của 128 bit, nếu được hỗ trợ. Một chiều dài AAD không được là một số nguyên của 128 bit, nếu được hỗ trợ.

- Hai chiều dài IV. Nếu hỗ trợ IV 96 bit, 96 bit sẽ phải là một trong hai chiều dài IV được kiểm tra.

Người đánh giá sẽ phải kiểm tra chức năng mã hóa bằng cách sử dụng bộ 10 khóa, bản rõ, AAD và IV cho mỗi sự kết hợp của các độ dài tham số ở trên và nhận giá trị bản mã và thẻ tag từ việc mã hóa được chứng thực AES-GCM. Mỗi độ dài thẻ được hỗ trợ sẽ phải được kiểm tra ít nhất một lần cho mỗi bộ 10. Giá trị IV có thể được cung cấp bởi người đánh giá hoặc việc thực hiện đang được thử nghiệm, miễn là nó đã được biết.

Người đánh giá sẽ phải kiểm tra chức năng giải mã bằng cách sử dụng bộ 10 khóa, bản mã, thẻ tag, AAD và IV 5-tuple cho mỗi sự kết hợp của các độ dài tham số ở trên và nhận được kết quả Đạt/ Thất bại trên xác thực và bản rõ được giải mã nếu Đạt. Bộ này sẽ bao gồm 5 bộ dữ liệu Đạt và 5 Thất bại.

Các kết quả từ mỗi lần kiểm tra có thể thu được hoặc trực tiếp từ người đánh giá hoặc bằng cách cung cấp đầu vào cho người thực hiện và nhận kết quả phản hồi. Để xác định tính chính xác, Người đánh giá sẽ phải so sánh các giá trị kết quả với các giá trị đã đạt được bằng cung cấp cùng các đầu vào cho một thực hiện tốt đã biết.

B.6  FCS_COP.1(2) Hoạt động mật mã - Hàm Băm (Hash)

FCS_COP.1.1(2)

...

...

...

SHA-1,

SHA-256,

SHA-384,

SHA-512,

không có các thuật toán khác

] và kích thước tiêu chuẩn thông điệp [lựa chọn:

160,

256,

384,

...

...

...

Không có kích thước tiêu chuẩn của thông điệp

] bit đáp ứng FIPS 180-4 [18].

Yêu cầu này tùy thuộc vào lựa chọn trong FCS_TLSC_EXT.1.1 (Điều B.9 Phụ lục B).

Lưu ý khi thực hiện: Theo SP 800-131A của NIST [16], SHA-1 để tạo các chữ ký số không còn được phép sử dụng và SHA-1 để xác minh chữ ký số bị từ chối mạnh vì có thể bị rủi ro khi chấp nhận các chữ ký này.

SHA-1 hiện đang được yêu cầu để tuân thủ FCS_TLSC_EXT.1 (Điều B.9 Phụ lục B). Nếu FCS_TLSC_EXT.1.1 được bao gồm trong ST, các thuật toán băm lựa chọn cho FCS_COP.1(2) (Điều B.6 Phụ lục B) phải khớp với các thuật toán băm được sử dụng trong bộ mã hóa bắt buộc và đã chọn của FCS_TLSC_EXT.1.1 (Điều B.9 Phụ lục B). Các nhà cung cấp được khuyến khích thực hiện các giao thức cập nhật hỗ trợ họ SHA-2. Cho đến có hỗ trợ của các giao thức được cập nhật, tiêu chuẩn này cho phép hỗ trợ cho việc triển khai SHA-1 phù hợp với SP 800-131A [16].

Mục đích của yêu cầu này là xác định chức năng hàm băm. Lựa chọn hàm băm phải hỗ trợ lựa chọn kích thước chuẩn của thông điệp. Lựa chọn hàm băm phải phù hợp với độ mạnh của thuật toán được sử dụng (ví dụ: SHA 256 cho các khóa 128-bit).

Hoạt động đảm bảo:

Người đánh giá sẽ phải kiểm tra rằng sự kết hợp của chức năng hàm băm với các chức năng mật mã của ứng dụng khác (ví dụ chức năng xác minh chữ ký số) được ghi lại trong TSS.

Các chức năng hàm băm TSF có thể được thực hiện ở một trong hai chế độ. Chế độ đầu tiên là chế độ theo định hướng byte. Trong chế độ này, TSF chỉ băm các thông điệp là một số nguyên của byte chiều dài; nghĩa là chiều dài (tính theo bit) của thông điệp được băm là chia hết cho 8. Chế độ thứ hai là chế độ định hướng bit. Trong chế độ này TSF sẽ băm các thông điệp có chiều dài tùy ý. Vì có các kiểm tra khác nhau cho mỗi chế độ, một dấu hiệu được đưa ra trong các phần sau cho định hướng bit so với các định hướng byte. Người đánh giá sẽ phải thực hiện tất cả các kiểm tra sau cho mỗi thuật toán băm được thực hiện bởi TSF và dùng để đáp ứng các yêu cầu của tiêu chuẩn.

...

...

...

- Kiểm tra 1: Kiểm tra các thông điệp ngắn - Chế độ định hướng bit. Người đánh giá đưa ra một bộ đầu vào bao gồm m + 1 thông điệp, trong đó m là độ dài khối của thuật toán băm. Chiều dài của các thông điệp theo thứ tự từ 0 đến m bit. Nội dung thông điệp sẽ được tạo giả ngẫu nhiên. Người đánh giá tính toán thông điệp sử dụng cho mỗi thông điệp và đảm bảo rằng kết quả chính xác được tạo ra khi các thông điệp được cung cấp cho TSF.

- Kiểm tra 2: Kiểm tra các thông điệp ngắn - Chế độ định hướng byte. Người đánh giá đưa ra một bộ đầu vào bao gồm m/8+1 thông điệp, trong đó m là độ dài khối của thuật toán băm. Chiều dài của các thông điệp theo thứ tự từ 0 đến m/8 bytes, với mỗi thông điệp là một số nguyên của các byte. Nội dung thông điệp sẽ được tạo giả ngẫu nhiên. Người đánh giá tính toán thông điệp sử dụng cho mỗi thông điệp và đảm bảo rằng kết quả chính xác được tạo ra khi các thông điệp được cung cấp cho TSF

- Kiểm tra 3: Chọn Kiểm tra các thông điệp dài - Chế độ định hướng bit. Người đánh giá đưa ra một bộ đầu vào bao gồm m thông điệp, trong đó m là độ dài khối của thuật toán băm. Độ dài của thông điệp thứ i là 512 + 99xi, trong đó 1 ≤ i ≤ m. Nội dung thông điệp sẽ được tạo giả ngẫu nhiên. Người đánh giá tính toán thông điệp sử dụng cho mỗi thông điệp và đảm bảo rằng kết quả chính xác được tạo ra khi các thông điệp được cung cấp cho TSF.

- Kiểm tra 4: Chọn Kiểm tra các thông điệp dài - Chế độ định hướng byte. Người đánh giá đưa ra một bộ đầu vào bao gồm m/8 thông điệp, trong đó m là độ dài khối của thuật toán băm. Độ dài của thông điệp thứ i là 512 + 8x99xi, trong đó 1 ≤ i ≤ m/8. Nội dung của thông điệp sẽ được tạo giả ngẫu nhiên. Người đánh giá tính toán thông điệp sử dụng cho mỗi thông điệp và đảm bảo rằng kết quả chính xác được tạo ra khi các thông điệp được cung cấp cho TSF

- Kiểm tra 5: Kiểm tra các Thông điệp Tạo Giả Ngẫu nhiên. Kiểm tra này chỉ dành cho việc triển khai theo định hướng byte. Người đánh giá tạo ngẫu nhiên một hạt giống là n bit dài, trong đó n là chiều dài của thông điệp sử dụng được tạo ra bởi chức năng băm để được kiểm tra. Sau đó, người đánh giá lập một bộ 100 thông điệp và các sử dụng liên quan bằng cách thực hiện theo thuật toán được cung cấp trong Hình 1 của [SHAVS] (tham khảo [22]). Sau đó, người đánh giá đảm bảo rằng kết quả chính xác được tạo ra khi các thông điệp được cung cấp cho TSF.

B.7  FCS_COP.1(3) Thao tác mã hóa - Ký tên

FCS_COP.1.1(3)

TOE sẽ phải thực hiện các dịch vụ ký mật mã (tạo và xác thực) theo một thuật toán mật mã cụ thể [lựa chọn:

Các lược đồ RSA sử dụng các kích thước khóa mật mã 2048-bit trở lên đáp ứng FIPS PUB 186-4, “Tiêu chuẩn Chữ ký Số (DSS)”, Điều 4 [19],

...

...

...

].

Yêu cầu này tùy thuộc vào lựa chọn trong FCS_TLSC_EXT.1.1 (Điều B.9 Phụ lục B).

Lưu ý khi thực hiện: Tác giả ST nên chọn thuật toán triển khai để thực hiện chữ ký số; nếu có sẵn nhiều hơn một thuật toán, yêu cầu này nên được lặp lại để xác định các chức năng. Với thuật toán đã chọn, tác giả ST nên thực hiện các nhiệm vụ / lựa chọn thích hợp để xác định các tham số được thực hiện cho thuật toán đó. Việc tạo và xác thực chữ ký RSA hiện đang được yêu cầu để tuân thủ FCS_TLSC_EXT.1 (Điều B.9 Phụ lục B).

Hoạt động đảm bảo:

Người đánh giá sẽ phải thực hiện các hoạt động sau dựa trên các lựa chọn trong ST.

Các thử nghiệm sau đây yêu cầu nhà phát triển cung cấp quyền truy cập vào một ứng dụng thử nghiệm để cấp cho người đánh giá các công cụ thường không có trong ứng dụng phát hành.

Các Kiểm tra Thuật toán ECDSA

- Kiểm tra 1: Thử nghiệm tạo chữ ký FIPS 186-4 của ECDSA. Đối với mỗi đường cong NIST được hỗ trợ (ví dụ: P-256, P-384 và P-521) và cặp chức năng SHA, người đánh giá sẽ tạo ra 10 thông điệp dài 1024-bit và nhận một khóa công khai và các giá trị chữ ký kết quả R và S cho mỗi thông điệp. Để xác định tính chính xác, người đánh giá sẽ phải dùng chức năng xác thực chữ ký của một thực hiện tốt đã biết.

- Kiểm tra 2: Kiểm tra xác thực Chữ ký FIPS 186-4 của ECDSA. Đối với mỗi đường cong NIST được hỗ trợ (ví dụ: P-256, P-384 và P-521) và cặp chức năng SHA, người đánh giá sẽ tạo ra một bộ 10 thông điệp 1024-bit, khóa công khai và các danh sách chữ ký và sửa đổi một trong các giá trị (thông điệp, khóa công khai hoặc chữ ký) của năm trong số 10 bộ. Người đánh giá sẽ phải nhận được phản hồi một bộ 10 giá trị Đạt / Thất bại

...

...

...

- Kiểm tra 1: Kiểm tra Tạo Chữ ký. Người đánh giá sẽ phải xác nhận việc thực hiện Tạo Chữ ký RSA bằng TOE sử dụng Kiểm tra Tạo Chữ ký. Để tiến hành kiểm tra này, người đánh giá phải tạo ra hoặc nhận được 10 thông điệp từ một sự thực hiện tham chiếu đáng tin cho mỗi kết hợp kích cỡ mô-đun / SHA được hỗ trợ bởi TSF. Người đánh giá sẽ phải có TOE sử dụng khóa riêng của chúng và giá trị mô-đun để ký các thông báo này. Người đánh giá sẽ xác thực tính chính xác của chữ ký của TSF bằng cách sử dụng một thực hiện tốt đã biết và các khóa công khai liên quan để xác minh chữ ký.

- Kiểm tra 2: Kiểm tra Xác thực Chữ ký. Người đánh giá sẽ phải thực hiện Kiểm tra Xác thực Chữ ký để xác nhận khả năng của TOE nhận ra các chữ ký hợp lệ và không hợp lệ của một bên khác. Người đánh giá sẽ phải đưa lỗi vào vectơ kiểm tra được tạo ra trong quá trình Kiểm tra Xác thực Chữ ký bằng cách đưa ra các lỗi trong một số khóa công khai, e, các thông điệp, định dạng IR và / hoặc các chữ ký. TOE sẽ cố gắng xác minh chữ ký và trả lại kết quả là thành công hoặc thất bại.

B.8  FCS_COP.1(4) Hoạt động mật mã - Xác thực Thông điệp Khóa Băm (Keyed-Hash)

FCS_COP.1.1(4)

Ứng dụng sẽ phải thực hiện xác thực thông điệp khóa-băm theo một thuật toán mật mã được chỉ định

• HMAC-SHA-256

và [lựa chọn:

SHA-1,

SHA-384,

...

...

...

không có thuật toán khác

] với các kích cỡ khóa [chỉ định: kích thước khóa (theo bit) được dùng trong HMAC] và kích thước tiêu chuẩn của thông điệp là 256 và [lựa chọn: 160, 384, 512, không có kích thước khác] bit đáp ứng FIPS 198-1 Mã Xác thực Thông điệp Khóa Băm (tham khảo [20]) và FIPS 180-4 Tiêu chuẩn Băm An toàn (tham khảo [18]).

Yêu cầu này tùy thuộc vào lựa chọn trong FCS_TLSC_EXT.1.1 (Điều B.9 Phụ lục B).

Lưu ý khi thực hiện: Mục đích của yêu cầu này là chỉ định chức năng xác thực thông điệp khóa băm được dùng cho mục đích thiết lập khóa cho các giao thức mật mã khác nhau dùng bởi ứng dụng (ví dụ: kênh tin cậy). Lựa chọn băm phải hỗ trợ lựa chọn kích thước tiêu chuẩn của thông điệp. Lựa chọn băm phải phù hợp với độ mạnh chung của thuật toán được sử dụng cho FCS_COP.1(1) (Điều B.5 Phụ lục B). HMAC-SHA256 được yêu cầu để tuân thủ các bộ mã yêu cầu trong FCS_TLSC_EXT.1.

Hoạt động đảm bảo:

Người đánh giá sẽ phải thực hiện các hoạt động sau dựa trên các lựa chọn trong ST.

Đối với mỗi bộ tham số được hỗ trợ, người đánh giá sẽ phải tạo ra 15 bộ dữ liệu kiểm tra. Mỗi bộ sẽ bao gồm một khóa và dữ liệu của thông điệp. Người đánh giá sẽ phải có TSF tạo các thẻ HMAC cho các bộ dữ liệu kiểm tra này. Các thẻ MAC kết quả sẽ phải được so sánh với kết quả của việc tạo các thẻ HMAC có cùng khóa và IV bằng cách sử dụng một thực hiện tốt đã biết.

B.9  FCS_TLSC_EXT.1 Giao thức Máy khách của TLS

FCS_TLSC_EXT.1.1

...

...

...

Bộ mã bắt buộc: TLS_RSA_WITH_AES_128_CBC_SHA theo định nghĩa trong RFC 5246

Bộ mã tùy chọn: [lựa chọn:

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 như được định nghĩa trong RFC 5246,

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 như được định nghĩa trong RFC 5246,

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 như được định nghĩa trong RFC 5289,

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 như được định nghĩa trong RFC 5289,

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 như được định nghĩa trong RFC 5289,

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 như được định nghĩa trong RFC 5289,

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 như được định nghĩa trong RFC 5289,

...

...

...

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 như được định nghĩa trong RFC 5289,

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 như được định nghĩa trong RFC 5289,

TLS_RSA_WITH_AES_128_CBC_SHA256 như được định nghĩa trong RFC 5246,

TLS_RSA_WITH_AES_256_CBC_SHA256 như được định nghĩa trong RFC 5246,

Không có bộ mã khác].

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

Lưu ý khi thực hiện: Các bộ mã được kiểm tra trong cấu hình đánh giá được giới hạn bởi yêu cầu này. Tác giả ST nên chọn các bộ mã tùy chọn được hỗ trợ; nếu không có bộ mã được hỗ trợ ngoài các bộ bắt buộc, thì sẽ chọn “None”. Cần hạn chế các bộ mã có thể được sử dụng trong một cấu hình đánh giá quản trị trên máy chủ trong môi trường thử nghiệm. Các thuật toán Suite B được liệt kê ở trên (RFC 6460) là các thuật toán được ưa thích để thực hiện. TLS_RSA_WITH_AES_128_CBC_SHA là bắt buộc để đảm bảo tuân thủ RFC 5246.

Các yêu cầu này sẽ được xem xét lại khi các phiên bản TLS mới được chuẩn hóa bởi IETF.

Nếu bất kỳ bộ mã nào được chọn bằng cách sử dụng ECDHE, thì FCS_TLSC_EXT.4 là bắt buộc.

...

...

...

Hoạt động đảm bảo:

Người đánh giá sẽ phải kiểm tra mô tả về việc triển khai của giao thức này trong TSS để đảm bảo rằng chỉ định các bộ mã được hỗ trợ. Người đánh giá sẽ phải kiểm tra TSS để đảm bảo rằng các bộ mã được chỉ định bao gồm các bộ mã được liệt kê cho thành phần này. Người đánh giá cũng sẽ phải kiểm tra hướng dẫn hoạt động để đảm bảo rằng nó có các chỉ dẫn về cấu hình TOE để TLS phù hợp với mô tả trong TSS. Người đánh giá cũng sẽ phải thực hiện các kiểm tra sau:

- Kiểm tra 1: Người đánh giá sẽ phải thiết lập kết nối TLS bằng cách sử dụng mỗi bộ mã được chỉ định theo yêu cầu. Kết nối này có thể được thiết lập như một phần của việc thiết lập một giao thức cấp cao hơn, ví dụ như là một phần của một phiên EAP. Chỉ cần quan sát việc đàm phán thành công một bộ mã để đáp ứng mục đích của kiểm tra; không cần phải kiểm tra các đặc tính của lưu lượng đã mã hóa để phân biệt bộ mã đang được dùng (ví dụ, thuật toán mật mã là AES 128-bit chứ không phải là AES 256-bit).

- Kiểm tra 2: Người đánh giá sẽ phải cố thiết lập kết nối bằng cách sử dụng một máy chủ với chứng chỉ máy chủ có chứa mục đích Xác thực Máy chủ (Server Authentication) trong trường extendedKeyUsage và xác nhận rằng kết nối đã được thiết lập. Người đánh giá sau đó sẽ xác minh rằng máy khách từ chối chứng chỉ máy chủ hợp lệ khác mà thiếu mục đích Xác thực Máy chủ trong trường extendedKeyUsage và kết nối không được thiết lập. Một cách lý tưởng là hai chứng chỉ phải giống hệt nhau, ngoại trừ trường extendedKeyUsage.

- Kiểm tra 3: Người đánh giá sẽ phải gửi chứng chỉ máy chủ trong kết nối TLS không khớp với bộ mã của máy chủ đã chọn (ví dụ: gửi chứng chỉ ECDSA trong khi sử dụng bộ mật mã TLS_RSA_WITH_AES_128_CBC_SHA hoặc gửi chứng chỉ RSA trong khi sử dụng một trong các bộ mật mã ECDSA.) Người đánh giá sẽ phải xác nhận rằng TOE sẽ ngắt kết nối sau khi nhận được thông điệp bắt tay Chứng chỉ (Certificate handshake message) của máy chủ.

- Kiểm tra 4: Người đánh giá sẽ phải cấu hình máy chủ để chọn bộ mã TLS_NULL_WITH_NULL_NULL và xác thực rằng máy khách từ chối kết nối.

- Kiểm tra 5: Người đánh giá sẽ phải thực hiện những thay đổi sau đến lưu lượng:

• Kiểm tra 5.1: Sửa đổi phiên bản TLS được chọn bởi máy chủ trong Server Hello đến phiên bản TLS không được hỗ trợ (ví dụ 1.3 đại diện cho hai byte 03 04) và xác nhận rằng máy khách từ chối kết nối.

• Kiểm tra 5.2: Sửa đổi ít nhất một byte trong nonce của máy chủ trong thông điệp bắt tay Server Hello, và xác nhận rằng máy khách từ chối thông điệp bắt tay Trao đổi Khóa Máy chủ (Key Exchange handsahke message) (nếu sử dụng một bộ mã DHE hoặc ECDHE) hoặc máy chủ từ chối thông điệp bắt tay Kết thúc (Finished handshake message) của máy khách.

...

...

...

• Kiểm tra 5.4: Sửa đổi khối chữ ký trong thông điệp bắt tay Trao đổi Khóa (KeyExchange handshake message) của Máy chủ và xác thực rằng máy khách từ chối kết nối sau khi nhận được thông điệp Trao đổi Khóa của Máy chủ (Server Key Exchange message).

• Kiểm tra 5.5: Sửa đổi một byte trong thông điệp bắt tay đã Hoàn thành của máy chủ, và xác thực rằng máy khách gửi một cảnh báo xấu khi nhận và không gửi bất kỳ dữ liệu nào của ứng dụng.

• Kiểm tra 5.6: Gửi một thông điệp bị cắt xén từ máy chủ sau khi máy chủ đã phát thông điệp ChangeCipherSpec và xác nhận rằng máy khách từ chối kết nối.

FCS_TLSC_EXT.1.2

Ứng dụng sẽ phải xác nhận rằng bộ định danh được trình bày phù hợp với bộ định danh tham chiếu theo RFC 6125.

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

Lưu ý khi thực hiện: Các quy tắc xác thực định danh được mô tả trong điều 6 của RFC 6125. Bộ định danh tham chiếu được thiết lập bởi người dùng (ví dụ như nhập URL vào một trình duyệt web hoặc nhấp vào liên kết), bởi việc cấu hình (ví dụ như cấu hình tên của máy chủ thư hoặc máy chủ xác thực), hoặc bởi một ứng dụng (ví dụ như một tham số của một API) tùy thuộc vào dịch vụ của ứng dụng. Dựa vào miền tài nguyên và loại dịch vụ ứng dụng của bộ định danh tham chiếu (ví dụ HTTP, SIP, LDAP), máy khách sẽ thiết lập tất cả các bộ định danh tham chiếu được chấp nhận, chẳng hạn như Common Name cho trường Subject Name của chứng chỉ và một tên DNS, tên URI và Service Name cho trường Subject Alternative Name. Sau đó máy khách sẽ so sánh danh sách này của tất cả các bộ định danh tham chiếu chấp nhận được với các bộ định danh được trình bày trong chứng chỉ của máy chủ TLS.

Phương pháp được ưa thích để xác thực Subject Alternative Name sử dụng các tên DNS, các tên URI, hoặc các Service Name. Yêu cầu xác thực dùng Common Name cho mục đích tương thích ngược. Ngoài ra, việc hỗ trợ sử dụng các địa chỉ IP trong Subject Name hoặc tên của Subject Alternative sẽ không được khuyến khích như những thực hành tốt nhất nhưng có thể thực hiện được. Cuối cùng, máy khách nên tránh xây dựng các bộ định danh tham chiếu sử dụng ký tự đại diện. Tuy nhiên, nếu các bộ định danh được trình bày có các ký tự đại diện, máy khách phải tuân theo các phương pháp thực hành tốt nhất về kết hợp; những thực hành tốt nhất này được ghi lại trong hoạt động đảm bảo.

Hoạt động đảm bảo:

...

...

...

Người đánh giá sẽ phải xác nhận rằng hướng dẫn AGD bao gồm các chỉ dẫn để thiết đặt bộ định danh tham chiếu được sử dụng cho mục đích chứng thực hợp lệ trong TLS.

Người đánh giá sẽ phải cấu hình bộ định danh tham chiếu theo hướng dẫn AGD và thực hiện các kiểm tra sau đây trong quá trình kết nối TLS:

- Kiểm tra 1: Người đánh giá sẽ phải đưa ra một chứng chỉ máy chủ không chứa một bộ định danh hoặc là Subject Alternative Name (SAN) hoặc là Common Name (CN) phù hợp với bộ định danh tham chiếu. Người đánh giá sẽ phải xác nhận kết nối không thành công.

- Kiểm tra 2: Người đánh giá sẽ phải đưa ra một chứng chỉ máy chủ có chứa một CN phù hợp với bộ định danh tham chiếu, chứa phần mở rộng SAN, nhưng không chứa một bộ định danh trong SAN phù hợp với bộ định danh tham chiếu. Người đánh giá sẽ phải xác nhận rằng kết nối không thành công. Người đánh giá sẽ phải lặp lại thử nghiệm này cho mỗi loại SAN được hỗ trợ.

- Kiểm tra 3: Người đánh giá sẽ phải đưa ra một chứng chỉ máy chủ có chứa một CN phù hợp với bộ định danh tham chiếu và không chứa phần mở rộng SAN. Người đánh giá sẽ phải xác nhận rằng kết nối thành công.

- Kiểm tra 4: Người đánh giá sẽ phải đưa ra một chứng chỉ máy chủ có chứa một CN không phù hợp với bộ định danh tham chiếu nhưng chứa một bộ định danh trong SAN phù hợp. Người đánh giá sẽ phải xác nhận rằng kết nối thành công.

- Kiểm tra 5: Người đánh giá sẽ phải thực hiện các kiểm tra ký tự đại diện sau với mỗi loại bộ định danh tham chiếu được hỗ trợ:

• Kiểm tra 5.1: Người đánh giá sẽ phải đưa ra chứng chỉ máy chủ chứa ký tự đại diện không nằm trong nhãn phía bên trái nhất của bộ định danh được trình bày (ví dụ foo.*.example.com) và xác thực rằng kết nối không thành công.

• Kiểm tra 5.2: Người đánh giá sẽ phải đưa ra chứng chỉ máy chủ có chứa ký tự đại diện trong nhãn phía bên trái nhất nhưng không phải trước hậu tố công khai (ví dụ: *.example.com). Người đánh giá sẽ phải cấu hình bộ định danh tham chiếu với một nhãn đơn phía bên trái nhất (ví dụ: foo.example.com) và xác nhận rằng kết nối thành công. Người đánh giá sẽ phải cấu hình bộ định danh tham chiếu không có nhãn phía bên trái nhất như trong chứng chỉ (ví dụ example.com) và xác nhận rằng kết nối không thành công. Người đánh giá sẽ phải cấu hình bộ định danh tham chiếu với hai phía bên trái nhất (ví dụ: bar.foo.example.com) và xác nhận rằng kết nối không thành công.

...

...

...

- Kiểm tra 6: [có điều kiện] Nếu các bộ định danh tham chiếu URI hoặc tên Service được hỗ trợ, người đánh giá sẽ phải cấu hình tên DNS và bộ định danh dịch vụ. Người đánh giá sẽ phải đưa ra chứng chỉ máy chủ có chứa tên DNS chính xác và bộ định danh dịch vụ trong các trường URIName hoặc SRVName của SAN và xác nhận rằng kết nối thành công. Người đánh giá sẽ phải lặp lại thử nghiệm này với bộ định danh dịch vụ sai (nhưng đúng tên DNS) và xác nhận rằng kết nối không thành công.

- Kiểm tra 7: [có điều kiện] Nếu các chứng chỉ ghim được hỗ trợ, người đánh giá sẽ phải đưa ra chứng chỉ không khớp với chứng chỉ ghim và xác nhận rằng kết nối không thành công.

FCS_TLSC_EXT.1.3

Ứng dụng sẽ chỉ thiết lập một kênh đáng tin nếu chứng chỉ ngang hàng là hợp lệ.

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

Lưu ý khi thực hiện: Hiệu lực được xác định bằng xác thực bộ định danh, đường dẫn chứng chỉ, ngày hết hạn, và trạng thái thu hồi theo RFC 5280. Hiệu lực của chứng chỉ hợp lệ sẽ phải được kiểm tra theo các thử nghiệm được thực hiện cho FIA_X509_EXT.1 (Điều B.14 Phụ lục B).

Đối với kết nối TLS, kênh này sẽ không được thiết lập nếu chứng chỉ ngang hàng không hợp lệ. Giao thức HTTPS (FCS_HTTPS_EXT.1 (Điều B.13 Phụ lục B)) yêu cầu hành vi khác nhau, mặc dù HTTPS được thực hiện trên TLS. Yếu tố này cung cấp các kết nối TSL không phải HTTPS.

Hoạt động đảm bảo:

Người đánh giá sẽ phải dùng TLS như là một chức năng để xác minh rằng các quy tắc xác thực trong FIA_X509_EXT.1.1 (Điều B.14 Phụ lục B) được tuân thủ và sẽ phải thực hiện kiểm tra bổ sung sau đây:

...

...

...

B.10  FCS_TLSC_EXT.4 Giao thức Máy khách của TLS

FCS_TLSC_EXT.4.1

Ứng dụng sẽ trình bày Mở rộng các Đường cong En-líp (Elliptic Curves Extension) được hỗ trợ trong Client Hello với các đường cong NIST sau: [lựa chọn: secp256r1, secp384r1, secp521r1] và không có đường cong khác.

Yêu cầu này tùy thuộc vào việc lựa chọn trong FCS_TLSC_EXT.1.1 (Điều B.9 Phụ lục), FCS_TLSC_EXT.1.1 (Điều B.11 Phụ lục B).

Lưu ý khi thực hiện: Yêu cầu này sẽ giới hạn các đường cong elliptic được phép cho việc xác thực và thỏa thuận khóa với các đường cong NIST từ FCS_COP.1(3) (Điều B.7 Phụ lục B), FCS_CKM.1(1) (Điều B.3 Phụ lục B) và FCS_CKM.2 (Điều B.4 Phụ lục B). Phần mở rộng này là bắt buộc đối với máy khách hỗ trợ bộ mã đường cong en-líp.

Hoạt động đảm bảo:

Người đánh giá sẽ phải xác nhận TSS mô tả Mở rộng các Đường Cong En-líp (Elliptic Curves Extension) được hỗ trợ và liệu hành vi yêu cầu là được thực hiện mặc định hay có thể được cấu hình. Nếu TSS chỉ ra rằng Mở rộng các Đường Cong En-líp (Elliptic Curves Extension) được hỗ trợ phải được cấu hình để đáp ứng yêu cầu, người đánh giá sẽ phải xác nhận rằng hướng dẫn AGD có hỗ trợ cấu hình Elliptic Curves Extension.

Người đánh giá cũng sẽ phải thực hiện các kiểm tra sau:

- Kiểm tra 1: Người đánh giá sẽ phải cấu hình máy chủ để thực hiện một thông điệp trao đổi khóa ECDHE trong kết nối TLS bằng cách sử dụng đường cong ECDHE không được hỗ trợ (ví dụ, P-192) và sẽ phải xác thực rằng TOE ngắt kết nối sau khi nhận được thông điệp bắt tay Trao đổi Khóa (Key Exchange handshake message) của máy chủ.

...

...

...

FCS_TLSS_EXT.1.1

Ứng dụng sẽ [lựa chọn: gọi TLS 1.2 được nền tảng cung cấp, thực hiện TLS 1.2 (RFC 5246)] hỗ trợ các bộ mã sau đây:

Các bộ mã bắt buộc: TLS_RSA_WITH_AES_128_CBC_SHA như định nghĩa trong RFC 5246.

Các bộ mã tùy chọn: [lựa chọn:

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 như được định nghĩa trong RFC 5246,

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 như được định nghĩa trong RFC 5246,

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 như được định nghĩa trong RFC 5289,

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 như được định nghĩa trong RFC 5289,

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 như được định nghĩa trong RFC 5289,

...

...

...

TLS_ECDHE_RSA_ WITH_AES_128_CBC_SHA256 như được định nghĩa trong RFC 5289,

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 như được định nghĩa trong RFC 5289,

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 như được định nghĩa trong RFC 5289,

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 như được định nghĩa trong RFC 5289,

TLS_RSA_WITH_AES_128_CBC_SHA256 như được định nghĩa trong RFC 5246,

TLS_RSA_WITH_AES_256_CBC_SHA256 như được định nghĩa trong RFC 5246,

không có bộ mã khác

].

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

...

...

...

Các yêu cầu này sẽ được xem xét lại ở các phiên bản TLS mới được tiêu chuẩn hóa bởi IETF.

Nếu bất kỳ bộ mã nào được chọn bằng cách sử dụng ECDHE, thì FCS_TLSC_EXT.4 là bắt buộc.

Nếu chọn “thực hiện TLS 1.2 (RFC 5246)”, thì FCS_CKM.2.1 (Điều B.4 Phụ lục B), FCS_COP.1.1(1) (Điều B.5 Phụ lục B), FCS_COP.1.1(2) (Điều B.6 Phụ lục B), FCS_COP.1.1(3) (Điều B.7 Phụ lục B) và FCS_COP.1.1(4) (Điều B.8 Phụ lục B) là bắt buộc.

Hoạt động đảm bảo:

Người đánh giá sẽ phải kiểm tra mô tả về việc triển khai của giao thức này trong TSS để đảm bảo rằng sử dụng các bộ mã được hỗ trợ. Người đánh giá sẽ phải kiểm tra TSS để đảm bảo rằng các bộ mã được chỉ định được liệt kê cho thành phần này. Người đánh giá cũng sẽ phải kiểm tra hướng dẫn vận hành để đảm bảo rằng nó chứa các chỉ dẫn về cấu hình TOE để TLS phù hợp với mô tả trong TSS. Người đánh giá cũng sẽ phải thực hiện các kiểm tra sau:

- Kiểm tra 1: Người đánh giá sẽ phải thiết lập một kết nối TLS bằng cách sử dụng mỗi một trong các bộ mã được chỉ định theo yêu cầu. Kết nối này có thể được thiết lập như một phần của việc thiết lập một giao thức cấp cao hơn, ví dụ như là một phần của một phiên EAP. Chỉ cần quan sát việc đàm phán thành công một bộ mã để đáp ứng mục đích của kiểm tra; không cần phải kiểm tra các đặc tính của lưu lượng đã mã hóa để phân biệt bộ mã đang được dùng (ví dụ, thuật toán mật mã là AES 128-bit chứ không phải là AES 256-bit).

- Kiểm tra 2: Người đánh giá sẽ phải gửi Client Hello tới máy chủ với một danh sách các bộ mã không chứa bất kỳ một bộ mã nào trong ST của máy chủ và xác minh rằng máy chủ đã từ chối kết nối. Ngoài ra, người đánh giá sẽ phải gửi một Client Hello tới máy chủ chỉ chứa bộ mã TLS_NULL_WITH_NULL_NULL và xác nhận rằng máy chủ sẽ từ chối kết nối.

- Kiểm tra 3: Người đánh giá sẽ phải sử dụng một máy khách để gửi một thông điệp trao đổi khóa trong kết nối TLS không khớp với bộ mã của máy chủ được chọn (ví dụ gửi một trao đổi khóa ECDHE trong khi sử dụng bộ mã TLS_RSA_WITH_AES_128_CBC_SHA hoặc gửi một trao đổi khóa RSA trong khi sử dụng một trong các bộ mã ECDSA) Người đánh giá sẽ phải xác nhận rằng ứng dụng ngắt kết nối sau khi nhận được thông điệp trao đổi khóa.

- Kiểm tra 4: Người đánh giá sẽ phải thực hiện các sửa đổi sau cho lưu lượng:

...

...

...

• Kiểm tra 4.2: Sửa đổi ít nhất một byte trong nonce của máy khách trong thông điệp bắt tay Client Hello, và xác nhận rằng máy chủ từ chối thông điệp bắt tay Certificate Verify của máy khách (nếu sử dụng chứng thực lẫn nhau) hoặc máy chủ từ chối thông điệp bắt tay Đã hoàn tất (Finished handshake message) của máy khách.

• Kiểm tra 4.3: Sửa đổi khối chữ ký trong thông điệp bắt tay Trao đổi Khóa (Key Exchange handshake message) của máy khách và xác nhận rằng máy chủ từ chối thông điệp bắt tay Xác nhận Chứng chỉ (Certificate Verify handshake message) của máy khách (nếu sử dụng chứng thực lẫn nhau) hoặc máy chủ từ chối thông điệp bắt tay Đã hoàn tất (Finished handshake message) của máy khách.

• Kiểm tra 4.4: Sửa đổi một byte trong thông điệp bắt tay Đã Hoàn tất (Finished handshake message) của máy khách và xác nhận rằng máy chủ từ chối kết nối và không gửi bất kỳ dữ liệu ứng dụng nào.

• Kiểm tra 4.5: Sau khi tạo ra một cảnh báo nghiêm trọng bằng cách gửi một thông điệp Đã Hoàn tất (Finished message) từ máy khách trước khi máy khách gửi thông điệp ChangeCipherSpec, hãy gửi Client Hello với bộ định danh phiên từ thử nghiệm trước và xác nhận rằng máy chủ từ chối kết nối.

• Kiểm tra 4.6: Gửi một thông điệp bị cắt xén từ máy khách sau khi máy khách đã phát hành thông điệp ChangeCipherSpec và xác nhận rằng máy chủ từ chối kết nối.

FCS_TLSS_EXT.1.2

Ứng dụng sẽ từ chối kết các nối từ các máy khách đòi hỏi SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, và [lựa chọn: TLS 1.2, none].

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

Lưu ý khi thực hiện: Tất cả phiên bản SSL và TLS 1.0 và 1.1 bị từ chối. Bất kỳ phiên bản TLS nào không được chọn trong FCS_TLSS_EXT.1.1 (Điều B.11 Phụ lục B) nên được chọn ở đây.

...

...

...

Người đánh giá sẽ phải xác nhận rằng TSS chứa mô tả về việc từ chối các phiên bản SSL và TLS cũ, và bất kỳ cấu hình nào cần thiết để đáp ứng yêu cầu phải được chứa trong hướng dẫn AGD.

- Kiểm tra 1: Người đánh giá sẽ phải gửi Client Hello yêu cầu kết nối với phiên bản SSL 2.0 và xác thực rằng máy chủ từ chối kết nối. Người đánh giá sẽ phải lặp lại thử nghiệm này với SSL 3.0, TLS 1.0, TLS 1.1 và TLS 1.2 nếu nó được chọn.

FCS_TLSS_EXT.1.3

Ứng dụng sẽ tạo các tham số thiết lập khóa dùng RSA với kích thước 2048 bit và [lựa chọn: 3072 bit, 4096 bit, không có kích thước khác] và [lựa chọn: qua các đường cong [lựa chọn: secp256r, secp384r] NIST và không có đường cong khác, các tham số Diffe-Hellman của kích thước 2048 và [lựa chọn: 3072 bits, không có kích thước khác], không có khác].

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

Lưu ý khi thực hiện: Nếu ST liệt kê một bộ mã DHE trong FCS_TLSS_EXT.1.1 (Điều B.11 Phụ lục B), ST phải bao gồm lựa chọn Diffie-Hellman trong yêu cầu.

Hoạt động đảm bảo:

Người đánh giá sẽ phải xác nhận rằng TSS mô tả các thông số thỏa thuận khóa của thông điệp trao đổi khóa máy chủ.

Người đánh giá sẽ phải xác thực rằng bất kỳ hướng dẫn cấu hình nào cần thiết để đáp ứng yêu cầu phải có trong hướng dẫn AGD.

...

...

...

FCS_TLSS_EXT.1.4

Ứng dụng sẽ hỗ trợ chứng thực lẫn nhau của các máy khách TLS sử dụng chứng chỉ X.509v3.

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

FCS_TLSS_EXT.1.5

Ứng dụng sẽ không thiết lập một kênh tin cậy nếu chứng chỉ ngang hàng không hợp lệ.

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

Lưu ý khi thực hiện: Việc dùng các chứng chỉ X.509v3 với TLS được đề cập trong FIA_X509_EXT.2.1 (Điều B.15 Phụ lục B). Yêu cầu này bổ sung rằng việc sử dụng này phải bao gồm hỗ trợ cho các chứng chỉ phía máy khách để chứng thực lẫn nhau TLS. Hiệu lực được xác định bởi đường dẫn chứng chỉ, ngày hết hạn và trạng thái thu hồi theo RFC 5280. Hiệu lực của chứng chỉ sẽ được kiểm tra phù hợp với thử nghiệm thực hiện cho FIA_X509_EXT.1 (Điều B.14 Phụ lục B).

Hoạt động đảm bảo:

Người đánh giá sẽ phải đảm bảo rằng mô tả TSS yêu cầu cho mỗi FIA_X509_EXT.2.1 (Điều B.15 Phụ lục B) sẽ bao gồm việc sử dụng các chứng chỉ phía máy khách để chứng thực lẫn nhau TLS.

...

...

...

- Kiểm tra 1: Người đánh giá sẽ phải cấu hình máy chủ để gửi yêu cầu chứng chỉ cho máy khách và sẽ cố kết nối mà không cần gửi chứng chỉ từ máy khách. Người đánh giá sẽ phải xác nhận rằng kết nối bị từ chối.

- Kiểm tra 2: Người đánh giá sẽ phải cấu hình máy chủ để gửi yêu cầu chứng chỉ cho máy khách mà không có supported_signature_algorithm (thuật toán chữ ký được hỗ trợ) được dùng bởi chứng chỉ của máy khách. Người đánh giá sẽ phải cố kết nối bằng chứng chỉ máy khách và xác nhận rằng kết nối bị từ chối.

- Kiểm tra 3: Người đánh giá sẽ chứng minh rằng sử dụng một chứng chỉ mà không có một đường dẫn chứng nhận hợp lệ sẽ dẫn đến chức năng thất bại. Bằng cách sử dụng hướng dẫn quản trị, người đánh giá sẽ tải một chứng chỉ hoặc các chứng chỉ thiết để xác nhận hợp lệ chứng chỉ được sử dụng trong chức năng và chứng minh rằng chức năng đó thành công. Người đánh giá sau đó sẽ xóa một trong các chứng chỉ, và chỉ ra rằng chức năng không thành công.

- Kiểm tra 4: Người đánh giá sẽ phải cấu hình máy khách gửi một chứng chỉ không nằm trong chuỗi của các Tổ chức Chứng nhận (Certificate Authorities) (hoặc là CA gốc hoặc CA trung gian) trong thông điệp Yêu cầu Chứng chỉ (Certificate Request message) của máy chủ. Người đánh giá sẽ phải xác nhận rằng nỗ lực kết nối bị từ chối.

- Kiểm tra 5: Người đánh giá sẽ phải cấu hình máy khách gửi một chứng chỉ với mục đích Xác thực Máy Khách (Client Authentication) trong trường extendedKeyUsage và xác nhận rằng máy chủ sẽ chấp nhận kết nối đã thử. Người đánh giá sẽ phải lặp lại kiểm tra này mà không có mục đích Chứng thực Máy Khách (Client Authentication) và sẽ xác nhận rằng máy chủ từ chối kết nối. Lý tưởng nhất là hai chứng chỉ nên giống hệt nhau, ngoại trừ mục đích Chứng thực Máy Khách (Client Authentication).

- Kiểm tra 6: Người đánh giá sẽ phải thực hiện các sửa đổi sau cho lưu lượng: a) Cấu hình máy chủ để yêu cầu chứng thực lẫn nhau và sau đó sửa đổi một byte trong chứng chỉ của máy khách. Người đánh giá sẽ phải xác nhận rằng máy chủ từ chối kết nối. b) Cấu hình máy chủ để yêu cầu chứng thực lẫn nhau và sau đó sửa một byte trong thông điệp bắt tay Xác nhận Chứng Chỉ (Certificate Verify handshake message) của máy khách. Người đánh giá sẽ phải xác nhận rằng máy chủ từ chối kết nối.

FCS_TLSS_EXT.1.6

Ứng dụng sẽ không thiết lập một kênh tin cậy nếu tên phân biệt (DN - distinguished name) hoặc Subject Alternative Name (SAN) được chứa trong một chứng chỉ không khớp với bộ định danh dự kiến cho điểm ngang hàng.

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

...

...

...

Hoạt động đảm bảo:

Nếu TOE thực hiện xác thực lẫn nhau, người đánh giá sẽ phải xác nhận rằng TSS mô tả cách DN và SAN trong chứng chỉ được so sánh với bộ định danh dự kiến.

Nếu DN không được so sánh tự động với Domain Name, địa chỉ IP, tên người dùng hoặc địa chỉ email, người đánh giá sẽ phải đảm bảo rằng hướng dẫn của AGD bao gồm cấu hình của định danh dự kiến hoặc máy chủ thư mục cho kết nối.

- Kiểm tra 1: Người đánh giá sẽ phải gửi chứng chỉ máy khách với một bộ định danh không khớp với bộ định danh dự kiến và xác nhận rằng máy chủ từ chối kết nối.

B.12  FCS_DTLS_EXT.1 Thực hiện DTLS

FCS_DTLS_EXT.1.1

Ứng dụng sẽ thực hiện giao thức DTLS tương ứng với DTLS 1.2 (RFC 6347).

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

Hoạt động đảm bảo:

...

...

...

Các kiểm tra khác được thực hiện kết hợp với Hoạt động đảm bảo (Assuarance Activity) được liệt kê cho FCS_TLSC_EXT.1 (Điều B.9 Phụ lục B).

FCS_DTLS_EXT.1.2

Ứng dụng sẽ thực hiện các yêu cầu trong TLS (FCS_TLSC_EXT.1 (Điều B.9 Phụ lục B)) để thực hiện DTLS, ngoại trừ các biến thể được cho phép theo DTLS 1.2 (RFC 6347).

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

Lưu ý khi thực hiện: Sự khác biệt giữa DTLS 1.2 và TLS 1.2 được nêu trong RFC 6347; ngoài ra các giao thức là như nhau. Đặc biệt, đối với các đặc tính bảo mật có thể áp dụng được xác định cho TSF, hai giao thức không khác nhau. Do đó, tất cả các ghi chú ứng dụng và hoạt động đảm bảo được liệt kê cho TLS áp dụng cho việc triển khai DTLS.

Hoạt động đảm bảo:

Người đánh giá sẽ phải thực hiện các Hoạt động đảm bảo liệt kê cho FCS_TLSC_EXT.1 (Điều B.9 Phụ lục B).

FCS_DTLS_EXT.1.3

Ứng dụng sẽ không thiết lập một kênh truyền thông tin cậy nếu chứng nhận ngang hàng được coi là không hợp lệ.

...

...

...

Lưu ý khi thực hiện: Hiệu lực được xác định bởi đường dẫn chứng chỉ, ngày hết hạn và trạng thái thu hồi theo RFC 5280.

Hoạt động đảm bảo:

Chứng chỉ hợp lệ sẽ phải được kiểm tra theo các thử nghiệm thực hiện cho FIA_X509_EXT.1 (Điều B.14 Phụ lục B) và người đánh giá sẽ phải thực hiện kiểm tra sau:

- Kiểm tra 1: Người đánh giá sẽ phải chứng minh rằng sử dụng một chứng chỉ mà không có một đường dẫn chứng chỉ hợp lệ sẽ dẫn đến việc thất bại chức năng. Bằng cách sử dụng hướng dẫn quản trị, người đánh giá sẽ tải một hoặc nhiều chứng chỉ vào Trust Anchor Database, cần thiết để xác thực chứng chỉ được sử dụng trong chức năng và chứng minh rằng chức năng sẽ thành công. Người đánh giá sau đó sẽ phải xóa một trong các chứng chỉ, và cho thấy rằng chức năng thất bại.

B.13  FCS_HTTPS_EXT.1 Giao thức HTTPS

FCS_HTTPS_EXT.1.1

Ứng dụng sẽ thực hiện giao thức HTTPS tuân thủ RFC 2818.

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

Hoạt động đảm bảo:

...

...

...

FCS_HTTPS_EXT.1.2

Ứng dụng sẽ thực hiện HTTPS bằng cách dùng TLS (FCS_TLSC_EXT.1 (Điều B.9 Phụ lục B)).

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

Hoạt động đảm bảo:

Các kiểm tra khác được thực hiện kết hợp với FCS_TLSC_EXT.1 (Điều B.9 Phụ lục B).

FCS_HTTPS_EXT.1.3

Ứng dụng sẽ thông báo cho người dùng và [lựa chọn: không thiết lập kết nối, yêu cầu cho phép ứng dụng thiết lập kết nối, không có hành động nào khác] nếu chứng chỉ ngang hàng được coi là không hợp lệ.

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

Lưu ý khi thực hiện: Hiệu lực được xác định bởi đường dẫn chứng chỉ, ngày hết hạn và trạng thái thu hồi theo RFC 5280.

...

...

...

Hiệu lực của chứng chỉ sẽ phải được kiểm tra phù hợp với các kiểm tra sẽ được thực hiện cho FIA_X509_EXT.1 (Điều B.14 Phụ lục B) và người đánh giá sẽ phải thực hiện kiểm tra sau:

- Kiểm tra 1: Người đánh giá sẽ phải chứng minh rằng sử dụng chứng chỉ không có đường dẫn chứng chỉ hợp lệ sẽ dẫn đến thông báo của ứng dụng. Bằng cách sử dụng hướng dẫn quản trị, người đánh giá sẽ phải tải một hoặc nhiều chứng chỉ Trust Anchor Database, cần để xác thực chứng chỉ được dùng trong chức năng và chứng minh rằng chức năng đó thành công. Sau đó, người đánh giá sẽ phải xóa một trong các chứng chỉ và thấy rằng ứng dụng sẽ được thông báo về xác thực thất bại.

B.14  FIA_X509_EXT.1 Xác nhận chứng chỉ X.509

FIA_X509_EXT.1.1

Ứng dụng sẽ [lựa chọn: gọi chức năng được nền tảng cung cấp, thực hiện chức năng] để xác thực các chứng chỉ phù hợp với các quy tắc sau:

- Xác nhận chứng chỉ của RFC 5280 và xác nhận đường dẫn chứng chỉ

- Đường dẫn chứng chỉ phải kết thúc tại một chứng chỉ CA tin cậy.

- Ứng dụng sẽ phải xác nhận đường dẫn chứng chỉ bằng cách đảm bảo sự hiện diện của việc mở rộng các Ràng buộc (Constraints) cơ bản và cờ CA được đặt thành TRUE (ĐÚNG) đối với tất cả các chứng chỉ CA.

- Ứng dụng sẽ phải xác nhận tình trạng thu hồi của chứng chỉ bằng cách sử dụng [lựa chọn: Online Certificate Status Protocol (OCSP) (Giao thức trạng thái chứng chỉ trực tuyến) theo quy định trong RFC 2560, Certificate Revocation List (CRL) (Danh sách thu hồi chứng chỉ) theo quy định tại RFC 5759, OCSP TLS Status Request Extension (yêu cầu mở rộng yêu cầu trạng thái OCSP TLS), (ví dụ Ghim của OCSP) như được quy định trong RFC 6066].

...

...

...

• Các chứng chỉ được sử dụng cho các cập nhật tin cậy và xác thực toàn vẹn của mã thực thi sẽ phải có mục đích Ký Mã (Code Signing) (id-kp 3 với OID 1.3.6.1.5.5.7.3.3) trong trường extendedKeyUsage.

• Các chứng chỉ của máy chủ được trình cho TLS sẽ phải có mục đích Xác thực Máy chủ (Server Authentication) (id-kp 1 với OID 1.3.6.1.5.5.7.3.1) trong trường extendedKeyUsage.

• Các chứng chỉ của máy khách được trình cho TLS sẽ phải có mục đích Xác thực Máy Khách (Client Authentication) (id-kp 2 với OID 1.3.6.1.5.5.7.3.2) trong trường extendedKeyUsage.

• Các chứng chỉ S/MIME được trình cho mã hóa và chữ ký email sẽ phải có mục đích Bảo vệ Email (Email Protection) (id-kp 4 với OID 1.3.6.1.5.5.7.3.4) trong trường extendedKeyUsage.

• Các chứng chỉ OCSP được trình cho các phản hồi của OCSP sẽ phải có mục đích Ký OCSP (OCSP Signing) (id-kp 9 với OID 1.3.6.1.5.5.7.3.9) trong trường extendedKeyUsage.

• Các chứng chỉ máy chủ được trình cho EST sẽ phải có mục đích Nhà Đăng ký (Registration Authority) (RA) của CMC (ID-kp-cmcRA với OID 1.3.6.1.5.5.7.3.28) trong trường extendedKeyUsage.

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

Lưu ý khi thực hiện: FIA_X509_EXT.1.1 (Điều B.14 Phụ lục B) sẽ liệt kê các quy tắc để xác nhận chứng chỉ. Tác giả ST sẽ phải lựa chọn xem tình trạng thu hồi có được xác nhận bằng OCSP hoặc các CRL hay không. FIA_X509_EXT.2 yêu cầu các chứng chỉ được dùng cho HTTPS, TLS và DTLS; việc sử dụng này yêu cầu phải xác nhận các quy tắc của extendedKeyUsage.

Bất kể việc lựa chọn “chức năng thực hiện” hoặc “gọi chức năng được nền tảng cung cấp”, việc xác nhận sẽ dự kiến kết thúc trong chứng chỉ CA gốc tin cậy trong lưu trữ gốc được quản lý bởi nền tảng.

...

...

...

Người đánh giá sẽ phải đảm bảo TSS mô tả nơi kiểm tra tính hợp lệ của chứng chỉ. Người đánh giá sẽ đảm bảo TSS cũng cung cấp mô tả của thuật toán xác nhận đường dẫn chứng chỉ.

Các kiểm tra được mô tả phải được thực hiện cùng với các hoạt động đảm bảo dịch vụ chứng chỉ khác, bao gồm các chức năng trong FIA_X509_EXT.2.1 (Điều B.15 Phụ lục B). Các kiểm tra cho các quy tắc extendedKeyUsage được thực hiện kết hợp với việc sử dụng yêu cầu những quy tắc này. Nếu ứng dụng hỗ trợ các chuỗi có chiều dài từ 4 trở lên thì người đánh giá sẽ phải tạo ra một chuỗi ít nhất bốn chứng chỉ: chứng chỉ nút (node) phải được kiểm tra, hai chứng chỉ CA trung gian và một chứng chỉ Root CA tự ký. Nếu ứng dụng hỗ trợ độ tin cậy tối đa là hai, thì nên tạo một chuỗi không có CA trung gian.

- Kiểm tra 1: Người đánh giá sẽ phải chứng minh rằng việc xác nhận một chứng chỉ không có đường dẫn chứng chỉ hợp lệ sẽ dẫn đến việc thất bại chức năng. Người đánh giá sẽ phải tải một hoặc nhiều chứng chỉ là CA tin cậy, cần để xác nhận chứng chỉ được sử dụng trong chức năng và chứng minh rằng chức năng đó thành công. Người đánh giá sẽ phải xóa một trong các chứng chỉ, và thấy rằng chức năng sẽ thất bại.

- Kiểm tra 2: Người đánh giá sẽ phải chứng minh rằng việc xác nhận một chứng chỉ hết hạn sẽ dẫn đến việc thất bại chức năng.

- Kiểm tra 3: Người đánh giá sẽ phải kiểm tra rằng TOE có thể xử lý đúng các chứng chỉ thu hồi - tùy thuộc vào việc lựa chọn CRL, OCSP, hoặc OCAP Stapling; nếu chọn nhiều phương pháp thì phải thực hiện các kiểm tra sau cho mỗi phương pháp:

• Người đánh giá sẽ phải kiểm tra việc thu hồi của chứng chỉ nút (node).

• Người đánh giá cũng sẽ phải kiểm tra việc thu hồi chứng chỉ CA trung gian (tức là CA gốc sẽ gọi thu hồi chứng chỉ CA trung gian), nếu các chứng chỉ CA trung gian được hỗ trợ.

Người đánh giá sẽ phải đảm bảo rằng một chứng chỉ hợp lệ được sử dụng và chức năng xác thực là thành công. Sau đó, người đánh giá sẽ cố kiểm tra với một chứng chỉ đã bị thu hồi (cho mỗi phương pháp đã chọn trong các lựa chọn) để đảm bảo khi chứng chỉ không còn hiệu lực nữa thì chức năng xác thực sẽ thất bại.

- Kiểm tra 4: Nếu OCSP được chọn, người đánh giá sẽ phải cấu hình máy OCSP hoặc sử dụng công cụ man-in-the-middle (người tấn công-ở giữa) để trình chứng chỉ không có mục đích ký OCSP và xác nhận rằng việc xác thực phản hồi của OCSP sẽ thất bại. Nếu CRL được chọn, người đánh giá sẽ phải cấu hình CA để ký một CRL bằng chứng chỉ không có khóa cRLsign và xác nhận rằng xác thực của CRL sẽ thất bại.

...

...

...

- Kiểm tra 6: Người đánh giá sẽ phải sửa đổi bất kỳ byte nào trong byte cuối cùng của chứng chỉ và chứng minh rằng chứng chỉ sẽ xác thực thất bại. (Chữ ký trên chứng chỉ sẽ không xác thực.)

- Kiểm tra 7: Người đánh giá sẽ phải sửa đổi bất kỳ byte nào trong khóa công khai của chứng chỉ và chứng minh rằng chứng chỉ sẽ xác thực thất bại. (Chữ ký trên chứng chỉ sẽ không xác thực.)

FIA_X509_EXT.1.2

Ứng dụng sẽ xem chứng chỉ như là chứng chỉ CA chỉ khi phần mở rộng basicConstraints (ràng buộc cơ bản) có hiện diện và cờ CA được đặt thành TRUE (ĐÚNG).

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

Lưu ý khi thực hiện: Yêu cầu này áp dụng cho các chứng chỉ được TSF sử dụng và xử lý, và sẽ hạn chế các chứng chỉ có thể được thêm vào như là chứng chỉ CA tin cậy.

Hoạt động đảm bảo:

Các kiểm tra được mô tả phải được thực hiện cùng với các Hoạt động đảm bảo các dịch vụ chứng chỉ khác, bao gồm các chức năng trong FIA_X509_EXT.2.1 (Điều B.15 Phụ lục B). Nếu ứng dụng hỗ trợ các chuỗi có chiều dài từ 4 trở lên thì người đánh giá sẽ phải tạo ra một chuỗi ít nhất bốn chứng chỉ: chứng chỉ nút (node) để kiểm tra, hai chứng chỉ CA trung gian và một chứng chỉ Root CA tự ký. Nếu ứng dụng hỗ trợ độ tin cậy tối đa là hai, thì nên tạo một chuỗi không có CA trung gian..

- Kiểm tra 1: Người đánh giá sẽ phải xây dựng một đường dẫn chứng chỉ, như vậy chứng chỉ của CA phát hành chứng chỉ của TOE không có phần mở rộng basicConstraints. Xác nhận của đường dẫn chứng chỉ sẽ thất bại.

...

...

...

- Kiểm tra 3: Người đánh giá sẽ phải xây dựng một đường dẫn chứng chỉ, như vậy chứng chỉ của CA phát hành chứng chỉ của TOE có cờ CA trong phần mở rộng basicConstraints được đặt thành TRUE (ĐÚNG). Việc xác nhận đường dẫn chứng chỉ sẽ thành công.

B.15  FIA_X509_EXT.2 Xác thực chứng chỉ X.509

FIA_X509_EXT.2.1

Ứng dụng sẽ sử dụng các chứng chỉ X.509v3 như được định nghĩa bởi RFC 5280 để hỗ trợ việc xác thực cho [lựa chọn: HTTPS, TLS, DTLS].

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

Lưu ý khi thực hiện: Lựa chọn của tác giả ST sẽ phải phù hợp với lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

FIA_X509_EXT.2.2

Khi ứng dụng không thể thiết lập kết nối để xác định tính hợp lệ của chứng chỉ, ứng dụng sẽ [lựa chọn: cho phép quản trị viên chọn chấp nhận chứng chỉ nào trong các trường hợp này, chấp nhận chứng chỉ, không chấp nhận chứng chỉ].

Yêu cầu này tùy thuộc vào lựa chọn trong FTP_DIT_EXT.1.1 (9.1.6).

...

...

...

Hoạt động đảm bảo:

Người đánh giá sẽ phải kiểm tra TSS để đảm bảo rằng nó mô tả cách TOE sẽ chọn chứng chỉ nào để dùng và bất kỳ chỉ dẫn cần thiết nào trong hướng dẫn quản trị để cấu hình môi trường vận hành mà TOE có thể sử dụng các chứng chỉ.

Người đánh giá sẽ phải kiểm tra TSS để xác nhận rằng nó mô tả hành vi của TOE khi một kết nối không thể được thiết lập trong quá trình kiểm tra xác thực của một chứng chỉ được dùng trong việc thiết lập một kênh tin cậy. Người đánh giá sẽ phải xác nhận rằng bất kỳ sự phân biệt nào giữa các kênh tin cậy sẽ được mô tả. Nếu yêu cầu rằng quản trị viên có thể chỉ rõ hành động mặc định, người đánh giá sẽ phải đảm bảo rằng hướng dẫn vận hành sẽ chứa các chỉ dẫn về cách mà hành động cấu hình này được thực hiện.

Người đánh giá sẽ phải thực hiện kiểm tra sau cho mỗi kênh tin cậy:

- Kiểm tra 1: Người đánh giá sẽ phải chứng minh rằng việc sử dụng chứng chỉ hợp lệ sẽ yêu cầu thực hiện kiểm tra xác thực chứng chỉ ít nhất một vài lần với đối tượng IT không phải là TOE. Người đánh giá sau đó sẽ phải thao tác môi trường sao cho TOE không thể xác nhận xác thực của chứng chỉ và quan sát thấy hành động được chọn trong FIA_X509_EXT.2.2 được thực hiện. Nếu hành động được chọn là quản trị viên có thể cấu hình được, thì người đánh giá sẽ phải theo hướng dẫn vận hành để xác định rằng tất cả các tùy chọn quản trị viên có thể cấu hình được xử lý theo cách đã được ghi vào tài liệu.

- Kiểm tra 2: Người đánh giá sẽ phải chứng minh rằng một chứng chỉ không hợp lệ sẽ yêu cầu thực hiện kiểm tra xác thực chứng chỉ được thực hiện ít nhất một vài phần bằng liên lạc với một thực thể IT không phải là TOE không thể được chấp nhận.

Phụ lục C

(Quy định)

...

...

...

Phụ lục này gồm các yêu cầu xác định chức năng an toàn cũng nhằm giải quyết các mối đe dọa. Các yêu cầu này hiện không được đưa trong phần thân của PP này vì chúng mô tả chức năng an toàn chưa có sẵn trong công nghệ thương mại. Tuy nhiên, các yêu cầu này có thể được bao gồm trong ST sao cho TOE vẫn phù hợp với PP này, và mong muốn rằng chúng sẽ được đưa vào càng sớm càng tốt.

C.1  FCS_TLSC_EXT.3 Giao thức máy khách TLS

FCS_TLSC_EXT.3.1

Ứng dụng sẽ phải trình bày phần mở rộng thuật toán_chữ ký (signature_algorithms) trong Chào Máy Khách (Client Hello) với giá trị thuật toán_chữ ký_được hỗ trợ (supported_signature_algorithms) chứa các thuật toán băm sau đây: [lựa chọn: SHA256, SHA384, SHA512] và không còn thuật toán băm nào khác.

Lưu ý khi thực hiện: yêu cầu này sẽ giới hạn các thuật toán băm được hỗ trợ cho mục đích xác thực chữ ký số của máy khách và giới hạn máy chủ tới các thuật toán băm được hỗ trợ cho mục đích tạo chữ ký số của máy chủ. Phần mở rộng thuật toán_chữ ký (signature_algorithms) chỉ được hỗ trợ bởi TLS 1.2.

Hoạt động đảm bảo:

Người đánh giá sẽ phải xác thực rằng TSS mô tả phần mở rộng thuật toán_chữ ký (signature_algorithm) và liệu hành vi yêu cầu có được thực hiện mặc định hay có thể được cấu hình. Nếu TSS chỉ ra rằng phần mở rộng thuật toán_chữ ký (signature_algorithm) phải được cấu hình để đáp ứng yêu cầu, người đánh giá sẽ phải xác thực rằng hướng dẫn AGD bao gồm cấu hình của phần mở rộng thuật toán_chữ ký (signature_algorithm).

Người đánh giá cũng sẽ phải thực hiện thử nghiệm sau:

- Kiểm tra 1: Người đánh giá sẽ phải cấu hình máy chủ để gửi chứng chỉ trong kết nối TLS không được hỗ trợ theo bảng kê HashAlgorithm của máy khách trong phần mở rộng của thuật toán_chữ ký (signature_algorithm) (ví dụ gửi chứng chỉ có chữ ký SHA-1). Người đánh giá sẽ phải xác thực rằng TOE sẽ ngắt kết nối sau khi nhận được thông điệp bắt tay Chứng chỉ (Certificate handshake message) của máy chủ.

...

...

...

FPT_API_EXT.2.1

Ứng dụng [lựa chọn: sử dụng các thư viện được nền tảng cung cấp, không thực hiện chức năng] để phân tích cú pháp [chỉ định: danh sách các định dạng được phân tích cú pháp được bao gồm trong các kiểu phương tiện IANA MIME].

Lưu ý khi thực hiện:

Các loại IANA MIME được liệt kê tại http://www.iana.org/assignments/media-types và bao gồm nhiều định dạng tệp như hình ảnh, âm thanh, video và nội dung. Yêu cầu này không áp dụng nếu cung cấp các dịch vụ phân tích cú pháp là mục đích của ứng dụng.

Hoạt động đảm bảo:

Người đánh giá sẽ phải xác thực rằng TSS liệt kê các loại phương tiện IANA MIME (như mô tả bởi http://www.iana.org/assignments/media-types) cho tất cả các định dạng các tiến trình ứng dụng và ánh xạ các định dạng đó đến các dịch vụ phân tích cú pháp do nền tảng cung cấp.

C.3  FPT_IDV_EXT.1 Nhận dạng và các phiên bản của phần mềm

FPT_IDV_EXT.1.1

Ứng dụng sẽ phải gồm các thẻ SWID đáp ứng các yêu cầu tối thiểu cho thẻ SWID theo tiêu chuẩn ISO/IEC 19770-2:2009.

...

...

...

Hoạt động đảm bảo:

Người đánh giá sẽ phải cài đặt ứng dụng, sau đó kiểm tra sự tồn tại của các thẻ SWID trong tệp .swidtag. Người đánh giá sẽ phải mở tệp và xác thực rằng nó có chứa ít nhất một phần tử SoftwareIdentity và một phần tử Thực thể.

Phụ lục D

(Tham khảo)

Tài liệu và đánh giá Entropy

Phụ lục này mô tả các thông tin bổ sung cần thiết cho nguồn entropy được sử dụng bởi TOE.

Tài liệu của nguồn entropy phải đủ chi tiết để sau khi đọc, người đánh giá sẽ hiểu sâu sắc nguồn entropy và tại sao nó có thể dựa vào để cung cấp đủ entropy. Tài liệu này nên bao gồm nhiều phần chi tiết: mô tả thiết kế, giải trình entropy, điều kiện hoạt động và kiểm tra hồi phục. Tài liệu này không bắt buộc phải là một phần của TSS.

D.1  Mô tả thiết kế

...

...

...

Tài liệu sẽ mô tả hoạt động của nguồn entropy bao gồm, cách tạo ra entropy, và cách dữ liệu chưa xử lý (thô) có thể được chứa bên trong nguồn entropy cho mục đích kiểm tra. Tài liệu cần đi qua công đoạn thiết kế nguồn entropy để biết entropy xuất phát từ đâu, nơi đầu ra của entropy được truyền tiếp theo, bất kỳ quá trình hậu xử lý các đầu ra thô (băm, XOR...), nơi lưu trữ, và cuối cùng cách xuất ra từ nguồn entropy. Bất kỳ điều kiện nào được đặt trên quy trình (ví dụ như chặn) cũng phải được mô tả trong thiết kế nguồn entropy. Khuyến khích các sơ đồ và các ví dụ.

Thiết kế này cũng phải bao gồm mô tả về nội dung của ranh giới bảo mật của nguồn entropy và mô tả cách ranh giới bảo mật đảm bảo rằng kẻ thù bên ngoài ranh giới không thể ảnh hưởng đến tỷ lệ entropy.

Nếu được thực hiện, mô tả thiết kế sẽ gồm mô tả về cách các ứng dụng của bên thứ ba có thể thêm entropy vào RBG. Phải có mô tả và ghi lại trạng thái RBG giữa tắt và bật máy.

D.2  Giải trình Entropy

Cần phải có một luận giải kỹ thuật về tính không đoán trước trong nguồn đến từ đâu và vì sao có thể tin cậy nguồn entropy cung cấp đủ entropy cho việc dùng để tạo đầu ra RBG (bởi TOE cụ thể này). Luận giải này sẽ gồm mô tả về tỷ lệ entropy tối thiểu được kỳ vọng (nghĩa là entropy tối thiểu (theo bit) cho mỗi bit hoặc byte của dữ liệu nguồn) và giải thích rằng có đủ entropy đi vào quá trình tạo hạt ngẫu nhiên của TOE. Thảo luận này sẽ là một phần của luận giải tại sao nguồn entropy là đủ để tạo ra các bit có entropy.

Số lượng thông tin cần thiết để lý giải cho tỷ lệ entropy tối thiểu được kỳ vọng phụ thuộc vào loại nguồn entropy trong sản phẩm.

Đối với nhà phát triển đã cung cấp các nguồn entropy, để xác minh tỷ lệ entropy tối thiểu, dự kiến một lượng lớn các bit của nguồn thô sẽ được thu thập, các phép thử thống kê sẽ được thực hiện và tỷ lệ entropy tối thiểu được xác định từ các thử nghiệm thống kê. Mặc dù tại thời điểm này không có thử nghiệm thống kê cụ thể, nhưng cần phải một số thử nghiệm để xác định lượng entropy tối thiểu ở mỗi đầu ra.

Đối với bên thứ ba đã cung cấp nguồn entropy, trong đó nhà cung cấp TOE có quyền truy cập hạn chế đối với dữ liệu entropy thiết kế và thô, tài liệu sẽ ước lượng ra số lượng entropy tối thiểu thu được từ nguồn các bên thứ ba này. Có thể chấp nhận cho nhà cung cấp để “giả định” một số lượng entropy tối thiểu, tuy nhiên giả định này phải được nêu rõ trong tài liệu cung cấp. Cụ thể, ước lượng entropy tối thiểu phải được xác định và giả định trong ST.

Bất kể kiểu nguồn entropy nào, sự giải thích cũng sẽ bao gồm cách DRBG được khởi tạo với entropy được nêu trong ST, ví dụ bằng cách xác minh rằng tỷ lệ entropy tối thiểu được nhân bởi số lượng dữ liệu nguồn được dùng để gieo hạt DRBG hoặc tỷ lệ entropy dự kiến dựa trên số lượng dữ liệu nguồn được nêu và so sánh rõ với tỷ lệ thống kê. Nếu số lượng dữ liệu nguồn được dùng để gieo hạt DRBG không rõ ràng hoặc tỷ lệ tính toán không rõ ràng liên quan đến hạt giống, tài liệu sẽ không được xem là hoàn chỉnh.

...

...

...

D.3  Điều kiện hoạt động

Tỷ lệ entropy có thể bị ảnh hưởng bởi các điều kiện nằm ngoài sự kiểm soát của nguồn entropy. Ví dụ điện áp, tần số, nhiệt độ, và thời gian trôi qua sau khi bật nguồn chỉ là một vài yếu tố có thể ảnh hưởng đến hoạt động của nguồn entropy. Do đó, tài liệu cũng sẽ bao gồm nhiều điều kiện hoạt động theo đó nguồn entropy dự kiến sẽ tạo ra dữ liệu ngẫu nhiên. Nó sẽ mô tả rõ ràng các biện pháp đã được thực hiện trong thiết kế hệ thống để đảm bảo nguồn entropy tiếp tục hoạt động theo các điều kiện đó. Tương tự, tài liệu sẽ mô tả các điều kiện theo đó nguồn entropy được biết là trục trặc hoặc trở nên không nhất quán. Sẽ phải đưa vào các phương pháp dùng để phát hiện sự thất bại hoặc suy thoái của nguồn.

D.4  Kiểm tra hồi phục

Cụ thể hơn, sẽ phải ghi lại tất cả các kiểm tra hồi phục nguồn entropy và lý do của chúng. Việc này sẽ gồm mô tả các kiểm tra, tỷ lệ và các điều kiện mà theo đó mỗi kiểm tra hồi phục được thực hiện (ví dụ khi khởi động, liên tục hoặc theo yêu cầu), kết quả dự kiến cho mỗi kiểm tra hồi phục và lý do cho biết tại sao mỗi kiểm tra được cho là phù hợp để phát hiện một hoặc nhiều thất bại trong nguồn entropy.

Thư mục tài liệu tham khảo

[1] NIAP Protection Profile for Application Software (Hồ sơ bảo vệ cho phần mềm ứng dụng), phiên bản 1.2, ngày 22/4/2016.

[2] CCMB-2012-09-001 Common Criteria for Information Technology Security Evaluation - Part 1: Introduction and General Model (Tiêu chí chung dùng đánh giá an toàn về công nghệ thông tin - Phần 1: Giới thiệu và các mô hình chung), phiên bản 3.1 - sửa đổi lần 4, tháng 9/2012. Tương đương TCVN 8709-1, “Công nghệ thông tin - Các kỹ thuật an toàn - Các tiêu chí đánh giá an toàn CNTT - Phần 1: Giới thiệu và mô hình tổng quát”.

[3] CCMB-2012-09-002 Common Criteria for Information Technology Security Evaluation - Part 2: Security Functional Components (Tiêu chí chung dùng đánh giá an toàn về công nghệ thông tin - Phần 2: Các thành phần chức năng an toàn), phiên bản 3.1 - sửa đổi lần 4, tháng 9/2012.

...

...

...

[4] CCMB-2012-09-003 Common Criteria for Information Technology Security Evaluation - Part 3: Security Assuarance Components (Tiêu chí chung dùng đánh giá an toàn về công nghệ thông tin - Phần 3: Các thành phần đảm bảo an toàn), phiên bản 3.1 - sửa đổi lần 4, tháng 9/2012. Tương đương TCVN 8709-3, “Công nghệ thông tin - Các kỹ thuật an toàn - Các tiêu chí đánh giá an toàn CNTT - Phần 3: Các thành phần đảm bảo an toàn”.

[5] CCMB-2012-09-004 Common Evaluation Methodology for Information Technology Security - Evaluation Methodology (Phương pháp Đánh giá chung dùng cho an toàn công nghệ thông tin - Phương pháp đánh giá), phiên bản 3.1 - sửa đổi lần 4, tháng 9/2012. Tương đương TCVN 11386:2016 (ISO/IEC 18045:2008), “Công nghệ thông tin - Các kỹ thuật an toàn - Phương pháp đánh giá an toàn công nghệ thông tin”.

[6] NIAP Application Software Protection Profile (ASPP) Extended Package: File Encryption: Mitigating the Risk of Disclosure of Sensitive Data on a System (Gói mở rộng của Hồ sơ bảo vệ Phần mềm ứng dụng (ASPP): Mã hóa tập tin: Giảm thiểu rủi ro công bố dữ liệu nhạy cảm trên hệ thống), phiên bản 1.0, ngày 10/11/2014.

[7] NIAP Extended Package for Secure Shell (SSH) (Gói mở rộng cho Shell an toàn SSH), phiên bản 1.0, ngày 19/02/2016

[8] Clarification to the Entropy Documentation and Assessment Annex (Làm rõ Tài liệu Entropy và Phụ lục đánh giá, địa chỉ tham khảo: https://www.niap-ccevs.org/Documents_and_Guidance/ccevs/Entropy%20Documentation%20and%20Assessment%20Clarification.pdf

[9] NIST SP 800-38A, Recommendation for Block Cipher Modes of Operation: Methods and Techniques (Khuyến nghị cho các Phương thức hoạt động của Mã khối: Phương pháp và kỹ thuật), tháng 12/2001.

[10] NIST SP 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC (Khuyến nghị cho các Phương thức hoạt động Mã khối: Phương thức Galois/Counter (GCM) và GMAC), tháng 11/2007.

[11] NIST SP 800-56A, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Khuyến nghị cho các Lược đồ thiết lập khóa cặp sử dụng mật mã Lô-ga-rít rời rạc), Rev. 2, tháng 5/2013.

[12] NIST SP 800-56B, Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography (Khuyến nghị cho các Lược đồ thiết lập khóa cặp sử dụng mật mã phần tử số nguyên), Rev. 1, tháng 9/2014.

...

...

...

[14] NIST SP 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators (Khuyến nghị cho việc tạo số ngẫu nhiên sử dụng các Bộ tạo bit ngẫu nhiên xác định), Rev. 1, tháng 6/2015.

[15] NIST SP 800-90B, Recommendation for Entropy Sources Used for Random Bit Generation (Khuyến nghị cho các nguồn Entropy được dùng để tạo bit ngẫu nhiên), bản dự thảo lần 2, tháng 1/2011.

[16] NIST SP 800-131A, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths (Chuyển đổi: Khuyến nghị cho việc chuyển đổi sử dụng của các thuật toán mật mã và độ dài khóa), Rev. 1, tháng 11/2015.

[17] NIST FIPS 140-2, Security Requirements for Cryptographic Modules (Các Yêu cầu bảo mật cho các mô-đun mật mã), 25/5/2001, Change Notice 2, 12/03/2002

[18] NIST FIPS 180-4, Secure Hash Standard (SHS) (Tiêu chuẩn Hàm băm an toàn), tháng 8/2015

[19] NIST FIPS 186-4, Digital Signature Standard (DSS) (Tiêu chuẩn Chữ ký số), tháng 7/2013

[20] NIST FIPS 198-1, The Keyed-Hash Message Authentication Code (HMAC) (Mã xác thực thông điệp khóa băm HMAC), tháng 7/2008

[21] ANSI X9.31-1998, Digital Signatures Using Reversible Public Key Cryptography for the Financial Services Industry (rDSA) (Các chữ ký số sử dụng mật mã khóa công khai có thể đảo ngược cho ngành công nghiệp dịch vụ tài chính), 01/01/1998

[22] NIST, The Secure Hash Algorithm Validation System (SHAVS) (Hệ thống xác thực thuật toán băm an toàn), cập nhật ngày 21/5/2014

...

...

...

MỤC LỤC

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  Chữ viết tắt

5  Ranh giới của TOE

6  Yêu cầu tuân thủ

6.1  Tuyên bố tuân thủ

6.2  Yêu cầu phù hợp với CC

...

...

...

6.4  Yêu cầu phù hợp với gói ứng dụng

7  Xác định vấn đề an toàn

7.1  Các mối đe dọa

7.2  Các giả định

7.3  Chính sách bảo mật tổ chức

8  Mục tiêu an toàn

8.1  Mục tiêu an toàn cho TOE

8.2  Mục tiêu an toàn cho môi trường hoạt động

8.3  Lý do mục tiêu an toàn

...

...

...

9.1  Yêu cầu chức năng an toàn

9.1.1  Hỗ trợ bằng mật mã (FCS)

9.1.2  Bảo vệ dữ liệu người dùng (FDP)

9.1.3  Quản lý bảo mật (FMT)

9.1.4  Sự riêng tư

9.1.5  Bảo vệ của TSF (FPT)

9.1.6  Đường dẫn / Kênh Tin cậy (FTP)

9.2  Yêu cầu đảm bảo an toàn

9.2.1  Lớp ASE: Mục tiêu an toàn

...

...

...

9.2.3  Lớp AGD: Tài liệu hướng dẫn

9.2.4  Lớp ALC: Hỗ trợ vòng đời

9.2.5  Lớp ATE: Kiểm tra

9.2.6  Lớp AVA: Đánh giá lỗ hổng

Phụ lục A (Quy định) Các yêu cầu không bắt buộc

A.1  FCS_CKM.1(2) Tạo khóa mật mã đối xứng

A.2  FCS_TLSC_EXT.2 Giao thức máy khách của TLS

Phụ lục B (Quy định) Các yêu cầu dựa trên lựa chọn

B.1  FCS_RBG_EXT.2 Tạo Bit ngẫu nhiên từ ứng dụng

...

...

...

B.3  FCS_CKM.1(1) Tạo khóa mật mã bất đối xứng

B.4  FCS_CKM.2 Thiết lập khóa mật mã

B.5  FCS_COP.1(1) Hoạt động mật mã - Mã hóa / Giải mã

B.6  FCS_COP.1(2) Hoạt động mật mã - Hàm Băm (Hash)

B.7  FCS_COP.1 (3) Thao tác mã hóa - Ký tên

B.8  FCS_COP.1(4) Hoạt động mật mã - Xác thực Thông điệp Khóa Băm (Keyed-Hash)

B.9  FCS TLSC EXT.1 Giao thức Máy khách của TLS

B.10  FCS_TLSC_EXT.4 Giao thức Máy khách của TLS

B.11  FCS_TLSS_EXT.1 Giao thức Máy chủ của TLS

...

...

...

B.13  FCS_HTTPS_EXT.1 Giao thức HTTPS

B.14  FIA_X509_EXT.1 Xác nhận chứng chỉ X.509

B.15  FIA_X509_EXT.2 Xác thực Chứng chỉ X.509

Phụ lục C (Quy định) Các yêu cầu mục tiêu

C.1  FCS_TLSC_EXT.3 Giao thức máy khách TLS

C.2  FPT_API_EXT.2 Sử dụng Các Dịch vụ Hỗ trợ và Các API

C.3  FPT_IDV_EXT.1 Nhận dạng và các phiên bản của phần mềm

Phụ lục D (Tham khảo) Tài liệu và đánh giá Entropy

D.1  Mô tả thiết kế

...

...

...

D.3  Điều kiện hoạt động

D.4  Kiểm tra hồi phục

Thư mục tài liệu tham khảo

[1] Entropy là một phép đo logarít về tốc độ truyền thông tin trong một thông điệp hoặc ngôn ngữ cụ thể