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

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 1 - TOE là ứng dụng và thành phần nhân (kernel) chạy trên hệ điều hành

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ủ

...

...

...

- 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.

Các yêu cầu vô điều kiện được trình bày trong phần chính của tiêu chuẩn này, và các phụ lục là các yêu cầu dựa trên lựa chọn, tùy chọn và yêu cầu mục tiêu. ST có thể lặp lại bất kì thành phần này, nhưng nó phải không bao hàm các thành phần bổ sung (ví dụ từ phần 2 hoặc 3 của CC hoặc một PP không phù hợp với PP này, hoặc được mở rộng bởi ST) không được định nghĩa trong PP này hoặc một PP phù hợp với tiêu chuẩn này.

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.

...

...

...

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 nghe lén qua mạng (T.NETWORK_EAVESDROP): 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ể giám sát và có được truy cập tới dữ liệu trao đổi giữa ứng dụng và các thiết bị đầu cuối khác.

- 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 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

8.1  Mục tiêu an toàn cho TOE

- 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).

...

...

...

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.

Giải quyết bằng: FTP_DIT_EXT.1 (9.1.6), FCS_ URL C_EXT.1 (Điều B.9 Phụ lục B), FCS_DTLS_EXT.1 (Điều B.12 Phụ lục B), FCS_RBG_EXT.1 (9.1.1).

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.

...

...

...

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

Lý do

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.

...

...

...

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.

Nguy cơ T.NETWORK_EVASDROP được đáp trả bởi O.MANAGEMENT vì nó cung cấp khả năng cấu hình ứng dụng để bảo vệ tính bảo mật của dữ liệu được truyền.

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

...

...

...

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.

A.PROPER_USER

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

...

...

...

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.

- Chỉ định (hiển thị bằng chữ in nghiêng): được dùng để chỉ định 1 giá trị cụ thể cho 1 thông số không cụ thể, ví dụ như chiều dài của mật khẩu. Hiển thị giá trị trong ngoặc vuông sẽ thông báo chỉ định.

- 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)

...

...

...

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,

thực hiện chức năng DRBG

] 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 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.

Đối với Android: người đánh giá sẽ xác thực rằng ứng dụng dùng ít nhất 1 trong những lớp (class)

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 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

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

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.

...

...

...

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 BlackBerry: Người đánh giá sẽ phải xác nhận rằng ứng dụng sử dụng các API Blackberry KeyStore và Secutity Builder để lưu trữ các chứng chỉ.

Đố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 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

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

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

kết nối mạng,

camera,

microphone,

...

...

...

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 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 Solaris: 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,

...

...

...

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 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 Solaris: 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:

...

...

...

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]

].

Lưu ý khi thực hiện: yêu cầu này nhằm hạn chế cả giao tiếp mạng vào và ra chỉ đến các nơi yêu cầu hoặc đến các giao tiếp mạng được người dùng khởi tạo. Nó không áp dụng cho giao tiếp mạng mà ứng dụng có thể truy cập hệ thống tệp có thể dẫn đến nền tảng truy cập vào các ổ đĩa hoặc các chia sẻ từ xa.

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).

...

...

...

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,

thực hiện chức năng 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:

...

...

...

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 Android: Người đánh giá sẽ phải kiểm tra TSS và xác nhận rằng nó mô tả cách thức các tập tin chứa dữ liệu nhạy cảm được lưu trữ với thiết lập cờ MODE_ PRIVATE.

Đố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.

...

...

...

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.

Lưu ý khi thực hiện: Các tùy chọn cấu hình nếu được lưu từ xa không phải là đối tượng của yêu cầu này.

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 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.

9.1.3.2  FMT_CFG_EXT.1 Bảo vệ bởi cấu hình mặc định

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:

...

...

...

- 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

Ứng dụng sẽ được cấu hình mặc định với các quyền truy cập tập tin để bảo vệ nó và dữ liệu khỏi bị truy cập trái phép.

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 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.

Đối với Mac OS X: 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.

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ỳ 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.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.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.

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

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].

...

...

...

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 Windows: Người đánh giá sẽ phải chạy ứng dụng giống nhau trên hai hệ thống Windows khác nhau và chạy công cụ liệt kê mọi địa chỉ ánh xạ của 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 sẽ chia sẻ các vị trí không tương ứng nhau. Có thể dùng công cụ VMMap của bộ SysInternals của Microsoft để xem các địa chỉ bộ nhớ của ứng dụng đang chạy. Người đánh giá sẽ phải dùng công cụ như Phân tích Nhị phân BinScope của Microsoft để xác nhận rằng ứng dụng đã bật ASLR.

Đố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.

...

...

...

Ứ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]

].

Lưu ý khi thực hiện: Yêu cầu việc lập bản đồ bộ nhớ với cả hai quyền ghi và thực thi sẽ làm hỏng bảo vệ của nền tảng được cấp bởi DEP. Nếu ứng dụng thực hiện biên dịch không theo kiểu đúng thời điểm (just-in-time) thì phải chọn lựa chọn đầu.

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à

...

...

...

Đố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 iOS: 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.

Đố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ả

...

...

...

- 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.

Lưu ý khi thực hiện: Yêu cầu này được thiết kế để đảm bảo rằng các chức năng an toàn của nền tảng không cần phải vô hiệu/tắt để ứng dụng thực thi.

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 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.

FPT_AEX_EXT.1.4

Ứ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 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 Solaris: 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:

...

...

...

Đố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 Linux: 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 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

...

...

...

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

Ứng dụng sẽ được phân phối sử dụng định dạng của trình quản lý các gói được nền tảng hỗ trợ.

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 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.

FPT_TUD_EXT.1.3

Ứ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ý.

...

...

...

Ứ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:

- Kiểm tra 1: Người đánh giá sẽ phải cài đặt ứng dụng và định vị tất cả các tập tin thi hành của nó. Sau đó, với mỗi tập tin, người đánh giá sẽ phải lưu lại hoặc là mã băm (hash) của tệp hoặc bản sao của tệp. Người đánh giá sẽ phải chạy ứng dụng và kiểm tra tất cả tính năng của ứng dụng đã mô tả trong TSS.

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:

...

...

...

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:

Người đánh giá sẽ phải xác nhận rằng TSS sẽ xác định cách thức gói cài đặt và cập nhật của ứng dụng được ký bởi nguồn có được phép. Định nghĩa nguồn được phép phải được chứa trong TSS. Người đánh giá sẽ phải đảm bảo rằng TSS (hoặc hướng dẫn vận hành) mô tả cách thức cập nhật.

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.

...

...

...

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

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

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]

...

...

...

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.

Nếu SSH được chọn, TSF sẽ được xác nhận hợp lệ với Gói Mở rộng cho Shell An toàn (tham khảo [7]).

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õ.

...

...

...

Đố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.

Điều này liệt kê tập hợp các SAR từ Phần 3 của CC được yêu cầu trong đánh giá đối với PP này. Các Hoạt động đảm bảo riêng rẽ (Individual Assurance Activities) (AA) được thực hiện cụ thể trong Điều 9 và cả trong điều này.

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.

...

...

...

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

Nhà phát triển sẽ phải cung cấp một đặc tả chức năng.

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:

...

...

...

Đặ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

Đặc tả chức năng sẽ cung cấp lý do cho phân loại ẩn của các giao diện như SFR-không can thiệp.

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

...

...

...

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 đủ.

9.2.3  Lớp AGD: Tài liệu hướng dẫn

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

...

...

...

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.

Lưu ý khi thực hiện: Người dùng và quản trị viên sẽ được định nghĩa như vai trò người dùng.

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.

...

...

...

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

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 mô tả các biện pháp an toàn phải tuân thủ để hoàn thành các mục tiêu an toàn cho môi trường vận hành như được mô tả trong ST.

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

...

...

...

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:

AGD_PRE.1.1D

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

...

...

...

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

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.

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.

...

...

...

Ở 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

Nhà phát triển phải cung cấp TOE và một tham chiếu cho TOE.

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:

...

...

...

- 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ó.

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

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.

...

...

...

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:

ALC_CMS.1.1C

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á:

...

...

...

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.

9.2.4.3  ALC_TSU_EXT.1 Cập nhật Bảo mật kịp thời

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.

...

...

...

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.

ALC_TSU_EXT.1.2C

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)).

...

...

...

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, với mỗi cơ chế thực hiện được mô tả trong quá trình cập nhật, TSS sẽ liệt kê thời gian giữa công bố công khai về lỗ hổng và thời gian có bản cập nhật bảo mật cho TOE để vá lỗ hổng này, bao gồm bất kỳ sự chậm trễ nào của bên thứ ba nào hoặc các bên chuyển phát khi triển khai. Người đánh giá sẽ phải xác nhận rằng thời gian này được diễn tả một hoặc nhiều ngày.

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)

...

...

...

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

TOE sẽ phải phù hợp với kiểm tra.

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

...

...

...

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ó.

Điều này cũng bao gồm cấu hình công cụ mã hóa được dùng. Các thuật toán mật mã được thực hiện bởi công cụ này là những quy định của PP này và được sử dụng bởi các giao thức mật mã đang được đánh giá (IPsec, TLS, SSH). Kế hoạch kiểm tra xác định các mục tiêu kiểm tra ở mức độ cao cũng như các thủ tục kiểm tra sẽ được tuân thủ để đạt được các mục tiêu đó. Các thủ tục này bao gồm các kết quả được mong đợi.

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)

...

...

...

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

TOE sẽ phải phù hợp cho kiểm tra.

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.

...

...

...

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.

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

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

...

...

...

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)

Ứng dụng sẽ phải tạo các khóa mật mã đối xứng sử dụng một Trình sinh bit ngẫu nhiên như được chỉ định trong FCS_RBG_EXT.1 (9.1.1) và chỉ định các kích thước khóa mật mã [lựa chọn:

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.

...

...

...

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

FCS_TLSC_EXT.2.1

Ứ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á 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.

Phụ lục B

(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

...

...

...

Ứ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.

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

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.

...

...

...

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.

Các đoạn sau đây chứa nhiều thông tin về một số giá trị đầu vào được tạo ra hoặc được chọn bởi người đánh giá.

Đầ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.

...

...

...

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:

128 bit,

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ó.

...

...

...

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ã

FCS_CKM_EXT.1.1

Ứ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.

B.3  FCS_CKM.1(1) Tạo khóa mật mã bất đối xứng

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.

Lưu ý khi thực hiện: Tác giả ST phải chọn tất cả các lược đồ tạo khóa được dùng để thiết lập khóa và xác thực thực thể. Khi tạo khóa được dùng cho thiết lập khóa, các lược đồ trong FCS_CKM.2.1 (Điều B.4 Phụ lục B) và các giao thức mật mã được chọn phải phù hợp với sự lựa chọn. Khi tạo khóa được dùng cho xác thực thực thể, khóa công khai mong muốn phải sẽ được kết hợp với chứng chỉ X.509v3.

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 đồ.

...

...

...

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

Người đánh giá sẽ phải xác nhận việc thực hiện tạo khóa RSA bằng TOE dùng thử nghiệm Tạo Khóa. Thử nghiệm này sẽ xác nhận khả năng của TSF để tạo chính xác các giá trị cho các thành phần của khóa bao gồm số mũ xác thực công khai e, các yếu tố nguyên tố riêng p và q, mô đun công cộng n và tính số mũ chữ ký riêng d. Việc tạo cặp khóa xác định 5 cách (hoặc phương pháp) để tạo ra các số nguyên tố p và q. Chúng bao gồm:

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:

...

...

...

• 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:

• n = p*q,

• 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 >= 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).

Tạo khóa cho các lược đồ RSA ANSI X9.31-1998

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”.

...

...

...

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ố mật mã và trường:

- 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

...

...

...

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:

- g! = 0,1

- 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.

...

...

...

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]],

[Các lược đồ thiết lập khóa dựa trên trường hữu hạn] đá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 đườ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 đồ.

Người đánh giá sẽ phải xác nhận rằng hướng dẫn AGD chỉ dẫn quản trị viên cách định cấu hình TOE để sử dụng (các) lược đồ thiết lập khóa đã chọn.

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]

...

...

...

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ẻ.

Người đánh giá sẽ phải xác minh tính chính xác của việc triển khai một lược đồ đã cho của TSF bằng cách sử dụng một thực hiện tốt đã biết để tính giá trị bí mật được chia sẻ, lấy được tài liệu khóa DKM và so sánh các giá trị băm (hash) hoặc các thẻ MAC được tạo ra từ các giá trị này.

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).

...

...

...

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.

Nếu TOE hoạt động như là người nhận, các 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 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)

...

...

...

- 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

] và kích thước khóa mật mã 256-bit và [lựa chọn: 128-bit, không có các kích thước khóa 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), 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ó 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ó.

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

Để 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

...

...

...

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

Người đánh giá sẽ phải kiểm tra tính năng mã hóa xác thực của AES-GCM cho mỗi kết hợp của các độ dài tham số đầu vào sau đây:

- 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 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)

Ứng dụng sẽ phải thực hiện các dịch vụ băm mật mã theo một thuật toán mật mã cụ thể [lựa chọn:

SHA-1,

SHA-256,

SHA-384,

SHA-512,

...

...

...

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

160,

256,

384,

512,

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.

...

...

...

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.

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 kiểm tra để 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.

- 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

...

...

...

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],

Các lược đồ ECDSA sử dụng các “đường cong NIST” P-256, P-384 và [lựa chọn: P-521, không có các đường cong khác] đáp ứng FIPS PUB 186-4, “Tiêu chuẩn Chữ ký Số (DSS)”, Điều 5 [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:

...

...

...

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

Các Kiểm tra Thuật toán Chữ ký RSA

- 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)

...

...

...

• HMAC-SHA-256

và [lựa chọn:

SHA-1,

SHA-384,

SHA-512,

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.

...

...

...

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

Ứ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ã hóa sau đây:

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_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_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,

...

...

...

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.

Nếu chọn thực hiện TLS 1.2 (RFC 5246), thì yêu cầu FCS_CKM.2 (Điều B.4 Phụ lục B), FCS_CKM_EXT.1 (Điều B.2 Phụ lục B), FCS_COP.1(1) (Điều B.5 Phụ lục B), FCS_COP.1(2) (Điều B.6 Phụ lục B), FCS_COP.1(3) (Điều B.7 Phụ lục B) và FCS_COP.1(4) (Điều B.8 Phụ lục B).

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 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.3: Sửa đổi bộ mã được chọn của máy chủ trong thông điệp bắt tay Server Hello thành bộ mã không được trình bày trong thông điệp bắt tay Client Hello. Người đánh giá sẽ phải xác nhận rằng máy khách từ chối kết nối sau khi nhận được Server Hello.

• 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

...

...

...

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 đảm bảo rằng TSS mô tả phương pháp của máy khách về thiết lập tất cả các bộ định danh tham chiếu từ bộ định danh tham chiếu của ứng dụng được cấu hình, bao gồm các loại của các bộ định danh tham chiếu được hỗ trợ (ví dụ Common Name, tên DNS, tên URI, Service Name hoặc các Subject Alternative Name của các ứng dụng được chỉ định khác) và cho dù có hỗ trợ các địa chỉ IP và ký tự đại diện. Người đánh giá sẽ phải đảm bảo rằng mô tả này xác định liệu rằng và cách thức nào mà trong đó chứng chỉ ghim (pinning) được hỗ trợ hoặc được dùng bởi TOE.

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 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 5.3: 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 ngay trước hậu tố công khai (ví dụ *.com). Người đánh giá sẽ phải cấu hình bộ định danh tham chiếu bằng một nhãn phía bên trái nhất (ví dụ foo.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 nhãn phía bên trái nhất (ví dụ: bar.foo.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ệ.

...

...

...

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:

- Kiểm tra 1: Người đánh giá sẽ phải chứng minh rằng một điểm ngang hàng sử dụng chứng chỉ mà không có đường dẫn chứng nhận hợp lệ dẫn đến lỗi xác thực. Sử dụng hướng dẫn quản trị, người đánh giá sẽ tải các chứng chỉ CA đáng tin cần thiết để xác nhận chứng chỉ của điềm ngang hàng và chứng minh rằng kết nối thành công. Người đánh giá sau đó sẽ phải xóa một trong các chứng chỉ CA, và cho thấy kết nối không thành công.

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).

...

...

...

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ủ.

B.11  FCS_TLSS_EXT.1 Giao thức Máy chủ của TLS

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_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_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_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á bị 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ợ nào ngoài các bộ bắt buộc, thì 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à được yêu cầu để đảm bảo tuân thủ RFC 5246.

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:

...

...

...

- 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.1: Thay đổi phiên bản TLS được chọn bởi máy chủ trong Server Hello thành phiên bản TLS không được hỗ trợ (ví dụ 1.3 được đại diện bởi 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 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.

...

...

...

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.

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

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].

...

...

...

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.

- Kiểm tra 1: Người đánh giá sẽ phải cố kết nối bằng cách sử dụng bộ mã ECDHE và một đường cong đã được cấu hình và sử dụng một bộ phân tích gói tin, xác thực rằng các thông số thỏa thuận khóa trong thông điệp Trao đổi khóa (Key Exchange message) là một cái được cấu hình. (Xác định rằng kích thước phù hợp với kích thước dự kiến cho đường cong được cấu hình là đủ) Người đánh giá sẽ phải lặp lại kiểm tra này cho mỗi Đường cong Elliptic (Elliptic Curve) của NIST được hỗ trợ và mỗi kích thước khóa Diffie-Hellman được hỗ trợ.

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

...

...

...

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.

Người đánh giá sẽ 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) sẽ bao gồm các chỉ dẫn để cấu hình 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 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).

Lưu ý khi thực hiện: Bộ nhận dạng ngang hàng có thể nằm trong trường Subject hoặc phần mở rộng Subject Alternative Name của chứng chỉ. Bộ định danh dự kiến hoặc có thể được cấu hình, hoặc có thể được so sánh với Tên miền, địa chỉ IP, tên người dùng hoặc địa chỉ email được sử dụng bởi người ngang hàng, hoặc có thể được chuyển đến một máy chủ thư mục để so sánh. Kết hợp nên được thực hiện bằng cách so sánh bit-wise.

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.

...

...

...

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:

- Kiểm tra 1: Người đánh giá sẽ phải cố thiết lập kết nối với máy chủ DTLS, quan sát lưu lượng truy cập bằng bộ phân tích gói tin và xác nhận rằng kết nối thành công và lưu lượng được xác định là DTLS.

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).

...

...

...

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ệ.

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.

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.

...

...

...

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:

Người đánh giá sẽ phải cố thiết lập một kết nối HTTPS với máy chủ web, quan sát lưu lượng bằng bộ phân tích gói tin, xác nhận rằng kết nối thành công và lưu lượng được xác định là TLS hoặc HTTPS.

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:

...

...

...

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.

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

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

...

...

...

- 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].

- Ứng dụng sẽ xác nhận trường extendedKeyUsage (sử dụng khóa mở rộng) theo các quy tắc sau:

• 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ỉ 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.

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

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.

...

...

...

• 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 5: Người đánh giá sẽ phải sửa đổi bất kỳ byte nào trong tám byte đầu tiên của chứng chỉ và chứng minh rằng chứng chỉ sẽ xác thực thất bại. (Chứng chỉ sẽ thất bại cho việc phân tích chính xác.)

- 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).

...

...

...

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 2: 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 không được thiết lập. 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].

...

...

...

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).

Lưu ý khi thực hiện: Thường một kết nối phải được thiết lập để thực hiện việc xác thực tình trạng thu hồi của một chứng chỉ - hoặc để tải xuống một CRL hoặc để thực hiện OCSP. Lựa chọn được dùng để mô tả hành vi trong trường hợp không thể thiết lập kết nối như vậy (ví dụ do lỗi mạng). Nếu TOE đã xác định chứng chỉ hợp lệ theo các quy tắc khác trong FIA_X509_EXT.1 (Điều B.14 Phụ lục B), hành vi được chỉ định trong việc lựa chọn sẽ xác định tính hợp lệ. TOE không được chấp nhận chứng chỉ nếu nó thất bại bất kỳ quy tắc xác thực nào khác trong 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 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 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)

Các yêu cầu mục tiêu

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.

...

...

...

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ủ.

C.2  FPT_API_EXT.2 sử dụng Các Dịch vụ Hỗ trợ và Các API

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.

...

...

...

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.

Lưu ý khi thực hiện: Các thẻ SWID hợp lệ phải chứa phần tử SoftwareIdentity (Nhận dạng của Phần mềm) và một phần tử Thực thể (Entity) được định nghĩa trong tiêu chuẩn ISO/IEC 19770-2:2009. Thẻ SWID phải được lưu trữ với phần mở rộng tệp là .swidtag theo định nghĩa trong 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

...

...

...

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ẽ bao gồm thiết kế của nguồn entropy như một tổng thể gồm tương tác của tất cả các thành phần nguồn entropy. Bất kỳ thông tin nào có thể được chia sẻ liên quan đến thiết kế cũng nên có các nguồn entropy của bất kỳ bên thứ ba nào có trong sản phẩm.

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

...

...

...

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.

Sự giải thích entropy sẽ không bao gồm bất kỳ dữ liệu nào được thêm vào từ bất kỳ ứng dụng của bên thứ ba nào hoặc từ bất kỳ trạng thái nào giữa các lần khởi động lại.

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.

Tương đương 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”.

[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

...

...

...

[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.

[13] NIST SP 800-57 part 1, Recommendation for Key Management, Part 1: General (Khuyến nghị cho Quản lý khóa, Phần 1: Tổng quát), Rev. 4, tháng 01/2016.

[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

...

...

...

[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

...

...

...

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.3  Yêu cầu phù hợp với PP

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

...

...

...

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  Các yêu cầ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.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.2  Lớp ADV: Phát triể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

...

...

...

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.2  FCS_CKM_EXT.1 Dịch vụ tạo khóa mật mã

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.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.12  FCS_DTLS_EXT.1 Thực hiện DTLS

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.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.2  Giải trình Entropy

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ể