"\r\n\r\n\r\n\r\n\r\nMicrosoft Word - TCVN 9735-5_2004.doc\r\n\r\n\r\n\r\n\r\n\r\n\r\n

\r\n\r\n

ISO\r\n9735-5:2002

\r\n\r\n

TRAO ĐỔI DỮ LIỆU ĐIỆN TỬ TRONG QUẢN LÝ HÀNH\r\nCHÍNH, THƯƠNG MẠI VÀ VẬN TẢI (EDIFACT) - CÁC QUY TẮC CÚ PHÁP MỨC ỨNG DỤNG (SỐ\r\nHIỆU PHIÊN BẢN CÚ PHÁP: 4, SỐ HIỆU PHÁT HÀNH CÚ PHÁP: 1) - PHẦN 5: QUY TẮC AN\r\nNINH CHO EDI LÔ (TÍNH XÁC THỰC, TÍNH TOÀN VẸN VÀ KHÔNG TỪ CHỐI GỐC)

\r\n\r\n

Electronic\r\ndata interchange for administration, commerce and transport (EDIFACT) -\r\nApplication level syntax rules (Syntax version number: 4, Syntax release\r\nnumber: 1) - Part 5: Security rules for batch EDI (authenticity, integrity and\r\nnon-repudiation of origin)

\r\n\r\n

Lời nói đầu

\r\n\r\n

TCVN ISO 9735-5:2004 hoàn toàn tương đương\r\nvới ISO 9735-5:2002.

\r\n\r\n

TCVN ISO 9735-5:2004 do Ban kỹ thuật tiêu\r\nchuẩn TCVN/TC 154 Quá trình, các yếu tố dữ liệu và tài liệu trong thương\r\nmại, công nghiệp và hành chính biên soạn, Tổng cục Tiêu chuẩn Đo lường Chất\r\nlượng đề nghị, Bộ Khoa học và Công nghệ ban hành.

\r\n\r\n

Tiêu chuẩn này được\r\nchuyển đổi năm 2008 từ Tiêu chuẩn Việt Nam cùng số hiệu thành Tiêu chuẩn Quốc gia\r\ntheo quy định tại khoản 1 Điều 69 của Luật Tiêu chuẩn và Quy chuẩn kỹ thuật và điểm\r\na khoản 1 Điều 6 Nghị định số 127/2007/NĐ-CP ngày 1/8/2007 của Chính phủ quy\r\nđịnh chi tiết thi hành một số điều của Luật Tiêu chuẩn và Quy chuẩn kỹ thuật.

\r\n\r\n

Lời giới thiệu

\r\n\r\n

Bộ tiêu chuẩn TCVN ISO 9735 gồm những phần\r\nsau, với tiêu đề chung “Trao đổi dữ liệu điện tử trong quản lý hành chính, thương\r\nmại và vận tải (EDIFACT) - Các quy tắc mức ứng dụng (Số hiệu phiên bản cú pháp:\r\n4, Số hiệu phát hành cú pháp: 1)”:

\r\n\r\n

- Phần 1: Quy tắc cú\r\npháp chung

\r\n\r\n

- Phần 2: Quy tắc cú\r\npháp đặc trưng cho EDI lô

\r\n\r\n

- Phần 3: Quy tắc cú\r\npháp đặc trưng cho EDI tương tác

\r\n\r\n

- Phần 4: Thông điệp\r\nbáo cáo dịch vụ và cú pháp cho EDI lô (kiểu thông điệp - CONTRL)

\r\n\r\n

- Phần 5: Quy tắc an\r\nninh cho EDI lô (tính xác thực, tính toàn vẹn và thừa nhận nguồn gốc)

\r\n\r\n

- Phần 6: Thông điệp\r\nbáo nhận và xác thực an ninh (kiểu thông điệp - AUTACK)

\r\n\r\n

- Phần 7: Quy tắc an ninh\r\ncho EDI lô (tính tin cậy)

\r\n\r\n

- Phần 8: Dữ liệu\r\nliên kết trong EDI

\r\n\r\n

- Phần 9: Thông điệp\r\nquản lý chứng nhận và khóa an ninh (kiểu thông điệp KEYMAN)

\r\n\r\n

- Phần 10: Danh mục\r\ndịch vụ cú pháp.

\r\n\r\n

Tiêu chuẩn này bao gồm\r\ncác quy tắc mức ứng dụng cho cấu trúc dữ liệu trong trao đổi thông điệp điện tử\r\ntrong một môi trường mở, được dựa trên các yêu cầu của cả hai xử lý lô hoặc tương\r\ntác.

\r\n\r\n

Các giao thức và đặc\r\ntả về truyền thông nằm ngoài phạm vi của tiêu chuẩn này.

\r\n\r\n

Phần này cung cấp một\r\nkhả năng tùy ý về bảo mật các cấu trúc EDIFACT lô, nghĩa là các thông điệp, các\r\ngói, các nhóm hoặc trao đổi.

\r\n\r\n

TRAO\r\nĐỔI DỮ LIỆU ĐIỆN TỬ TRONG QUẢN LÝ HÀNH CHÍNH, THƯƠNG MẠI VÀ VẬN TẢI (EDIFACT) -\r\nCÁC QUY TẮC CÚ PHÁP MỨC ỨNG DỤNG (SỐ HIỆU PHIÊN BẢN CÚ PHÁP: 4, SỐ HIỆU PHÁT\r\nHÀNH CÚ PHÁP: 1) - PHẦN 5: QUY TẮC AN NINH CHO EDI LÔ (TÍNH XÁC THỰC, TÍNH TOÀN\r\nVẸN VÀ KHÔNG TỪ CHỐI GỐC)

\r\n\r\n

Electronic\r\ndata interchange for administration, commerce and transport (EDIFACT) -\r\nApplication level syntax rules (Syntax version number:4, Syntax release number:\r\n1) - Part 5: Security rules for batch EDI (authenticity, integrity and\r\nnon-repudiation of origin)

\r\n\r\n

1. Phạm vi áp dụng

\r\n\r\n

Tiêu chuẩn này quy\r\nđịnh các quy tắc cú pháp an ninh EDIFACT và cung cấp một phương pháp tạo quy\r\ntắc an ninh mức thông điệp/gói, nhóm và trao đổi đối với tính xác thực, tính\r\ntoàn vẹn và không từ chối gốc, phù hợp với các cơ chế an ninh đã được xác lập.

\r\n\r\n

2. Sự phù hợp

\r\n\r\n

Do tiêu chuẩn này sử\r\ndụng số hiệu phiên bản “4” trong phần tử dữ liệu bắt buộc 0002 (số hiệu phiên\r\nbản cú pháp), và sử dụng số hiệu phát hành “01” trong phần tử dữ liệu điều kiện\r\n0076 (số hiệu phát hành cú pháp), mà mỗi số hiệu đều xuất hiện trong đoạn UNB\r\n(tiêu đề trao đổi), nên các trao đổi vẫn sử dụng cú pháp đã định nghĩa trong\r\ncác phiên bản trước phải sử dụng các số hiệu phiên bản cú pháp sau đây để phân\r\nbiệt chúng với nhau và với tiêu chuẩn này:

\r\n\r\n

- ISO 9735:1988: Số\r\nhiệu phiên bản cú pháp: 1

\r\n\r\n

- ISO 9735:1988 (Bổ\r\nsung và in lại năm 1990): Số hiệu phiên bản cú pháp: 2

\r\n\r\n

- ISO 9735:1988 và Bổ\r\nsung 1:1992: Số hiệu phiên bản cú pháp: 3

\r\n\r\n

- ISO 9735:1998: Số\r\nhiệu phiên bản cú pháp: 4

\r\n\r\n

Sự phù hợp với một\r\ntiêu chuẩn có nghĩa là tất cả mọi yêu cầu của tiêu chuẩn đó, bao gồm tất cả các\r\nlựa chọn đều phải được tuân thủ. Nếu không tuân thủ tất cả các lựa chọn thì\r\nphải công bố rõ các lựa chọn được công bố nào là phù hợp.

\r\n\r\n

Dữ liệu được trao đổi\r\nlà phù hợp nếu cấu trúc và biểu diễn dữ liệu đó phù hợp với các quy tắc cú pháp\r\nđược quy định trong tiêu chuẩn này.

\r\n\r\n

Các thiết bị hỗ trợ\r\ntiêu chuẩn này là phù hợp khi chúng có thể tạo và/hoặc thông dịch dữ liệu được\r\ncấu trúc và biểu diễn phù hợp với tiêu chuẩn này.

\r\n\r\n

Sự phù hợp với tiêu\r\nchuẩn này phải bao gồm sự phù hợp với TCVN ISO 9735-1, TCVN ISO 9735-2 và TCVN\r\nISO 9735-10.

\r\n\r\n

Khi được nêu trong\r\ntiêu chuẩn này, các điều khoản được định nghĩa trong các tiêu chuẩn liên quan phải\r\nlà những chuẩn mực về sự phù hợp.

\r\n\r\n

3. Tiêu chuẩn viện\r\ndẫn

\r\n\r\n

- TCVN ISO 9735- 1:2003,\r\nTrao đổi dữ liệu điện tử trong quản lý hành chính, thương mại và vận tải\r\n(EDIFACT) - Các quy tắc cú pháp mức ứng dụng (Số hiệu phiên bản cú pháp: 4, Số hiệu\r\nphát hành cú pháp: 1) - Phần 1: Quy tắc cú pháp chung.

\r\n\r\n

- TCVN ISO 9735- 2:2003,\r\nTrao đổi dữ liệu điện tử trong quản lý hành chính, thương mại và vận tải\r\n(EDIFACT) - Các quy tắc cú pháp mức ứng dụng (Số hiệu phiên bản cú pháp: 4, Số hiệu\r\nphát hành cú pháp: 1) - Phần 2: Quy tắc cú pháp đặc trưng cho EDI lô.

\r\n\r\n

- TCVN ISO 9735- 6:2004,\r\nTrao đổi dữ liệu điện tử trong quản lý hành chính, thương mại và vận tải\r\n(EDIFACT) - Các quy tắc cú pháp mức ứng dụng (Số hiệu phiên bản cú pháp: 4, Số hiệu\r\nphát hành cú pháp: 1) - Phần 6: Thông điệp báo nhận và xác thực an ninh (kiểu\r\nthông điệp - AUTACK).

\r\n\r\n

- TCVN ISO 9735- 7:2004,\r\nTrao đổi dữ liệu điện tử trong quản lý hành chính, thương mại và vận tải\r\n(EDIFACT) - Các quy tắc cú pháp mức ứng dụng (Số hiệu phiên bản cú pháp: 4, Số hiệu\r\nphát hành cú pháp: 1) - Phần 7: Quy tắc bảo mật cho EDI lô (độ tin cậy).

\r\n\r\n

- TCVN ISO 9735- 8:2004,\r\nTrao đổi dữ liệu điện tử trong quản lý hành chính, thương mại và vận tải\r\n(EDIFACT) - Các quy tắc cú pháp mức ứng dụng (Số hiệu phiên bản cú pháp: 4, Số hiệu\r\nphát hành cú pháp: 1) - Phần 8: Dữ liệu liên kết trong EDI.

\r\n\r\n

- TCVN ISO 9735-10:2004,\r\nTrao đổi dữ liệu điện tử trong quản lý hành chính, thương mại và vận tải\r\n(EDIFACT) - Các quy tắc cú pháp mức ứng dụng (Số hiệu phiên bản cú pháp: 4, Số hiệu\r\nphát hành cú pháp: 1) - Phần 10: Thư mục dịch vụ cú pháp.

\r\n\r\n

- ISO/IEC 10181- 2:1996,\r\nInformation technology - Open systems interconnection - Security frameworks for\r\nopen systems: Authentication framework (Công nghệ thông tin - Liên kết các\r\nhệ thống mở - Cơ cấu an ninh của các hệ thống mở: Cơ cấu xác thực).

\r\n\r\n

- ISO/IEC 10181- 4:1997,\r\nInformation technology - Open systems interconnection - Security frameworks for\r\nopen systems: Non-repudiation framework (Công nghệ thông tin - Liên kết các\r\nhệ thống mở - Cơ cấu an ninh của các hệ thống mở: Cơ cấu chấp nhận).

\r\n\r\n

- ISO/IEC 10181- 6:1996,\r\nInformation technology - Open systems interconnection - Security frameworks for\r\nopen systems: Integrity framework (Công nghệ thông tin - Liên kết các hệ\r\nthống mở - Cơ cấu an ninh của các hệ thống mở: Cơ cấu toàn vẹn).

\r\n\r\n

4. Thuật ngữ và định\r\nnghĩa

\r\n\r\n

Tiêu chuẩn này sử\r\ndụng các thuật ngữ và định nghĩa trong TCVN ISO 9735-1:2003

\r\n\r\n

5. Quy tắc sử dụng\r\ncác nhóm đoạn tiêu đề đuôi an ninh cho EDI lô.

\r\n\r\n

5.1. An ninh mức thông\r\nđiệp/gói - an ninh thông điệp/gói tích hợp

\r\n\r\n

5.1.1. Khái quát

\r\n\r\n

Mối đe dọa an ninh\r\nliên quan đến việc truyền thông điệp/gói và dịch vụ an ninh liên quan được\r\ntrình bày trong các Phụ lục A và B.

\r\n\r\n

Mục này mô tả cấu\r\ntrúc an ninh mức thông điệp/gói EDIFACT.

\r\n\r\n

Các dịch vụ an ninh được\r\nđề cập trong tiêu chuẩn này phải được đảm bảo bằng cách đặt các nhóm đoạn tiêu\r\nđề và đuôi an ninh sau đoạn UNH và trước đoạn UNT, cho mọi thông điệp, hoặc đặt sau đoạn UNO và trước đoạn UNP cho mọi gói.

\r\n\r\n

5.1.2. Các nhóm đoạn\r\ntiêu đề và các đuôi an ninh

\r\n\r\n

Hình 1 mô tả một trao\r\nđổi với an ninh tại mức thông điệp.

\r\n\r\n

Hình\r\n1 - Trao đổi với an ninh tại mức thông điệp (giản đồ)

\r\n\r\n

Hình 2 mô tả một trao\r\nđổi với an ninh tại mức gói.

\r\n\r\n

Hình\r\n2 - Trao đổi với an ninh tại mức gói (giản đồ)

\r\n\r\n

5.1.3. Cấu trúc các\r\nnhóm đoạn tiêu đề và đuôi an ninh

\r\n\r\n

Bảng\r\n1 - Bảng các nhóm đoạn tiêu đề và đuôi an ninh (an ninh mức thông điệp)

\r\n\r\n

Bảng\r\n2 - Bảng các nhóm đoạn tiêu đề và đuôi an ninh (an ninh mức gói)

\r\n\r\n

CHÚ THÍCH Đặc tả danh\r\nmục hoàn chỉnh của các đoạn và các phần tử dữ liệu, bao gồm các đoạn tiêu đề\r\nthông điệp UNH, đuôi thông điệp UNT, tiêu đề đối tượng UNO và đuôi đối tượng\r\nUNP được quy định trong TCVN ISO 9735-10. Danh mục phần tử dữ liệu của các đoạn\r\nnày không được mô tả thêm nữa trong tiêu chuẩn này.

\r\n\r\n

5.1.4. Giải thích\r\nđoạn dữ liệu

\r\n\r\n

Nhóm đoạn 1: USH -\r\nUSA - SG2 (nhóm tiêu đề an ninh)

\r\n\r\n

Nhóm đoạn xác định\r\ndịch vụ an ninh và các cơ chế an ninh được áp dụng và bao gồm dữ liệu cần thiết\r\nđể tiến hành các tính toán về tính hợp lệ.

\r\n\r\n

Có thể có một số nhóm\r\nđoạn tiêu đề an ninh khác nhau trong cùng một thông điệp/gói nếu có nhiều dịch\r\nvụ an ninh khác nhau được áp dụng cho thông điệp/gói đó (chẳng hạn như: tính\r\ntoàn vẹn và không từ chối gốc) hoặc nếu nhiều bên cùng áp dụng một dịch vụ an\r\nninh như vậy.

\r\n\r\n

USH, Tiêu đề an ninh

\r\n\r\n

Đoạn thuộc thông\r\nđiệp/gói nào thì chỉ rõ dịch vụ an ninh áp dụng cho thông điệp/gói đó.

\r\n\r\n

Các bên liên quan đến\r\ndịch vụ an ninh (bên tạo lập các phần tử an ninh và bên tiếp nhận các phần tử\r\nan ninh) có thể được định danh trong đoạn này, trừ khi các bên liên quan này được\r\nxác định rõ ràng thông qua các chứng chỉ (đoạn USC) khi sử dụng các thuật toán không đối xứng.

\r\n\r\n

Các chi tiết định\r\ndanh an ninh phần tử dữ liệu hỗn hợp (S500) phải được sử dụng trong đoạn USH,

\r\n\r\n

- nếu sử dụng các thuật\r\ntoán đối xứng, hoặc

\r\n\r\n

- nếu sử dụng các\r\nthuật toán không đối xứng khi hai chứng chỉ cùng tồn tại nhằm phân biệt chứng\r\nchỉ của bên tạo lập và chứng chỉ của bên tiếp nhận.

\r\n\r\n

Trong trường hợp sau,\r\nđịnh danh bên tham gia trong phần tử S500 (một trong các phần tử dữ liệu\r\nS500/0511, S500/0513, S500/0515, S500/0586) phải giống định danh của bên được\r\nhạn định là “bên sở hữu chứng chỉ” của một trong các phần tử dữ liệu S500 tồn\r\ntại trong đoạn USC trong nhóm đoạn 2 và phần tử dữ liệu S500/0577 phải xác định\r\nchức năng (bên tiếp nhận hoặc bên tạo lập) của các bên tham gia đó.

\r\n\r\n

Có thể sử dụng tên khóa\r\nphần tử dữ liệu trong phần tử dữ liệu hỗn hợp về chi tiết dịch vụ an ninh (S500/0538)\r\nđể thiết lập mối quan hệ khóa giữa bên gửi và bên tiếp nhận.

\r\n\r\n

Cũng có thể thiết lập\r\nmối quan hệ khóa bằng cách sử dụng định danh phần tử dữ liệu của khóa phần tử\r\ndữ liệu hỗn hợp về thông số thuật toán (S503/0554) trong đoạn USA của nhóm đoạn 1.

\r\n\r\n

Có thể sử dụng\r\nS500/0538 trong đoạn USH\r\nnếu\r\nkhông có nhu cầu truyền đoạn USA trong nhóm đoạn 1 (bởi vì các cơ chế mật mã hóa đã được thỏa\r\nthuận trước giữa các bên).

\r\n\r\n

Tuy nhiên, trong cùng\r\nmột nhóm tiêu đề an ninh, khuyến cáo sử dụng S500/0538 trong đoạn USH hoặc S503/0554 với\r\nhạn định thích hợp trong đoạn USA,\r\nnhưng không được sử dụng cả hai trong cùng một nhóm tiêu đề an ninh.

\r\n\r\n

Đoạn USH có thể chỉ rõ hàm lọc\r\nđược sử dụng cho các file nhị phân của đoạn USA trong nhóm đoạn 1 và của đoạn USR của nhóm đuôi an ninh\r\ntương ứng.

\r\n\r\n

Đoạn USH có thể bao gồm một số\r\nhiệu thứ tự an ninh để quy định tính toàn vẹn thứ tự và ngày tạo các phần tử an\r\nninh.

\r\n\r\n

USA, thuật toán an ninh

\r\n\r\n

Đoạn xác định một thuật\r\ntoán an ninh, kỹ thuật sử dụng tạo ra thuật toán và các tham số kỹ thuật hoặc\r\nyêu cầu. Thuật toán này phải được áp dụng trực tiếp trên thông điệp/gói. Thuật\r\ntoán này có thể là thuật toán đối xứng, hàm băm hoặc thuật toán nén. Ví dụ một chữ\r\nký số chỉ ra hàm băm phụ thuộc-thông điệp được sử dụng.

\r\n\r\n

Thuật toán không đối\r\nxứng không được đề cập trực tiếp trong đoạn USA của nhóm đoạn 1, nhưng có thể chỉ xuất hiện\r\ntrong nhóm đoạn 2 và được khởi tạo bởi một đoạn USC.

\r\n\r\n

Đoạn USA được phép xuất hiện\r\nba lần. Một lần xuất hiện được sử dụng cho thuật toán đối xứng hoặc hàm băm được\r\nyêu cầu để cung cấp dịch vụ an ninh quy định trong đoạn USH. Hai lần xuất hiện\r\nkhác được trình bày trong TCVN ISO 9735-7.

\r\n\r\n

Nếu thích hợp, có thể\r\nsử dụng chỉ dẫn cơ chế đệm.

\r\n\r\n

Nhóm đoạn 2: USC -\r\nUSA - USR (nhóm chứng chỉ)

\r\n\r\n

Nhóm đoạn chứa dữ\r\nliệu cần thiết để xác định tính hợp lệ của các phương pháp an ninh được áp dụng\r\ncho thông điệp/gói khi sử dụng các thuật toán không đối xứng. Nhóm đoạn chứng chỉ\r\nphải được sử dụng khi sử dụng các thuật toán không đối xứng để xác định cặp khóa\r\nkhông đối xứng đã được sử dụng, thậm chí khi các chứng chỉ không được sử dụng.

\r\n\r\n

Nhóm đoạn chứng chỉ\r\nđầy đủ (bao gồm cả đoạn USR) hoặc chỉ các phần\r\ntử dữ liệu cần thiết để xác định một cách rõ ràng cặp khóa không đối xứng đã được\r\nsử dụng phải có trong đoạn USC.\r\nCó thể không cần thiết đưa ra một chứng chỉ đầy đủ nếu chứng chỉ này vừa được\r\ntrao đổi bởi hai bên tham gia hoặc có thể được gọi ra từ một cơ sở dữ liệu.

\r\n\r\n

Khi áp dụng một chứng\r\nchỉ không phải là EDIFACT (ví dụ X.509), cú pháp và phiên bản chứng chỉ phải được\r\nxác định trong phần tử dữ liệu 0545 của đoạn USC. Các chứng chỉ này có thể được\r\ngửi trong một gói EDIFACT.

\r\n\r\n

Nhóm đoạn này được\r\nphép xuất hiện hai lần, một lần là chứng chỉ của bên gửi thông điệp/gói (mà bên\r\ntiếp nhận thông điệp/gói sẽ sử dụng để xác minh chữ ký của bên gửi), lần xuất\r\nhiện khác là chứng chỉ bên tiếp nhận thông điệp/gói (chỉ dành cho tham chiếu\r\nchứng chỉ) trong trường hợp khi mà bên gửi sử dụng khóa công bố của bên tiếp\r\nnhận để đảm bảo tính bảo mật của khóa đối xứng.

\r\n\r\n

Nếu nhóm đoạn này\r\nxuất hiện hai lần trong cùng một nhóm đoạn tiêu đề an ninh, thì phần tử dữ liệu\r\nhỗn hợp về chi tiết định danh an ninh (S500) cùng với phần tử dữ liệu tham\r\nchiếu chứng chỉ (0536) cho phép phân biệt chúng.

\r\n\r\n

Nhóm đoạn này phải lược\r\nbỏ nếu không sử dụng thuật toán không đối xứng.

\r\n\r\n

USC, chứng chỉ

\r\n\r\n

Đoạn chứa các thông tin\r\nvề năng lực của bên sở hữu chứng chỉ và xác định tổ chức chứng nhận cấp chứng chỉ.\r\nHàm lọc phần tử dữ liệu, đã mã hóa là (0505), phải xác định hàm lọc được sử\r\ndụng cho các trường nhị phân của các đoạn USA và đoạn USR trong nhóm đoạn 2.

\r\n\r\n

Phần tử dữ liệu S500 có\r\nthể xuất hiện hai lần trong Chứng chỉ USC: một lần cho bên sở hữu chứng chỉ (xác định\r\nbên đã ký cùng với khóa riêng kết hợp với khóa công bố trong chứng chỉ này),\r\nmột lần cho bên phát hành chứng chỉ (tổ chức chứng nhận hoặc CA).

\r\n\r\n

USA, thuật toán an\r\nninh

\r\n\r\n

Đoạn xác định một\r\nthuật toán an ninh, cách sử dụng kỹ thuật tạo ra thuật toán và chứa các tham số\r\nkỹ thuật được yêu cầu. Ba lần xuất hiện khác nhau của đoạn USA trong nhóm đoạn\r\n2 là:

\r\n\r\n

1. Bên phát hành\r\nchứng chỉ sử dụng thuật toán này để tính toán giá trị băm của chứng chỉ (hàm\r\nbăm);

\r\n\r\n

2. Bên phát hành\r\nchứng chỉ sử dụng thuật toán này để tạo ra chứng chỉ (nghĩa là ghi kết quả của\r\nhàm băm được tính toán vào nội dung chứng chỉ) (thuật toán không đối xứng);

\r\n\r\n

3a - Bên gửi sử dụng thuật\r\ntoán này để ghi vào thông điệp/gói (nghĩa là ghi kết quả của hàm băm được mô tả\r\ntrong đoạn USH, được tính toán vào nội dung thông điệp/gói) (thuật toán không đối\r\nxứng); hoặc

\r\n\r\n

3b - Bên gửi sử dụng thuật\r\ntoán không đối xứng của bên tiếp nhận để mật mã hóa khóa được yêu cầu bởi một\r\nthuật toán đối xứng thích hợp với nội dung thông điệp/gói và được đưa ra bởi\r\nnhóm đoạn 1 được khởi tạo bởi đoạn USH (thuật toán không đối xứng).

\r\n\r\n

Nếu thích hợp, có thể\r\nsử dụng chỉ dẫn cơ chế đệm.

\r\n\r\n

USR, kết quả an ninh

\r\n\r\n

Đoạn chứa kết quả của\r\nchức năng an ninh được áp dụng cho chứng chỉ bởi tổ chức chứng nhận. Kết quả\r\nnày chính là chữ ký của chứng chỉ được tính toán bởi tổ chức chứng nhận bằng cách\r\nký nhận kết quả băm được tính toán theo dữ liệu về khả năng.

\r\n\r\n

Đối với chứng chỉ,\r\nviệc tính toán chữ ký bắt đầu với ký tự đầu tiên của đoạn USC (ký tự “U”) và\r\nkết thúc với ký tự cuối cùng của đoạn USA cuối cùng (bao gồm cả dấu phân tách\r\ntheo sau đoạn USA).

\r\n\r\n

Nhóm đoạn n: UST -\r\nUSR (nhóm đuôi an ninh)

\r\n\r\n

Nhóm đoạn chứa một liên\r\nkết với nhóm đoạn tiêu đề an ninh và kết quả của các chức năng an ninh được áp\r\ndụng cho thông điệp/gói.

\r\n\r\n

UST, đuôi an ninh

\r\n\r\n

Đoạn thiết lập một\r\nliên kết giữa nhóm đoạn tiêu đề an ninh và nhóm đoạn đuôi an ninh, và cho biết\r\nsố lượng các đoạn an ninh chứa trong các nhóm này.

\r\n\r\n

USR, kết quả an ninh

\r\n\r\n

Đoạn chứa kết quả của\r\ncác chức năng an ninh được áp dụng cho thông điệp/gói như quy định trong nhóm tiêu\r\nđề an ninh liên kết. Tùy thuộc vào các cơ chế an ninh quy định trong nhóm tiêu đề\r\nan ninh, kết quả này phải:

\r\n\r\n

- được tính toán trực\r\ntiếp theo thông điệp/gói bằng thuật toán quy định trong đoạn USA trong nhóm đoạn 1 của\r\nnhóm tiêu đề an ninh, hoặc là

\r\n\r\n

- được tính toán bằng\r\ncách ký nhận cùng với một thuật toán không đối xứng được quy định trong đoạn USA trong nhóm đoạn 2 của\r\nnhóm đoạn tiêu đề an ninh, một kết quả băm được tính toán theo thông điệp/gói\r\nbằng thuật toán được quy định trong đoạn USA trong nhóm đoạn 1 của nhóm đoạn tiêu đề an\r\nninh.

\r\n\r\n

5.1.5. Phạm vi áp\r\ndụng an ninh

\r\n\r\n

Có hai khả năng cho\r\nphạm vi áp dụng an ninh:

\r\n\r\n

1. Việc tính toán mỗi\r\ngiá trị xác thực và toàn vẹn và tính toán các chữ ký số bắt đầu bằng và bao gồm\r\ncả nhóm đoạn tiêu đề an ninh hiện thời và thân thông điệp hoặc đối tượng. Trong\r\ntrường hợp này, các nhóm đoạn tiêu đề an ninh và đuôi an ninh khác đều phải nằm\r\nngoài phạm vi này.

\r\n\r\n

Nhóm đoạn tiêu đề an\r\nninh phải được tính từ ký tự đầu tiên, ký tự “U”, đến dấu phân tách kết thúc nhóm đoạn tiêu\r\nđề an ninh này, gồm cả hai, thân thông điệp hoặc đối tượng từ ký tự đầu tiên\r\nsau dấu phân tách kết thúc nhóm đoạn tiêu đề an ninh cuối cùng đến dấu phân\r\ntách trước ký tự đầu tiên của nhóm đoạn đuôi an ninh đầu tiên.

\r\n\r\n

Do đó trật tự các\r\ndịch vụ an ninh được tích hợp theo cách này đã được thực hiện, không cần quy định.\r\nCác dịch vụ an ninh này hoàn toàn độc lập với nhau.

\r\n\r\n

Hình 3 minh họa trường\r\nhợp này (phạm vi áp dụng dịch vụ an ninh được xác định trong tiêu đề an ninh 2\r\nđược biểu diễn bằng các khối bóng).

\r\n\r\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n

\r\n

UNH/UNO

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 3

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 2

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 1

\r\n

THÂN\r\n THÔNG ĐIỆP/ĐỐI TƯỢNG

\r\n

Nhóm\r\n đoạn đuôi an ninh 1

\r\n

Nhóm\r\n đoạn đuôi an ninh 2

\r\n

Nhóm\r\n đoạn đuôi an ninh 3

\r\n

UNT/UNP

\r\n

\r\n\r\n

Hình\r\n3 - Phạm vi áp dụng: chỉ nhóm đoạn tiêu đề an ninh và thân thông điệp/đối tượng\r\n(giản đồ)

\r\n\r\n

2. Tính toán bắt đầu\r\nvà bao gồm nhóm đoạn tiêu đề an ninh hiện hành tới nhóm đoạn đuôi an ninh được\r\nliên kết. Trong trường hợp này nhóm đoạn tiêu đề an ninh hiện thời thân, thông điệp\r\nhoặc đối tượng, và tất cả các nhóm đoạn tiêu đề và đuôi an ninh được nhúng khác\r\nnằm trong phạm vi này.

\r\n\r\n

Phạm vi này phải bao gồm\r\ntất cả ký tự từ ký tự đầu tiên, ký tự “U”, của nhóm đoạn tiêu đề an ninh hiện thời\r\ntới dấu phân tách trước ký tự đầu tiên của nhóm đoạn đuôi an ninh được liên\r\nkết.

\r\n\r\n

Hình 4 minh họa trường\r\nhợp này (phạm vi áp dụng dịch vụ an ninh được xác định trong tiêu đề an ninh 2\r\nđược biểu diễn bằng các khối bóng).

\r\n\r\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n

\r\n

UNH/UNO

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 3

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 2

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 1

\r\n

THÂN\r\n THÔNG ĐIỆP/ĐỐI TƯỢNG

\r\n

Nhóm\r\n đoạn đuôi an ninh 1

\r\n

Nhóm\r\n đoạn đuôi an ninh 2

\r\n

Nhóm\r\n đoạn đuôi an ninh 3

\r\n

UNT/UNP

\r\n

\r\n\r\n

Hình\r\n4 - Phạm vi áp dụng: từ nhóm đoạn tiêu đề an ninh tới nhóm đoạn đuôi an ninh\r\n(giản đồ)

\r\n\r\n

Đối với mỗi dịch vụ\r\nan ninh, có thể chọn một trong hai cách.

\r\n\r\n

Trong cả hai trường hợp,\r\nmối quan hệ giữa nhóm đoạn tiêu đề an ninh và nhóm đoạn đuôi an ninh tương ứng\r\nphải được cung cấp bởi số hiệu tham chiếu an ninh của các phần tử dữ liệu trong\r\nđoạn UST\r\nvà USH.

\r\n\r\n

5.2. Nguyên tắc sử\r\ndụng

\r\n\r\n

5.2.1. Lựa chọn dịch\r\nvụ

\r\n\r\n

Nhóm đoạn tiêu đề an\r\nninh có thể gồm thông tin chung sau:

\r\n\r\n

- dịch vụ an ninh được\r\náp dụng;

\r\n\r\n

- định danh của các\r\nbên liên quan;

\r\n\r\n

- cơ chế an ninh được\r\nsử dụng;

\r\n\r\n

- giá trị “duy nhất” (số\r\nhiệu thứ tự và/hoặc thẻ thời gian);

\r\n\r\n

- không-từ chối yêu\r\ncầu nhận.

\r\n\r\n

Nếu có hơn một dịch\r\nvụ an ninh được yêu cầu cho cùng một cấu trúc EDIFACT thì nhóm đoạn tiêu đề an ninh có thể\r\nxuất hiện nhiều lần. Trong trường hợp này có nhiều cặp của các bên liên quan.\r\nTuy nhiên, nếu nhiều dịch vụ được yêu cầu giữa hai bên thì chúng có thể được\r\ngộp trong một cặp nhóm đoạn tiêu đề và được bảo vệ khi mà chắc chắn các dịch vụ\r\nbao hàm nhau hoàn toàn.

\r\n\r\n

5.2.2. Tính xác thực

\r\n\r\n

Nếu có yêu cầu về xác\r\nthực gốc của một cấu trúc EDIFACT thì phải phù hợp với các nguyên tắc trong ISO/IEC 10181-2\r\nbằng cách sử dụng một cặp nhóm đoạn tiêu đề an ninh và đuôi an ninh thích hợp.

\r\n\r\n

Dịch vụ an ninh xác\r\nthực gốc phải quy định trong đoạn USH và thuật toán được định danh trong đoạn USA trong nhóm đoạn 1\r\nphải là một thuật toán đối xứng.

\r\n\r\n

Bên khởi tạo dịch vụ\r\nan ninh phải tính toán một giá trị xác thực được truyền trong đoạn USR của nhóm đoạn đuôi an\r\nninh. Bên tiếp nhận dịch vụ an ninh phải kiểm tra giá trị xác thực.

\r\n\r\n

Dịch vụ này có thể\r\nbao gồm dịch vụ toàn vẹn và có thể đạt được như dịch vụ phụ của dịch vụ không từ\r\nchối gốc.

\r\n\r\n

Nếu thực hiện một\r\ncách thích hợp dịch vụ “xác thực gốc” dựa trên phần cứng chống giả mạo hoặc được\r\nchứng thực bởi bên thứ ba được xem như một trường hợp của dịch vụ “không từ\r\nchối gốc”. Trên thực tế, dịch vụ này được xác định trong thỏa thuận trao đổi.

\r\n\r\n

5.2.3. Tính toàn vẹn

\r\n\r\n

Nếu có yêu cầu về\r\ntính toàn vẹn nội dung một cấu trúc EDIFACT thì phải phù hợp với các nguyên tắc trong ISO/IEC\r\n10181-6 bằng cách sử dụng một cặp nhóm đoạn tiêu đề an ninh và đuôi an ninh\r\nthích hợp.

\r\n\r\n

Dịch vụ an ninh về\r\ntính toàn vẹn phải quy định trong đoạn USH, và thuật toán được xác định trong đoạn USA của nhóm đoạn 1.\r\nThuật toán này phải là hàm băm hoặc một thuật toán đối xứng.

\r\n\r\n

Bên khởi tạo dịch vụ\r\nan ninh phải tính toán một giá trị toàn vẹn được truyền trong đoạn USR của nhóm đoạn đuôi an\r\nninh. Bên tiếp nhận dịch vụ an ninh phải kiểm tra giá trị toàn vẹn.

\r\n\r\n

Dịch vụ này có thể\r\nđạt được như dịch vụ phụ của dịch vụ xác thực gốc hoặc dịch vụ không từ chối\r\ngốc.

\r\n\r\n

Nếu có yêu cầu về\r\ntoàn vẹn thứ tự thì số hiệu thứ tự an ninh hoặc một thẻ thời gian an ninh hoặc\r\ncả hai phải được chứa trong nhóm đoạn tiêu đề an ninh và phải sử dụng hoặc dịch\r\nvụ về tính toàn vẹn nội dung hoặc dịch vụ xác thực gốc hoặc dịch vụ không từ\r\nchối gốc.

\r\n\r\n

5.2.4. Không từ chối\r\ngốc

\r\n\r\n

Nếu có yêu cầu không từ\r\nchối gốc một cấu trúc EDIFACT\r\nthì phải\r\nphù hợp với các nguyên tắc trong ISO/IEC 10181-4 bằng cách sử dụng một cặp nhóm\r\nđoạn tiêu đề an ninh và đuôi an ninh thích hợp.

\r\n\r\n

Dịch vụ an ninh không\r\ntừ chối gốc phải quy định trong đoạn USH và thuật toán băm phải quy định trong đoạn USA trong nhóm đoạn 1, và\r\nthuật toán không đối xứng được sử dụng cho chữ ký trong các đoạn USA của nhóm đoạn 2 nếu\r\nsử dụng các chứng chỉ.

\r\n\r\n

Nếu chứng chỉ không được\r\ntruyền trong thông điệp/gói thì thuật toán không đối xứng phải được xác định\r\nhoàn toàn bởi bên tiếp nhận. Trong trường hợp này, thuật toán không đối xứng phải\r\nđược xác định trong thỏa thuận trao đổi.

\r\n\r\n

Bên khởi tạo dịch vụ\r\nan ninh phải tính toán một chữ ký số được truyền trong đoạn USR của nhóm đoạn đuôi an\r\nninh. Bên tiếp nhận dịch vụ an ninh phải xác định giá trị chữ ký số này.

\r\n\r\n

Dịch vụ này cũng cung\r\ncấp cả dịch vụ về tính toàn vẹn nội dung và xác thực gốc.

\r\n\r\n

5.3. Các bộ lọc và\r\nbiểu diễn nội bộ theo cú pháp EDIFACT

\r\n\r\n

Có hai vấn đề khi sử\r\ndụng các thuật toán toán học để tính toán các giá trị toàn vẹn và các chữ ký\r\nsố.

\r\n\r\n

Vấn đề thứ nhất là\r\nkết quả tính toán phụ thuộc vào sự biểu diễn nội bộ của bộ ký tự. Do đó việc\r\ntính toán chữ ký số được thực hiện bởi bên gửi và bên tiếp nhận phải sử dụng cùng\r\nbộ ký tự mã hóa để xác định. Do đó bên gửi có thể chỉ ra việc biểu diễn được sử\r\ndụng để đưa ra kết quả an ninh gốc hợp lệ.

\r\n\r\n

Vấn đề thứ hai là kết\r\nquả tính toán có vẻ như là một mẫu bít ngẫu nhiên. Đây có thể là nguyên nhân\r\ngây ra các vấn đề trong quá trình truyền và với phần mềm biên dịch. Để tránh\r\ncác vấn đề này thì mẫu bít có thể được ánh xạ ngược tới một biểu diễn đặc biệt của\r\nbộ ký tự bằng phương pháp hàm lọc. Để đơn giản, mỗi dịch vụ an ninh chỉ sử dụng\r\nmột hàm lọc. Bất kỳ hiện tượng kết thúc khác thường nào ở đầu ra ánh xạ này được\r\ngiải quyết bằng một trình tự thoát.

\r\n\r\n

6. Quy tắc sử dụng\r\nnhóm đoạn tiêu đề và đuôi an ninh của nhóm và trao đổi cho EDI lô

\r\n\r\n

6.1. An ninh mức nhóm\r\nvà mức trao đổi - an ninh thông điệp tích hợp

\r\n\r\n

Các mối đe dọa an\r\nninh liên quan đến việc truyền thông điệp/gói và các dịch vụ an ninh dùng để\r\nchống lại các mối đe dọa đó được mô tả trong các phụ lục A và B cũng hợp lệ đối\r\nvới mức nhóm và trao đổi.

\r\n\r\n

Các kỹ thuật đã mô tả\r\nở mục trước về áp dụng an ninh cho các thông điệp/gói cũng có thể áp dụng cho\r\nnhóm và trao đổi.

\r\n\r\n

Đối với an ninh mức nhóm\r\nvà trao đổi, phải sử dụng cùng các nhóm đoạn tiêu đề và nhóm đoạn đuôi như đã\r\nmô tả ở mức thông điệp/gói, và sự tham chiếu ngang của tiêu đề - đuôi phải áp\r\ndụng tại cùng mức, cả khi dịch vụ an ninh được áp dụng riêng tại nhiều hơn một\r\nmức.

\r\n\r\n

Khi dịch vụ an ninh được\r\náp dụng tại mức thông điệp/gói cấu trúc được bảo vệ là thân thông điệp hoặc đối\r\ntượng. Tại mức nhóm, cấu trúc được bảo vệ là bộ các các thông điệp/gói trong\r\nnhóm bao gồm tất cả các tiêu đề và đuôi thông điệp/gói. Tại mức trao đổi, cấu\r\ntrúc được bảo vệ là bộ các thông điệp/gói hoặc các nhóm trong trao đổi bao gồm tất\r\ncả các tiêu đề và đuôi thông điệp hoặc nhóm.

\r\n\r\n

6.2. Nhóm đoạn tiêu\r\nđề và đuôi an ninh

\r\n\r\n

Hình 5 - Mô tả một\r\ntrao đổi với an ninh tại cả mức nhóm và mức trao đổi.

\r\n\r\n

Hình\r\n5 - Trao đổi với an ninh tại cả mức nhóm và mức trao đổi (giản đồ)

\r\n\r\n

6.3. Cấu trúc các nhóm\r\nđoạn tiêu đề và đuôi an ninh

\r\n\r\n

Bảng\r\n3 - Bảng đoạn các nhóm đoạn tiêu đề và đuôi an ninh (chỉ an ninh mức trao đổi)

\r\n\r\n

Bảng\r\n4 - Bảng\r\nđoạn các nhóm đoạn tiêu đề và đuôi an ninh (chỉ an ninh mức nhóm)

\r\n\r\n

CHÚ THÍCH Đặc tả danh mục hoàn\r\nchỉnh của các đoạn và phần tử dữ liệu bao gồm các đoạn tiêu đề trao đổi UNB,\r\ncác đoạn đuôi trao đổi UNZ, tiêu đề nhóm UNG và đuôi nhóm UNE quy định trong\r\ntiêu chuẩn TCVN ISO 9735-10 không được mô tả trong tiêu chuẩn này.

\r\n\r\n

6.4. Phạm vi áp dụng\r\nan ninh

\r\n\r\n

Có hai khả năng phạm\r\nvi áp dụng an ninh

\r\n\r\n

1. Tính toán mỗi giá\r\ntrị xác thực và toàn vẹn và tính toán các chữ ký số bắt đầu và bao gồm với\r\nchính nhóm đoạn tiêu đề an ninh hiện hành và cả (các) thông điệp/(các) gói hoặc\r\n(các) nhóm. Trong trường hợp này, nhóm đoạn tiêu đề hoặc đuôi an ninh khác\r\nkhông thuộc phạm vi này.

\r\n\r\n

Nhóm đoạn tiêu đề an\r\nninh được tính từ ký tự đầu tiên, ký tự “U”, đến dấu phân tách kết thúc nhóm đoạn tiêu\r\nđề an ninh này, gồm cả hai, và (các) thông điệp/(các)gói hoặc (các) nhóm thì từ\r\nký tự đầu tiên sau dấu phân tách kết thúc nhóm đoạn tiêu đề an ninh cuối cùng\r\nđến dấu phân tách trước ký tự đầu tiên của nhóm đoạn đuôi an ninh đầu tiên, bao\r\ngồm cả hai.

\r\n\r\n

Do đó thứ tự các dịch\r\nvụ an ninh được tích hợp theo cách này, không cần quy định. Các dịch vụ an ninh\r\nnày hoàn toàn độc lập với nhau.

\r\n\r\n

Hình 6 và 7 minh họa cho\r\ntrường hợp này (phạm vi áp dụng dịch vụ an ninh xác định trong tiêu đề an ninh\r\n2 được biểu diễn bằng các khối bóng).

\r\n\r\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n

\r\n

UNB

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 3

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 2

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 1

\r\n

(CÁC)\r\n NHÓM HOẶC (CÁC) THÔNG ĐIỆP/(CÁC) GÓI

\r\n

Nhóm\r\n đoạn đuôi an ninh 1

\r\n

Nhóm\r\n đoạn đuôi an ninh 2

\r\n

Nhóm\r\n đoạn đuôi an ninh 3

\r\n

UNZ

\r\n

\r\n\r\n

Hình\r\n6 - Phạm vi áp dụng: nhóm đoạn tiêu đề an ninh và (các) nhóm hoặc chỉ (các) thông\r\nđiệp/(các) gói (giản đồ)

\r\n\r\n

\r\n\r\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n

\r\n

UNG

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 3

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 2

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 1

\r\n

(CÁC)\r\n THÔNG ĐIỆP/(CÁC) GÓI

\r\n

Nhóm\r\n đoạn đuôi an ninh 1

\r\n

Nhóm\r\n đoạn đuôi an ninh 2

\r\n

Nhóm\r\n đoạn đuôi an ninh 3

\r\n

UNE

\r\n

\r\n\r\n

Hình\r\n7 - Phạm vi áp dụng: chỉ nhóm đoạn tiêu đề an ninh và (các) thông điệp/(các) gói\r\n(giản đồ)

\r\n\r\n

2. Việc tính toán bắt\r\nđầu và bao gồm cả nhóm đoạn tiêu đề an ninh hiện tới nhóm đoạn đuôi an ninh được\r\nliên kết. Trong trường hợp này, nhóm đoạn tiêu đề an ninh hiện hành, (các) thông\r\nđiệp/(các) gói hoặc (các) nhóm và tất cả các nhóm đoạn tiêu đề và nhóm đoạn\r\nđuôi an ninh được nhúng khác thuộc phạm vi này.

\r\n\r\n

Phạm vi này bao gồm tất\r\ncả các ký tự từ ký tự đầu tiên, ký tự “U”, của nhóm đoạn tiêu đề an ninh hiện hành,\r\nđến dấu phân tách trước ký tự đầu tiên của nhóm đoạn đuôi an ninh liên kết, bao\r\ngồm cả hai.

\r\n\r\n

Hình 8 và 9 minh họa cho\r\ntrường hợp này (phạm vi áp dụng dịch vụ an ninh xác định trong tiêu đề an ninh\r\n2 được biểu diễn bằng các khối bóng).

\r\n\r\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n

\r\n

UNB

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 3

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 2

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 1

\r\n

(CÁC)\r\n NHÓM HOẶC (CÁC) THÔNG ĐIỆP/(CÁC) GÓI

\r\n

Nhóm\r\n đoạn đuôi an ninh 1

\r\n

Nhóm\r\n đoạn đuôi an ninh 2

\r\n

Nhóm\r\n đoạn đuôi an ninh 3

\r\n

UNZ

\r\n

\r\n\r\n

Hình\r\n8 - Phạm vi áp dụng: từ nhóm đoạn tiêu đề an ninh tới nhóm đoạn đuôi an ninh\r\n(giản đồ)

\r\n\r\n

\r\n\r\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n

\r\n

UNG

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 3

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 2

\r\n

Nhóm\r\n đoạn tiêu đề an ninh 1

\r\n

(CÁC)\r\n THÔNG ĐIỆP/(CÁC) GÓI

\r\n

Nhóm\r\n đoạn đuôi an ninh 1

\r\n

Nhóm\r\n đoạn đuôi an ninh 2

\r\n

Nhóm\r\n đoạn đuôi an ninh 3

\r\n

UNE

\r\n

\r\n\r\n

Hình\r\n9 - Phạm vi áp dụng: từ nhóm đoạn tiêu đề an ninh tới nhóm đoạn đuôi an ninh\r\n(giản đồ)

\r\n\r\n

Đối với mỗi dịch vụ\r\nan ninh được bổ sung, có thể chọn một trong hai phương pháp trên.

\r\n\r\n

Trong cả hai trường hợp,\r\nmối liên hệ giữa nhóm đoạn tiêu đề và đuôi an ninh được kết nối phải được cung\r\ncấp bởi số hiệu tham chiếu an ninh của các phần tử dữ liệu trong các đoạn UST và USH.

\r\n\r\n

Phụ lục A
\r\n(tham\r\nkhảo)

\r\n\r\n

Các mối đe dọa và giải pháp cho an\r\nninh EDIFACT

\r\n\r\n

A.1. Giới thiệu

\r\n\r\n

Phụ lục này mô tả các\r\nmối đe dọa an ninh chung do truyền thông điệp/gói giữa (các) bên khởi tạo thông\r\nđiệp/gói và (các) bên tiếp nhận. Phương pháp tiếp cận chung để khắc phục các\r\nmối đe dọa này cũng được nói đến. Các mối đe dọa và giải pháp này liên quan đến\r\ntất cả các mức: thông điệp/gói, nhóm hoặc trao đổi.

\r\n\r\n

A.2. Các mối đe dọa\r\nan ninh

\r\n\r\n

Việc lưu trữ và\r\ntruyền các thông điệp/gói EDIFACT qua môi trường và phương tiện điện tử dẫn đến một số mối\r\nđe dọa, đáng chú ý là:

\r\n\r\n

- Để lộ nội dung\r\nthông điệp/gói một cách trái phép;

\r\n\r\n

- chèn có chủ định\r\ncác thông điệp/gói giả;

\r\n\r\n

- sao chép, mất mát\r\nhoặc lặp lại các thông điệp/gói;

\r\n\r\n

- thay đổi nội dung\r\nthông điệp/gói;

\r\n\r\n

- xóa các thông\r\nđiệp/gói;

\r\n\r\n

- từ chối chịu trách nhiệm\r\nvề thông điệp/gói của bên gửi hoặc bên tiếp nhận.

\r\n\r\n

Các mối đe dọa trên\r\ncó thể do cố ý như việc thao tác trái phép trên nội dung thông điệp/gói, hoặc\r\ndo vô ý như một lỗi truyền thông làm thay đổi nội dung thông điệp/gói.

\r\n\r\n

A.3. Các giải pháp an\r\nninh - Các dịch vụ cơ bản và các nguyên tắc sử dụng

\r\n\r\n

A.3.1. Khái quát

\r\n\r\n

Để chống lại các mối\r\nđe dọa nói trên, một số cơ chế an ninh đã được xác định có sử dụng một hoặc\r\nnhiều phương pháp luận nhằm đáp ứng những mục đích tương ứng.

\r\n\r\n

Điều quan trọng là có\r\nthể xác định rõ ràng các bên liên quan khi các thông điệp/gói được bảo vệ -bên\r\nkhởi tạo an ninh, để cho đơn giản gọi là bên gửi, là bên khởi tạo dịch vụ an\r\nninh thông điệp/gói trước khi truyền và bên tiếp nhận an ninh, để cho đơn giản\r\ngọi là bên tiếp nhận, là bên thực hiện kiểm tra thông điệp/gói nhận được. Các\r\nbên tham gia có thể được xác định trong các đoạn an ninh. Để xác định các bên\r\ncó thể sử dụng các phương pháp được gọi là chứng chỉ (trong thực tế, hoặc là\r\nmột chứng chỉ thật hoặc là một tham chiếu chứng chỉ), được giải thích bên dưới,\r\nnếu sử dụng các thuật toán không đối xứng.

\r\n\r\n

Điển hình yêu cầu sử\r\ndụng một tổ chức chứng nhận trong một hệ thống mở. Đây là bên thứ ba được ủy quyền\r\nbởi các bên liên quan với một mức độ giới hạn, cụ thể là để xác định và lưu trữ\r\ntất cả bên sử dụng cùng khóa công bố. Thông tin này được chuyển đến các bên sử\r\ndụng khác bằng cách sử dụng một chứng chỉ, đó là một chữ ký số do CA phát hành trên một\r\nthông điệp chứa thông tin định danh bên sử dụng cùng khóa công bố của bên sử\r\ndụng. Trong trường hợp này, sự ủy thác hoàn toàn mang tính chức năng và không\r\nliên quan đến bảo mật hoặc khóa riêng.

\r\n\r\n

Ngoài ra, nếu sử dụng\r\ncác kỹ thuật đối xứng để xác định các bên liên quan được chỉ ra trong các trường\r\ntên bên gửi/bên tiếp nhận an ninh.

\r\n\r\n

Một thông điệp/gói có\r\nthể được bảo vệ bởi nhiều bên tham gia (ví dụ một thông điệp/gói có nhiều chữ\r\nký số) và vì vậy các thông tin an ninh liên quan có thể được lặp lại để cho\r\nphép định danh nhiều nhiều bên tham gia ký nhận hoặc chứng nhận và bao gồm\r\nnhiều chữ ký điện tử và giá trị kiểm soát tương ứng.

\r\n\r\n

Các yêu cầu và kỹ\r\nthuật được quy định để bảo vệ thông điệp/gói, nhóm hoặc trao đổi EDIFACT được\r\ntrình bày bên dưới.

\r\n\r\n

A.3.2. Toàn vẹn thứ\r\ntự

\r\n\r\n

Tính toàn vẹn thứ tự\r\nbảo vệ ngăn ngừa sao chép, thêm, xóa, mất hoặc lặp lại một cấu trúc EDIFACT (thông điệp/gói, nhóm\r\nhoặc trao đổi).

\r\n\r\n

Để phát hiện các\r\nthông điệp/gói, nhóm hoặc trao đổi bị mất:

\r\n\r\n

- bên gửi và có thể\r\ncả bên tiếp nhận kiểm tra một số hiệu thứ tự (liên quan đến dòng thông điệp/gói\r\ngiữa hai bên liên quan);

\r\n\r\n

- bên gửi có thể yêu\r\ncầu và kiểm tra tin báo nhận;

\r\n\r\n

Để phát hiện các\r\nthông điệp/gói, các nhóm hoặc trao đổi bị thêm hoặc nhân đôi;

\r\n\r\n

- bên gửi và có thể\r\ncả bên tiếp nhận kiểm tra một số hiệu thứ tự;

\r\n\r\n

- bên gửi và có thể\r\ncả bên tiếp nhận kiểm tra một thẻ thời gian;

\r\n\r\n

Khi các số hiệu thứ tự\r\nđược sử dụng chúng phải được thỏa thuận giữa các bên tham gia về cách thức quản\r\nlý.

\r\n\r\n

Thẻ thời gian thường được\r\ntạo ra bởi hệ thống của bên gửi. Điều này hàm ý rằng, như trong dạng giấy, độ\r\nchính xác ban đầu của giá trị thẻ thời gian chỉ nằm dưới sự kiểm soát của bên\r\ngửi.

\r\n\r\n

Để có sự bảo vệ đầy\r\nđủ, tính toàn vẹn của thẻ thời gian hoặc số hiệu thứ tự phải bảo đảm bằng một\r\ntrong các chức năng khác được đề cập sau đây.

\r\n\r\n

A.3.3. Toàn vẹn nội\r\ndung

\r\n\r\n

Dịch vụ an ninh về\r\ntính toàn vẹn nội dung bảo vệ chống lại sự thay đổi dữ liệu.

\r\n\r\n

Việc bảo vệ có thể được\r\nthực hiện bởi bên gửi bao gồm một giá trị kiểm soát tính toàn vẹn. Giá trị này\r\nđược tính toán bằng cách sử dụng một thuật toán mật mã hóa thích hợp, chẳng hạn\r\nMDC (mã phát hiện sự thay\r\nđổi). Vì chính giá trị kiểm soát này không được bảo vệ nên cần bổ sung các phép\r\nđánh giá lên giá trị kiểm soát như gửi giá trị kiểm soát bằng một kênh dành\r\nriêng hoặc việc tính toán một chữ ký số, thậm chí cần thiết cung cấp cả an ninh\r\nkhông - từ chối gốc trên giá trị kiểm soát này. Ngoài ra, Để sự xác thực gốc đạt\r\nđược bằng việc sử dụng một mã xác thực thông điệp phải bao gồm cả dịch vụ về\r\ntính toàn vẹn nội dung. Bên tiếp nhận tính toán giá trị kiểm soát toàn vẹn của dữ\r\nliệu thực sự nhận được thông qua việc sử dụng các thuật toán và tham số tương\r\nứng và so sánh kết quả với giá trị nhận được.

\r\n\r\n

Cuối cùng, dịch vụ về\r\ntính toàn vẹn nội dung trong EDI thường đạt được như là dịch vụ phụ của dịch vụ an ninh\r\nxác thực gốc hoặc không - từ chối gốc.

\r\n\r\n

A.3.4. Xác thực gốc

\r\n\r\n

Xác thực gốc bảo vệ\r\nbên tiếp nhận chống lại bên gửi thực tế một thông điệp/gói, một nhóm hoặc trao đổi\r\ntự cho là một bên tham gia (được phép) khác.

\r\n\r\n

Sự bảo vệ có thể thực\r\nhiện nhờ một giá trị xác thực (ví dụ như MAC: Mã xác thực thông điệp). Giá trị này phụ\r\nthuộc vào cả nội dung dữ liệu và một khóa bí mật của bên gửi.

\r\n\r\n

Dịch vụ này có thể\r\nbao gồm tính toàn vẹn nội dung và có thể đạt được như dịch vụ phụ của dịch vụ\r\nan ninh không từ chối gốc.

\r\n\r\n

Trong đa số trường\r\nhợp, càng ít dịch vụ xác thực gốc càng tốt.

\r\n\r\n

A.3.5. Không - từ\r\nchối gốc

\r\n\r\n

Không - từ chối gốc bảo\r\nvệ bên tiếp nhận một thông điệp/gói, nhóm hoặc trao đổi tránh việc phủ nhận đã\r\ngửi thông điệp/gói, một nhóm hoặc trao đổi đó của bên gửi.

\r\n\r\n

Sự bảo vệ có thể thực\r\nhiện nhờ một chữ ký số (hoặc bằng việc sử dụng thích hợp chức năng đã được mô\r\ntả trong “xác thực gốc” trên cơ sở phần cứng chống giả mạo hoặc sự xác thực của\r\ncác bên thứ ba). Một chữ ký số thu được khi mã hóa với một thuật toán không đối\r\nxứng và một khóa riêng, đối tượng hoặc một giá trị kiểm soát được tạo ra từ dữ\r\nliệu này (ví dụ sử dụng một hàm băm).

\r\n\r\n

Chữ ký số có thể được\r\nxác minh bằng việc sử dụng khóa công bố được tạo ra từ khóa riêng tương ứng.\r\nKhóa công bố này có thể bao gồm trong thỏa thuận trao đổi đã bởi các bên tham gia\r\nhoặc trong một chứng chỉ số được ký hiệu bởi tổ chức chứng nhận. Chứng chỉ này\r\ncó thể được gửi như một phần của cấu trúc EDIFACT.

\r\n\r\n

Chữ ký số không chỉ\r\ncung cấp dịch vụ không - từ chối gốc mà còn dịch vụ về tính toàn vẹn nội dung và\r\nxác thực gốc.

\r\n\r\n

A.3.6. Không - từ\r\nchối nhận của bên tiếp nhận

\r\n\r\n

Không - từ chối nhận\r\ncủa bên tiếp nhận bảo vệ bên gửi mộ thông điệp/gói, nhóm hoặc trao đổi trước sự\r\ntừ chối nhận của bên tiếp nhận.

\r\n\r\n

Sự bảo vệ có thể thực\r\nhiện qua việc bên tiếp nhận gửi một báo nhận có chứa một chữ ký số dựa trên dữ liệu\r\ntrong cấu trúc EDI\r\ngốc. Báo\r\nnhận này đưa mẫu một thông điệp dịch vụ từ bên tiếp nhận tới bên gửi.

\r\n\r\n

A.3.7. Độ tin cậy về\r\nnội dung

\r\n\r\n

Độ tin cậy về nội\r\ndung nhằm tránh để lộ, sao chép hoặc đọc trái phép nội dung một nhóm hoặc thông\r\nđiệp/gói trao đổi.

\r\n\r\n

Sự bảo vệ có thể đảm\r\nbảo nhờ mật mã hóa dữ liệu. Mật mã hóa có thể thực hiện bằng cách sử dụng một\r\nthuật toán đối xứng với một khóa bí mật được dùng chung bởi bên gửi và bên tiếp\r\nnhận.

\r\n\r\n

Tuy nhiên, khóa bí\r\nmật có thể được truyền đi an toàn bằng cách mật mã hóa theo một thuật toán\r\nkhông đối xứng dưới dạng khóa công bố của bên tiếp nhận.

\r\n\r\n

Độ tin cậy được trình\r\nbày riêng trong TCVN ISO 9735-7.

\r\n\r\n

A.3.8. Mối quan hệ\r\ngiữa các dịch vụ an ninh

\r\n\r\n

Như đã nói, một số\r\ndịch vụ an ninh bản thân đã bao hàm cả dịch vụ khác, do đó không cần thiết bổ\r\nsung các dịch vụ đã đạt được hoàn toàn. Ví dụ, sử dụng cơ chế cung cấp dịch vụ\r\nkhông - từ chối gốc bao gồm dịch vụ về tính toàn vẹn nội dung.

\r\n\r\n

Bảng A.1 Tổng kết mối\r\nquan hệ.

\r\n\r\n

Bảng\r\nA.1 - Bảng tương quan

\r\n\r\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n

\r\n Sử\r\n dụng \r\n	\r\n Bao\r\n gồm \r\n
\r\n Sử\r\n dụng \r\n	\r\n Toàn\r\n vẹn nội dung \r\n	\r\n Xác\r\n thực gốc \r\n	\r\n Không\r\n từ chối gốc \r\n
\r\n Toàn vẹn nội dung \r\n	\r\n có \r\n	\r\n - \r\n	\r\n - \r\n
\r\n Xác thực gốc \r\n	\r\n có \r\n	\r\n có \r\n	\r\n - \r\n
\r\n Không - từ chối gốc \r\n	\r\n có \r\n	\r\n có \r\n	\r\n có \r\n

\r\n\r\n

Phụ lục B
\r\n(tham\r\nkhảo)

\r\n\r\n

Cách bảo vệ một cấu trúc EDIFACT

\r\n\r\n

B.1. Khái quát

\r\n\r\n

Sau đây là một số bước\r\ncơ bản được dùng để thực hiện an ninh cho các cấu trúc EDIFACT: trao đổi, nhóm hoặc\r\nthông điệp/gói. Chi tiết và giải thích các nguyên tắc được đề cập đến trong Phụ\r\nlục A, ISO 7498 - 2 và ISO/IEC 9594-8/CCITT X.509.

\r\n\r\n

Bước đầu tiên là xác\r\nđịnh (kết hợp với các nghiệp vụ liên quan) nhu cầu dịch vụ an ninh. Các dịch vụ\r\nan ninh thông dụng của EDIFACT\r\ndưới đây\r\nlà quan trọng để đáp ứng các yêu cầu nghiệp vụ tránh các mối đe dọa an ninh đã\r\nđược xác định. Các nhu cầu này có thể được xác định thông qua yêu cầu kiểm tra\r\nnội bộ cũng như bên ngoài. Các dịch vụ an ninh cơ bản có sẵn tại bên gửi là:

\r\n\r\n

- tính toàn vẹn nội\r\ndung;

\r\n\r\n

- xác thực gốc;

\r\n\r\n

- không - từ chối\r\ngốc.

\r\n\r\n

Các dịch vụ này không\r\nđộc lập nhau mà chúng đã hàm chứa lẫn nhau, do đó không cần thiết bổ sung các\r\ndịch vụ đã được bao gồm trong dịch vụ khác. Ví dụ, nếu sử dụng dịch vụ không -\r\ntừ chối gốc thì cũng đạt được dịch vụ về tính toàn vẹn nội dung.

\r\n\r\n

Các mối quan hệ này được\r\ntổng kết trong Bảng A.1.

\r\n\r\n

Do đó, bên gửi chỉ\r\ncần chọn một trong ba dịch vụ.

\r\n\r\n

Không - từ chối nhận\r\nviệc nhận là dịch vụ được bắt đầu từ bên tiếp nhận. Nó có thể được yêu cầu bởi\r\nbên gửi hoặc được đề nghị trong một thỏa thuận trao đổi. Thông điệp AUTACT được phát triển để\r\nmang thông tin về sự nhận được.

\r\n\r\n

B.2. Thỏa thuận song\r\nphương/bên thứ ba

\r\n\r\n

Nếu các dịch vụ an ninh\r\nđược tích hợp, các thỏa thuận bổ sung phải được thiết lập cùng với các bên tham\r\ngia nghiệp vụ. Có một số cách tiếp cận khác nhau, ở đây trình bày ngắn gọn hai\r\ntrường hợp đại diện.

\r\n\r\n

Một yêu cầu tối thiểu\r\nvề dịch vụ an ninh, thuật toán, mã hóa, phương pháp quản lý khóa, hành động\r\nkhắc phục lỗi, v.v có thể là một thỏa thuận song phương với mỗi bên tham gia\r\nriêng lẻ với nhau. Ví dụ; Một bản dự thảo thỏa thuận có sẵn từ Chương trình TEDIS của Ủy ban Châu Âu.\r\nTrong trường hợp này, cần thiết rất ít thông tin an ninh liên quan trong bản\r\nthân thông điệp/gói này.

\r\n\r\n

Trong trường hợp đối\r\nvới mức độ an ninh cao liên quan đến một bên thứ ba có vai trò như một tổ chức\r\nchứng nhận, lưu trữ hồ sơ của tất cả các bên sử dụng và phát hành các chứng chỉ\r\nđể chứng nhận khóa công bố. Trường hợp này, hoàn toàn là việc ký kết một thỏa thuận\r\nvới tổ chức chứng nhận. Tổ chức chứng nhận đại diện chịu trách nhiệm ghi vào\r\ndanh sách đen. Trường hợp này có thể cần bao gồm nhiều thông tin an ninh liên\r\nquan.

\r\n\r\n

Các dịch vụ an ninh được\r\ntích hợp trong EDIFACT\r\nthiết\r\nlập theo cách nhằm tạo sự linh hoạt tối đa và phục vụ cho cả hai trường hợp\r\ntrên cũng như cho bất cứ trường hợp nào.

\r\n\r\n

B.3. Khía cạnh thực\r\ntế

\r\n\r\n

Trên thực tế, có một số\r\nkhía cạnh khác nhau cần thiết để xác định dịch vụ an ninh như tạo khóa, nhu cầu\r\ncó bộ chuyển dịch có khả năng điều khiển các đoạn an ninh, các thủ tục nội bộ\r\nđể sử dụng đầy đủ các dịch vụ an ninh, như là lưu trữ thông điệp/gói đến cùng\r\ncác chữ ký số, sử dụng đa chữ ký, v.v.

\r\n\r\n

Cần nhấn mạnh rằng\r\nviệc tích hợp các dịch vụ an ninh là hoàn toàn rõ ràng và độc lập với các giao\r\nthức truyền thông được sử dụng. Nếu một hệ thống cho phép truyền một thông điệp/gói\r\nEDIFACT cũng cho phép truyền\r\nmột thông điệp/gói EDIFACT\r\nan ninh.

\r\n\r\n

B.4. Thủ tục xây dựng\r\nmột cấu trúc EDIFACT\r\nan\r\nninh

\r\n\r\n

Trước tiên, cấu trúc EDIFACT như thông điệp/gói,\r\nnhóm hoặc trao đổi được tạo ra. Sau đó, các dịch vụ an ninh thích hợp được xác\r\nđịnh và áp dụng. Nếu dịch vụ này dựa trên các chữ ký số thì các cá nhân xử lý\r\nkhóa riêng phải được liên quan một cách trực tiếp hoặc gián tiếp. Nhưng điều\r\nnày không cần phải thực hiện ngay lập tức sau khi tạo cấu trúc EDIFACT

\r\n\r\n

Tương tự như hoạt\r\nđộng lưu trữ giấy tờ, bước đầu tiên là xác minh các dịch vụ an ninh cấu trúc EDIFACT, có thể lưu cấu trúc\r\nEDIFACT đã đảm bảo an ninh\r\ncho việc kiểm tra và làm tài liệu chứng từ sau này.

\r\n\r\n

B.5. Thứ tự các dịch\r\nvụ an ninh áp dụng

\r\n\r\n

Thứ tự các dịch vụ an\r\nninh được thực hiện hoàn toàn tùy ý đối với người sử dụng do tất cả các dịch vụ\r\nan ninh là độc lập hoàn toàn với nhau. Đặc biệt, nếu sử dụng nhiều chữ ký số,\r\nngoài việc nhúng các nhóm đoạn an ninh và đoạn tiêu đề an ninh còn tính toán và\r\nxác minh thứ tự các nhóm đoạn này trong cấu trúc EDIFACT.

\r\n\r\n

B.6. An ninh thông\r\nđiệp phân tách tại mức thông điệp/gói

\r\n\r\n

B.6.1. Các yêu cầu\r\nnghiệp vụ

\r\n\r\n

Có hai yêu cầu nghiệp\r\nvụ cho đặc tính này, đó là:

\r\n\r\n

a) cung cấp an ninh\r\ncho một hoặc nhiều thông điệp/gói trong một thông điệp riêng từ bên gửi,

\r\n\r\n

b) cung cấp một báo\r\nnhận được đảm bảo an ninh cho bên gửi khi nhận được (các) thông điệp/(các) gói\r\ngốc mà không trả lại.

\r\n\r\n

Các yêu cầu này có thể\r\nđáp ứng bằng xác thực an ninh và thông điệp báo nhận AUTACK, được trình bày\r\ntrong TCVN ISO 9735- 6.

\r\n\r\n

B.6.2. An ninh thông\r\nđiệp phân tách được sử dụng bởi bên gửi

\r\n\r\n

Việc sử dụng AUTACK này cho phép bên gửi\r\ncung cấp bất kỳ dịch vụ an ninh nào nhưng được tiến hành trong một thông điệp\r\ntách biệt. Do đó, các dịch vụ an ninh có thể được truyền vào một thời điểm\r\nthích hợp hơn sau đó. Hơn nữa, chúng có thể bảo vệ cho vài thông điệp/gói gốc, khác\r\nvới sự tích hợp trực tiếp, chúng chỉ bảo vệ một thông điệp/gói tại một thời\r\nđiểm ở mức thông điệp/gói.

\r\n\r\n

Các nguyên tắc này\r\ndành cho các cách tiếp cận tách biệt và tích hợp, nhưng cách sau yêu cầu một\r\ntham chiếu duy nhất tới gói/thông điệp gốc đang được bảo vệ.

\r\n\r\n

B.6.3. An ninh thông\r\nđiệp phân tách được sử dụng bởi bên tiếp nhận

\r\n\r\n

Việc sử dụng AUTACK này đáp ứng yêu cầu\r\ncung cấp không - từ chối nhận của bên tiếp nhận. Chi tiết về thông điệp xem\r\nphần AUTACK\r\ntrong\r\nTCVN ISO 9735- 6:2004.

\r\n\r\n

AUTACK được sử dụng như một báo\r\nnhận được đảm bảo an ninh được gửi bởi bên tiếp nhận của một hoặc nhiều trao đổi\r\nhoặc một hoặc nhiều gói/thông điệp từ một hoặc nhiều trao đổi đến bên gửi của\r\nchúng. Một AUTACK\r\nđược\r\nphát đi tới bên gửi của trao đổi hoặc thông điệp/gói gốc cùng với báo nhận an\r\nninh là cách thức tiêu chuẩn có nghĩa rằng bên bên tham gia đã nhận được trao đổi\r\nhoặc thông điệp/gói.

\r\n\r\n

B.7. An ninh thông\r\nđiệp phân tách tại mức nhóm hoặc mức trao đổi

\r\n\r\n

Kỹ thuật trình bày\r\ncho an ninh thông điệp/gói phân tách trong mục D.5 tại mức thông điệp/gói có thể\r\nđược sử dụng để bảo vệ cho trao đổi hoàn chỉnh hoặc nhóm hoàn chỉnh. Hai yêu\r\ncầu nghiệp vụ đặc trưng là:

\r\n\r\n

a) cung cấp an ninh\r\ncho một hoặc nhiều nhóm trao đổi hoặc trong một thông điệp tách biệt từ bên\r\ngửi;

\r\n\r\n

b) cung cấp một báo\r\nnhận đã được đảm bảo an ninh tới bên gửi về việc nhận được các nhóm hoặc (các) trao\r\nđổi gốc mà không gửi lại chúng.

\r\n\r\n

Các yêu cầu này có thể\r\nđược đáp ứng bằng xác thực an ninh và thông điệp báo nhận AUTACK được trình bày trong\r\nTCVN ISO 9735- 6:2004.

\r\n\r\n

Phụ lục C
\r\n(tham\r\nkhảo)

\r\n\r\n

Các ví dụ về bảo vệ thông điệp

\r\n\r\n

C.1. Giới thiệu

\r\n\r\n

Ba ví dụ trong phụ\r\nlục này minh họa việc áp dụng khác nhau của các đoạn dịch vụ an ninh.

\r\n\r\n

Các ví dụ về an ninh thông\r\nđiệp này dựa trên cơ sở các hóa đơn thanh toán EDIFACT như trình bày trong sổ tay MIG về các thông điệp tài\r\nchính được SWIFT\r\nban hành.\r\nTuy nhiên, những cơ chế an ninh được trình bày ở đây là hoàn toàn độc lập với\r\nkiểu thông điệp và có thể áp dụng cho bất kỳ thông điệp EDIFACT nào.

\r\n\r\n

“Ví dụ 1: xác thực nguồn\r\ngốc thông điệp” chỉ\r\nra cách các đoạn dịch vụ an ninh có thể được sử dụng khi áp dụng phương pháp\r\ndựa trên cơ sở thuật toán đối xứng để cung cấp dịch vụ xác thực nguồn gốc thông\r\nđiệp. Khóa đối xứng được trao đổi trước đó giữa các bên tham gia và nhóm đoạn\r\ntiêu đề an ninh chỉ chứa đúng hai đoạn đơn giản.

\r\n\r\n

“Ví dụ 2: không - từ\r\nchối gốc, kỹ thuật thứ nhất” chỉ ra cách các đoạn dịch vụ an ninh có thể được\r\nsử dụng khi áp dụng phương pháp dựa trên cơ sở một thuật toán không đối xứng để\r\ncung cấp dịch vụ không từ chối gốc. Thuật toán áp dụng trực tiếp cho thông điệp\r\nlà một hàm băm, hàm băm này không yêu cầu bất kỳ trao đổi khóa nào giữa\r\ncác bên tham gia. Giá trị - băm này được ký hiệu bằng một thuật toán không đối\r\nxứng. Khóa công bố mà bên tiếp nhận cần để xác minh chữ ký của thông điệp được\r\nchứa trong một đoạn chứng chỉ được truyền trong nhóm đoạn tiêu đề an ninh của\r\nthông điệp. Chứng chỉ này được ký hiệu bởi người phát hành (“bên chứng nhận”\r\nnào đó) và chứa khóa công bố của bên chứng nhận đó, để bên tham gia nào\r\ncũng có thể xác minh tính toàn vẹn hoặc tính xác thực của chứng chỉ.

\r\n\r\n

“Ví dụ 3: không - từ\r\nchối gốc, kỹ thuật thứ hai” chỉ ra cách các đoạn dịch vụ an ninh có thể được\r\nsử dụng khi áp dụng phương pháp dựa trên cơ sở một thuật toán không đối xứng để\r\ncung cấp dịch vụ không - từ chối gốc. Thuật toán áp dụng trực tiếp vào thông điệp\r\nlà một thuật toán đối xứng, thuật toán đối xứng này yêu cầu một trao đổi khóa đối\r\nxứng giữa các bên tham gia và cung cấp một “giá trị toàn vẹn”. Khóa đối xứng\r\nnày được trao đổi trong nhóm đoạn tiêu đề an ninh của thông điệp, được mã hóa bằng\r\nmột thuật toán không đối xứng dưới dạng khóa công bố của người nhận.

\r\n\r\n

Giá trị toàn vẹn này\r\nđược ký hiệu bằng một thuật toán không đối xứng. Khóa công bố cần cho bên tiếp\r\nnhận để xác minh chữ ký của thông điệp có trong đoạn chứng chỉ thứ nhất, đoạn\r\nnày được truyền trong nhóm đoạn tiêu đề an ninh của thông điệp. Chứng chỉ này được\r\nký hiệu bởi bên phát hành nó (“bên chứng nhận” nào đó) và chứa khóa công\r\nbố của bên chứng nhận trong trường hợp một bên tham gia nào đó có thể xác minh\r\ntính toàn vẹn hoặc tính xác thực của chứng chỉ.

\r\n\r\n

Một đoạn chứng chỉ\r\nthứ hai chứa một tham chiếu đến khóa công bố của bên tiếp nhận, được sử dụng\r\nbởi bên gửi thông điệp để bảo vệ khóa đối xứng.

\r\n\r\n

Kỹ thuật này hiện nay\r\nđược các ngân hàng Pháp sử dụng trong hệ thống ETEBAC 5 (truyền file đã được đảm bảo an ninh\r\ngiữa các ngân hàng và khách hàng công ty).

\r\n\r\n

Trong hai ví dụ sau,\r\nbất kỳ bên tham gia được ủy thác là bên có thẩm quyền nào cũng có thể xác minh\r\nchữ ký của thông điệp nhận được mà chỉ cần sử dụng dữ liệu chứa trong thông điệp.

\r\n\r\n

C.2. Ví dụ 1: xác\r\nthực nguồn gốc thông điệp

\r\n\r\n

C.2.1. Tình huống

\r\n\r\n

Công ty A yêu cầu\r\nNgân hàng A, dùng mã 603000 để ghi vào sổ nợ số tài khoản 00387806 tổng số 54345,10\r\nbảng Anh vào ngày 09 tháng 04 năm 1996. Tổng số tiền này được trả cho ngân hàng\r\nB, dùng mã phân loại 201827 với số tài khoản 00663151 của công ty B, Bến tầu\r\nphía tây, Milford Haven. Việc thanh toán theo hóa đơn 62345. Tên liên hệ của bên\r\nđược trả nợ là ông Jones thuộc Phòng Kinh doanh.

\r\n\r\n

Ngân hàng A yêu cầu\r\nthủ tục thanh toán được đảm bảo an ninh bằng chức năng an ninh “xác thực nguồn\r\ngốc thông điệp”. Việc này được thực hiện bằng việc tạo ra một “Mã Xác thực Thông\r\nđiệp” (MAC) cùng với “Tiêu chuẩn Mã hóa Dữ liệu” đối xứng (DES) tuân\r\ntheo ISO 8731-1 tại bên gửi thông điệp, được kiểm tra tính hợp lệ bởi Ngân hàng\r\nA. Giả sử rằng Khóa - DES bí mật đã được trao đổi trước giữa Công ty A và Ngân\r\nhàng A.

\r\n\r\n

Lưu ý:

\r\n\r\n

Trong phần sau đây,\r\nchỉ những phần liên quan đến an ninh của thông điệp mới được đề đến.

\r\n\r\n

C.2.2. Chi tiết an\r\nninh

\r\n TIÊU ĐỀ AN NINH \r\n		\r\n \r\n
\r\n DỊCH VỤ AN NINH \r\n		\r\n Xác thực nguồn gốc\r\n thông điệp \r\n
\r\n SỐ HIỆU THAM CHIẾU\r\n AN NINH \r\n		\r\n Tham chiếu của tiêu\r\n đề này là 1. \r\n
\r\n HÀM LỌC \r\n		\r\n Tất cả giá trị nhị\r\n phân (MAC) được lọc bằng bộ lọc thập lục phân. \r\n
\r\n MÃ HÓA BỘ KÝ TỰ GỐC \r\n		\r\n Thông điệp được mã\r\n hóa thành mã ASCII 8 bít khi MAC được tạo ra. \r\n
\r\n CHI TIẾT ĐỊNH DANH\r\n AN NINH \r\n Bên gửi thông điệp\r\n (bên tạo ra Mã Xác thực Thông điệp). \r\n		\r\n Ông Smith ở Công ty\r\n A \r\n
	\r\n CHI TIẾT ĐỊNH DANH\r\n AN NINH \r\n Bên tiếp nhận thông\r\n điệp (bên xác minh Mã Xác thực Thông điệp). \r\n		\r\n Ngân hàng A \r\n
	\r\n SỐ HIỆU THỨ TỰ AN\r\n NINH \r\n		\r\n Số hiệu thứ tự an\r\n ninh của thông điệp này là 001. \r\n
	\r\n NGÀY THÁNG VÀ THỜI\r\n GIAN AN NINH \r\n		\r\n Thẻ thời gian an\r\n ninh có dạng: ngày 1996 04 09 thời gian: 13:59:50. \r\n
	\r\n THUẬT TOÁN AN NINH \r\n		\r\n \r\n
	\r\n THUẬT TOÁN AN NINH \r\n Sử dụng thuật toán \r\n Phương thức hoạt\r\n động mật mã hóa \r\n Thuật toán \r\n		\r\n Sử dụng một thuật\r\n toán đối xứng cho xác thực nguồn gốc thông điệp. \r\n Một MAC được tính\r\n toán, theo ISO 8731-1. \r\n Sử dụng thuật toán\r\n DES. \r\n
	\r\n THAM SỐ THUẬT TOÁN \r\n Hạn định tham số\r\n thuật toán \r\n Giá trị tham số\r\n thuật toán \r\n		\r\n Xác định giá trị\r\n tham số thuật toán sau bằng tên của một khóa đối xứng được trao đổi trước đó. \r\n Khóa sử dụng là MAC\r\n - KEY1. \r\n
	\r\n ĐUÔI AN NINH \r\n		\r\n \r\n
	\r\n SỐ HIỆU THAM CHIẾU\r\n AN NINH \r\n		\r\n Số tham chiếu của\r\n đuôi là 1. \r\n
	\r\n SỐ LƯỢNG ĐOẠN AN\r\n NINH \r\n \r\n		\r\n 4 \r\n
	\r\n KẾT QUẢ AN NINH \r\n		\r\n \r\n
	\r\n KẾT QUẢ HỢP LỆ \r\n Hạn định giá trị\r\n hợp lệ \r\n Giá trị hợp lệ \r\n		\r\n \r\n MAC \r\n 4 byte Kết quả hợp\r\n lệ (Mã Xác thực Thông điệp) \r\n

\r\n\r\n

C.3. Ví dụ 2: Không -\r\ntừ chối gốc, kỹ thuật thứ nhất

\r\n\r\n

C.3.1. Tình huống

\r\n\r\n

Ngân hàng A muốn sử\r\ndụng dịch vụ an ninh không từ chối gốc cho đơn đặt hàng thanh toán từ Công ty A,\r\nđược thực hiện bởi ông Smith.

\r\n\r\n

Ngân hàng A yêu cầu\r\nthiết lập dịch vụ an ninh không- từ chối gốc trong Thỏa thuận trao đổi giữa các\r\nbên tham gia để hoàn tất các đơn đặt hàng thanh toán bởi ông Smith ở Công ty A,\r\nbằng cách sử dụng một chữ ký số.

\r\n\r\n

Chứng chỉ xác nhận khóa\r\ncông bố của ông Smith được phát hành bởi một cơ quan có thẩm quyền đã được ủy\r\nquyền bởi cả hai bên, Bên phát hành chứng chỉ.

\r\n\r\n

C.3.2. Chi tiết an\r\nninh

\r\n TIÊU ĐỀ AN NINH \r\n	\r\n \r\n
\r\n DỊCH VỤ AN NINH \r\n	\r\n Không - từ chối gốc \r\n
\r\n SỐ HIỆU THAM CHIẾU\r\n AN NINH \r\n	\r\n Tham chiếu của tiêu\r\n đề này là 1. \r\n
\r\n HÌNH THỨC ĐÁP ỨNG \r\n	\r\n Không yêu cầu báo\r\n nhận. \r\n
\r\n HÀM LỌC \r\n	\r\n Tất cả giá trị nhị\r\n phân (các chữ ký) được lọc bằng bộ lọc thập lục phân. \r\n
\r\n MÃ HÓA BỘ KÝ TỰ GỐC \r\n	\r\n Thông điệp được mã\r\n hóa thành mã ASCII 8 bít khi chữ ký của nó được tạo ra \r\n
\r\n SỐ HIỆU THỨ TỰ AN\r\n NINH \r\n	\r\n Số hiệu thứ tự an\r\n ninh của thông điệp là 202. \r\n
\r\n NGÀY THÁNG VÀ THỜI\r\n GIAN AN NINH \r\n	\r\n Thẻ thời gian an\r\n ninh có dạng: ngày: 1996 01 15,thời gian: 10:05:30. \r\n
\r\n THUẬT TOÁN AN NINH \r\n	\r\n Ông Smith sử dụng\r\n hàm băm cho chữ ký. \r\n
\r\n THUẬT TOÁN AN NINH \r\n Sử dụng thuật toán \r\n Phương thức hoạt\r\n động mật mã hóa \r\n \r\n \r\n \r\n \r\n \r\n Thuật toán \r\n	\r\n \r\n Bên bên sở hữu sử\r\n dụng một thuật toán băm \r\n Hàm băm ISO/IEC\r\n 10118 - 2 các hàm băm sử dụng một thuật toán mã hóa khối n - bít để tạo ra\r\n một mã băm có độ dài gấp đôi (128 bít); các giá trị đầu vào: \r\n IV = 0F 0F 0F 0F 0F\r\n 0F 0F 0F \r\n IV’ = F0 F0 F0 F0\r\n F0 F0 F0 F0; các quy tắc đệm như phần biến đầu tiên của B.3 trong ISO/IEC\r\n 10118:2000; Phép biến đổi u và u’ như trong phụ lục A của ISO/IEC 10118 -2:2000.\r\n \r\n Sử dụng thuật toán\r\n mã khối DES. \r\n
\r\n CHỨNG CHỈ \r\n	\r\n Chứng chỉ của ông\r\n Smith \r\n
\r\n THAM CHIẾU CHỨNG\r\n CHỈ \r\n	\r\n Chứng chỉ này được\r\n tham chiếu bởi CƠ QUAN CÓ THẨM QUYỀN: 00000001. \r\n
\r\n CHI TIẾT ĐỊNH DANH\r\n AN NINH \r\n Hạn định bên tham gia\r\n an ninh \r\n	\r\n Bên sở hữu chứng chỉ\r\n (ông Smith ở Công ty A) \r\n
\r\n CHI TIẾT ĐỊNH DANH\r\n AN NINH \r\n Hạn định bên tham gia\r\n an ninh \r\n \r\n Tên khóa \r\n	\r\n Xác thực bên tham gia\r\n (chứng chỉ của ông Smith được phát hành bởi một cơ quan chứng nhận gọi là: CƠ\r\n QUAN CÓ THẨM QUYỀN) \r\n Khóa công bố của CƠ\r\n QUAN CÓ THẨM QUYỀN được sử dụng để phát hành chứng chỉ của ông Smith là PK1. \r\n
\r\n CÚ PHÁP VÀ PHIÊN\r\n BẢN CHỨNG CHỈ \r\n	\r\n Phiên bản chứng chỉ\r\n của danh mục đoạn dịch vụ UN/EDIFACT \r\n
\r\n HÀM LỌC \r\n	\r\n Tất cả giá trị nhị\r\n phân (các chữ ký số và khóa) được lọc bằng bộ lọc thập lục phân. \r\n
\r\n MÃ HÓA BỘ KÝ TỰ GỐC \r\n	\r\n Giấy ủy nhiệm về\r\n chứng chỉ được mã hóa thành mã ASCII 8 bít khi chứng chỉ được phát hành \r\n
\r\n KÝ TỰ DỊCH VỤ CHỮ\r\n KÝ \r\n Hạn định ký tự dịch\r\n vụ chữ ký \r\n Ký tự dịch vụ chữ\r\n ký \r\n	\r\n Ký tự dịch vụ được\r\n sử dụng khi chữ ký được tính toán \r\n Ký tự dịch vụ là\r\n dấu kết thúc đoạn \r\n Giá trị “ ’ “ (dấu\r\n nháy) \r\n
\r\n KÝ TỰ DỊCH VỤ CHỮ\r\n KÝ \r\n Hạn định ký tự dịch\r\n vụ chữ ký \r\n Ký tự dịch vụ chữ\r\n ký \r\n	\r\n Ký tự dịch vụ được\r\n sử dụng khi chữ ký được tính toán \r\n Ký tự dịch vụ là\r\n dấu phân tách phần tử dữ liệu \r\n Giá trị “ + “ (dấu\r\n cộng) \r\n
\r\n KÝ TỰ DỊCH VỤ CHỮ\r\n KÝ \r\n Hạn định ký tự dịch\r\n vụ chữ ký \r\n \r\n Ký tự dịch vụ chữ ký \r\n	\r\n Ký tự dịch vụ được\r\n sử dụng khi chữ ký được tính toán \r\n Ký tự dịch vụ là\r\n dấu phân tách phần tử dữ liệu thành phần \r\n Giá trị “ : “ (dấu\r\n hai chấm) \r\n
\r\n KÝ TỰ DỊCH VỤ CHỮ\r\n KÝ \r\n Hạn định ký tự dịch\r\n vụ chữ ký \r\n Ký tự dịch vụ chữ\r\n ký \r\n	\r\n Ký tự dịch vụ được\r\n sử dụng khi chữ ký được tính toán \r\n Ký tự dịch vụ là\r\n dấu phân tách lặp lại \r\n Giá trị “ * “ (dấu\r\n hoa thị) \r\n
\r\n KÝ TỰ DỊCH VỤ CHỮ\r\n KÝ \r\n Hạn định ký tự dịch\r\n vụ chữ ký \r\n Ký tự dịch vụ chữ\r\n ký \r\n	\r\n Ký tự dịch vụ được\r\n sử dụng khi chữ ký được tính toán \r\n Ký tự dịch vụ là ký\r\n tự phát hành \r\n Giá trị “?” (dấu\r\n hỏi) \r\n
\r\n NGÀY THÁNG VÀ THỜI\r\n GIAN AN NINH \r\n Ngày và giờ \r\n	\r\n Thời gian phát hành\r\n chứng chỉ \r\n Chứng chỉ ông Smith\r\n được phát hành vào 931215 lúc 14:12:00 \r\n
\r\n NGÀY THÁNG VÀ THỜI\r\n GIAN AN NINH \r\n Ngày và giờ \r\n	\r\n Bắt đầu thời gian\r\n hợp lệ của chứng chỉ \r\n Thời gian chứng chỉ\r\n của ông Smith hợp lệ bắt đầu: 1996 01 01 000000 \r\n
\r\n NGÀY THÁNG VÀ THỜI\r\n GIAN AN NINH \r\n Ngày và giờ \r\n	\r\n Kết thúc thời gian\r\n hợp lệ của chứng chỉ \r\n Kỳ hạn chứng chỉ\r\n của ông Smith hết hiệu lực: \r\n 1996 12 31 235959 \r\n
\r\n THUẬT TOÁN AN NINH \r\n	\r\n Thuật toán không\r\n đối xứng được ông Smith sử dụng để ký \r\n
\r\n THUẬT TOÁN AN NINH \r\n Sử dụng thuật toán \r\n Phương thức hoạt\r\n động mật mã hóa \r\n Thuật toán \r\n	\r\n \r\n Bên sở hữu sử dụng\r\n một thuật toán để ký \r\n Không có phương\r\n thức hoạt động liên quan ở đây \r\n \r\n RSA là thuật toán không đối xứng \r\n
\r\n THAM SỐ THUẬT TOÁN \r\n Hạn định tham số\r\n thuật toán \r\n \r\n Giá trị tham số thuật toán \r\n	\r\n \r\n Nhận dạng tham số\r\n thuật toán như là một hàm mũ công bố cho việc xác minh chữ ký \r\n Khóa công bố của\r\n ông Smith \r\n
\r\n TIÊU ĐỀ AN NINH \r\n	\r\n \r\n
\r\n THAM SỐ THUẬT TOÁN \r\n Hạn định tham số\r\n thuật toán \r\n \r\n Giá trị tham số thuật toán \r\n	\r\n \r\n Định danh tham số\r\n thuật toán như một môđun cho việc xác minh chữ ký \r\n Các môđun của ông\r\n Smith \r\n
\r\n THAM SỐ THUẬT TOÁN \r\n Hạn định tham số\r\n thuật toán \r\n \r\n Giá trị tham số thuật toán \r\n	\r\n \r\n định danh tham số\r\n thuật toán như độ dài các môđun của ông Smith (bằng bít) \r\n Các mô môđun của\r\n ông Smith dài 512 bít \r\n
\r\n THUẬT TOÁN AN NINH \r\n	\r\n Hàm băm được BÊN CHỨNG\r\n NHẬN sử dụng để phát hành chứng chỉ của ông Smith \r\n
\r\n THUẬT TOÁN AN NINH \r\n Sử dụng thuật toán \r\n Mật mã hóa phương\r\n thức hoạt động \r\n \r\n \r\n \r\n \r\n \r\n Thuật toán \r\n	\r\n \r\n Bên phát hành sử\r\n dụng một thuật toán băm \r\n Hàm băm ISO/IEC\r\n 10118-2 Hàm băm sử dụng một thuật toán mã khối n-bít để tạo ra một mã băm có\r\n độ dài gấp đôi (128 bít); giá trị ban đầu: \r\n IV = 0F 0F 0F 0F 0F\r\n 0F 0F 0F \r\n IV’ = F0 F0 F0 F0\r\n F0 F0 F0 F0; các quy tắc đệm như phần biến đầu tiên của B.3 trong ISO/IEC\r\n 10118-2:2000; việc biến đổi u và u’ như được quy định trong phụ lục A\r\n của ISO/IEC 10118-2:2000. \r\n Thuật toán mã khối\r\n DES được sử dụng \r\n
\r\n THUẬT TOÁN AN NINH \r\n Sự sử dụng thuật\r\n toán \r\n Mật mã hóa phương\r\n thức hoạt động \r\n Thuật toán \r\n	\r\n \r\n Bên phát hành sử\r\n dụng một thuật toán để ký \r\n Không có phương\r\n thức hoạt động liên quan ở đây \r\n \r\n RSA là thuật toán không đối xứng \r\n
\r\n THAM SỐ THUẬT TOÁN \r\n Hạn định tham số\r\n thuật toán \r\n \r\n Giá trị tham số thuật toán \r\n	\r\n \r\n định danh tham số\r\n thuật toán như một hàm mũ công bố cho việc xác minh chữ ký \r\n Khóa chung của BÊN\r\n CHỨNG NHẬN \r\n
\r\n THAM SỐ THUẬT TOÁN \r\n Hạn định tham số\r\n thuật toán \r\n \r\n Giá trị tham số thuật toán \r\n	\r\n \r\n định danh tham số\r\n thuật toán như một môđun cho việc xác minh chữ ký \r\n Các môđun của BÊN\r\n CHỨNG NHẬN \r\n
\r\n THAM SỐ THUẬT TOÁN \r\n Hạn định tham số\r\n thuật toán \r\n \r\n Giá trị tham số thuật toán \r\n	\r\n \r\n định danh tham số\r\n thuật toán như độ dài môđun của BÊN CHỨNG NHẬN (theo bít) \r\n Các mô đul của BÊN\r\n CHỨNG NHẬN dài 512 bít \r\n
\r\n KẾT QUẢ AN NINH \r\n	\r\n Chữ ký số của chứng\r\n chỉ \r\n
\r\n KẾT QUẢ HỢP LỆ \r\n Hạn định giá trị\r\n hợp lệ \r\n Giá trị hợp lệ \r\n	\r\n \r\n Giá trị hợp lệ duy\r\n nhất là 1. \r\n Chữ ký số 512 bít \r\n
\r\n ĐUÔI AN NINH \r\n	\r\n \r\n
\r\n TIÊU ĐỀ AN NINH \r\n	\r\n \r\n
\r\n SỐ HIỆU THAM CHIẾU\r\n AN NINH \r\n	\r\n Số tham chiếu của\r\n đuôi an ninh là 1 \r\n
\r\n SỐ LƯỢNG ĐOẠN AN\r\n NINH \r\n	\r\n 9 \r\n
\r\n KẾT QUẢ AN NINH \r\n	\r\n Chữ ký số của thông\r\n điệp \r\n
\r\n KẾT QUẢ HỢP LỆ \r\n Hạn định giá trị\r\n hợp lệ \r\n Giá trị hợp lệ \r\n	\r\n \r\n Giá trị hợp lệ duy\r\n nhất là 1. \r\n Chữ ký số 512 bít \r\n

\r\n\r\n

C.4. Ví dụ 3: không\r\ntừ chối gốc, kỹ thuật thứ hai

\r\n\r\n

C.4.1. Tình huống

\r\n\r\n

Ngân hàng A muốn sử\r\ndụng dịch vụ an ninh không - từ chối gốc cho đơn đặt hàng thanh toán của ông\r\nSmith ở Công ty A. Công ty A yêu cầu một báo nhận an ninh từ ngân hàng A (không\r\n- từ chối việc nhận của bên tiếp nhận) được truyền trong một thông điệp AUTACK.

\r\n\r\n

Dịch vụ an ninh không\r\n- từ chối gốc được thiết lập giữa các bên trao đổi để hoàn tất các đơn đặt hàng\r\nthanh toán bằng cách sử dụng một chữ ký số.

\r\n\r\n

Cả hai bên đồng ý\r\nrằng chữ ký này được tính toán bằng RSA 512 bít (thuật toán không đối xứng) nhờ một\r\ngiá trị toàn vẹn - 64 bít được tính toán bằng CBC trong chế độ DES (thuật toán\r\nđối xứng). Chứng chỉ để định danh khóa công bố của ông Smith được phát hành bởi\r\nmột bên chứng nhận được cả hai bên tin cậy.

\r\n\r\n

C.4.2. Chi tiết an\r\nninh

\r\n

TIÊU ĐỀ AN NINH

\r\n

DỊCH VỤ AN NINH

\r\n

Không - từ chối gốc

\r\n

SỐ HIỆU THAM CHIẾU\r\n AN NINH

\r\n

Số tham chiếu của\r\n tiêu đề là 1.

\r\n

HÌNH THỨC ĐÁP ỨNG

\r\n

Yêu cầu báo nhận.

\r\n

HÀM LỌC

\r\n

Tất cả giá trị nhị\r\n phân các (chữ ký) được lọc bằng bộ lọc thập lục phân.

\r\n

MÃ HÓA BỘ KÝ TỰ GỐC

\r\n

Thông điệp được mã\r\n hóa thành mã ASCII 8 bít khi chữ ký của nó được phát hành.

\r\n

CHI TIẾT ĐỊNH DANH\r\n AN NINH

\r\n

Hạn định bên tham gia\r\n an ninh

\r\n

Bên gửi thông điệp\r\n (bên tham gia an ninh thông điệp: ông Smith ở công ty A)

\r\n

CHI TIẾT ĐỊNH DANH\r\n AN NINH

\r\n

Hạn định bên tham gia\r\n an ninh

\r\n

Bên tiếp nhận thông\r\n điệp (bên xác minh thông điệp an ninh: Ngân hàng A)

\r\n

SỐ HIỆU THỨ TỰ AN\r\n NINH

\r\n

Số hiệu thứ tự an\r\n ninh của thông điệp là 001

\r\n

NGÀY THÁNG VÀ THỜI\r\n GIAN AN NINH

\r\n

Thẻ thời gian an\r\n ninh có dạng: ngày:196 01 15, thời gian: 10:05:30.

\r\n

THUẬT TOÁN AN NINH

\r\n

Thuật toán đối xứng\r\n được sử dụng để tính một giá trị toàn vẹn

\r\n

THUẬT TOÁN AN NINH

\r\n

Sử dụng thuật toán

\r\n

Phương thức hoạt\r\n động mật mã hóa

\r\n

\r\n
\r\n Thuật toán

\r\n

Sử dụng một thuật\r\n toán băm của bên sở hữu.

\r\n

Chuỗi khối mã;\r\n ISO/IEC 10116 (n - bít). Một giá trị toàn vẹn 64 bít được tính toán; giá trị\r\n ban đầu là số 0 nhị phân; một khóa - bí mật DES được sử dụng. Nó được truyền\r\n và mã hóa dưới khóa công bố của Ngân hàng A.

\r\n

Thuật toán mã khối\r\n DES được sử dụng.

\r\n

THAM SỐ THUẬT TOÁN

\r\n

Hạn định tham số\r\n thuật toán

\r\n

\r\n Giá trị tham số thuật toán

\r\n

Định danh giá trị\r\n tham số thuật toán theo sau như một khóa đối xứng được mã hóa dưới một khóa công\r\n bố.

\r\n

Khóa đối xứng được\r\n mã hóa dưới khóa công bố của Ngân hàng A.

\r\n

THAM SỐ THUẬT TOÁN

\r\n

Hạn định tham số\r\n thuật toán

\r\n

\r\n Giá trị tham số thuật toán

\r\n

Định danh giá trị\r\n tham số thuật toán theo sau như một giá trị văn bản ban đầu.

\r\n

Giá trị văn bản ban\r\n đầu (tất cả là số nhị phận 0).

\r\n

CHỨNG CHỈ

\r\n

Chứng chỉ của ông\r\n Smith (Bên gửi thông điệp)

\r\n

THAM CHIẾU CHỨNG\r\n CHỈ

\r\n

Chứng chỉ này được\r\n tham chiếu: 00000001, bởi BÊN CHỨNG NHẬN

\r\n

CHI TIẾT ĐỊNH DANH\r\n AN NINH

\r\n

Hạn định bên tham gia\r\n an ninh

\r\n

Bên sở hữu chứng chỉ\r\n (ông Smith ở Công ty A)

\r\n

CHI TIẾT ĐỊNH DANH\r\n AN NINH

\r\n

Hạn định bên tham gia\r\n an ninh

\r\n

\r\n
\r\n Tên khóa

\r\n

Xác thực bên tham gia\r\n (chứng chỉ của ông Smith được phát hành bởi một tổ chức chứng nhận gọi là:\r\n bên chứng nhận)

\r\n

Khóa công bố của\r\n bên chứng nhận được sử dụng để phát hành chứng chỉ của ông Smith là PK1.

\r\n

CÚ PHÁP VÀ PHIÊN\r\n BẢN CHỨNG CHỈ

\r\n

Phiên bản chứng chỉ\r\n của thư mục đoạn dịch vụ UN/EDIFACT

\r\n

HÀM LỌC

\r\n

Tất cả giá trị nhị\r\n phân (các chữ ký số và khóa) được lọc bằng bộ lọc thập lục phân

\r\n

MÃ HÓA BỘ KÝ TỰ GỐC

\r\n

Thông tin về chứng chỉ\r\n được mã hóa thành mã ASCII 8 bít khi chứng chỉ được phát hành

\r\n

KÝ TỰ DỊCH VỤ CHỮ\r\n KÝ

\r\n

\r\n Hạn định ký tự dịch vụ chữ ký

\r\n

Ký tự dịch vụ chữ\r\n ký

\r\n

Ký tự dịch vụ được\r\n sử dụng khi chữ ký được điện tử hóa

\r\n

Ký tự dịch vụ là\r\n dấu kết thúc đoạn

\r\n

Giá trị “’” (dấu\r\n nháy)

\r\n

KÝ TỰ DỊCH VỤ CHỮ\r\n KÝ

\r\n

\r\n Hạn định ký tự dịch vụ chữ ký

\r\n

Ký tự dịch vụ chữ\r\n ký

\r\n

Ký tự dịch vụ được\r\n sử dụng khi chữ ký được điện tử hóa

\r\n

Ký tự dịch vụ là\r\n dấu phân tách phần tử dữ liệu

\r\n

Giá trị “+” (dấu\r\n cộng)

\r\n

KÝ TỰ DỊCH VỤ CHỮ\r\n KÝ

\r\n

\r\n Hạn định ký tự dịch vụ chữ ký

\r\n

\r\n Ký tự dịch vụ chữ ký

\r\n

Ký tự dịch vụ được\r\n sử dụng khi chữ ký được điện tử hóa

\r\n

Ký tự dịch vụ là\r\n dấu phân tách phần tử dữ liệu thành phần

\r\n

Giá trị “:” (dấu\r\n hai chấm)

\r\n

KÝ TỰ DỊCH VỤ CHỮ\r\n KÝ

\r\n

\r\n Hạn định ký tự dịch vụ chữ ký

\r\n

Ký tự dịch vụ chữ\r\n ký

\r\n

Ký tự dịch vụ được\r\n sử dụng khi chữ ký được điện tử hóa

\r\n

Ký tự dịch vụ là\r\n dấu phân tách lặp lại

\r\n

Giá trị “*” (dấu\r\n hoa thị)

\r\n

KÝ TỰ DỊCH VỤ CHỮ\r\n KÝ

\r\n

\r\n Hạn định ký tự dịch vụ chữ ký

\r\n

Ký tự dịch vụ chữ\r\n ký

\r\n

Ký tự dịch vụ được\r\n sử dụng khi chữ ký được điện tử hóa

\r\n

Ký tự dịch vụ là ký\r\n tự phát hành

\r\n

Giá trị “?” (dấu\r\n hỏi)

\r\n

NGÀY THÁNG VÀ THỜI\r\n GIAN AN NINH

\r\n

Ngày và giờ

\r\n

Thời gian phát hành\r\n chứng chỉ

\r\n

\r\n Chứng chỉ ông Smith được tạo ra vào 931215 lúc 14:12:00

\r\n

NGÀY THÁNG VÀ THỜI\r\n GIAN AN NINH

\r\n

Ngày và giờ

\r\n

Bắt đầu thời gian\r\n hợp lệ của chứng chỉ

\r\n

\r\n Quá trình có hiệu lực của ông Smith bắt đầu: 1996 01 01 000000

\r\n

NGÀY THÁNG VÀ THỜI\r\n GIAN AN NINH

\r\n

Ngày và giờ

\r\n

Kết thúc thời gian\r\n hợp lệ của chứng chỉ

\r\n

\r\n Kỳ hạn chứng chỉ của ông Smith hết hiệu lực: 1996 12 31 235959

\r\n

THUẬT TOÁN AN NINH

\r\n

Thuật toán không\r\n đối xứng được ông Smith sử dụng để ký

\r\n

THUẬT TOÁN AN NINH

\r\n

Sử dụng thuật toán

\r\n

Phương thức hoạt\r\n động mật mã hóa

\r\n

Thuật toán

\r\n

Bên sở hữu sử dụng\r\n một thuật toán để ký

\r\n

Không có lao động\r\n liên quan ở đây

\r\n

\r\n RSA là thuật toán không đối xứng

\r\n

THAM SỐ THUẬT TOÁN

\r\n

Hạn định tham số\r\n thuật toán

\r\n

\r\n Giá trị tham số thuật toán

\r\n

định danh tham số\r\n thuật toán như một hàm mũ công bố việc xác minh chữ ký

\r\n

Khóa công bố của\r\n ông Smith

\r\n

THAM SỐ THUẬT TOÁN

\r\n

Hạn định tham số\r\n thuật toán

\r\n

\r\n Giá trị tham số thuật toán

\r\n

định danh tham số\r\n thuật toán như một môđun cho việc xác minh chữ ký

\r\n

Môđun của ông Smith

\r\n

THAM SỐ THUẬT TOÁN

\r\n

Hạn định tham số\r\n thuật toán

\r\n

\r\n Giá trị tham số thuật toán

\r\n

định danh tham số\r\n thuật toán như độ dài các môđun của ông Smith (bằng bít)

\r\n

Các mô đun của ông\r\n Smith dài 512 bít

\r\n

THUẬT TOÁN AN NINH

\r\n

Hàm băm được BÊN\r\n CHỨNG NHẬN sử dụng để phát hành chứng chỉ của ông Smith

\r\n

THUẬT TOÁN AN NINH

\r\n

Sử dụng thuật toán

\r\n

Mật mã hóa phương\r\n thức hoạt động

\r\n

Thuật toán

\r\n

Bên phát hành sử\r\n dụng một thuật toán băm

\r\n

Hàm băm n bình phương\r\n đối với RSA; phụ lục D, CCITT X509. ISO/IEC 9594-8.

\r\n

Thuật toán không\r\n đối xứng RSA

\r\n

THUẬT TOÁN AN NINH

\r\n

Thuật toán không\r\n đối xứng được BÊN CHỨNG NHẬN sử dụng để ký

\r\n

THUẬT TOÁN AN NINH

\r\n

Sự sử dụng thuật\r\n toán

\r\n

Mật mã hóa phương\r\n thức hoạt động

\r\n

Thuật toán

\r\n

Bên phát hành sử\r\n dụng một thuật toán để ký

\r\n

Không có phương\r\n thức hoạt động liên quan ở đây

\r\n

\r\n RSA là thuật toán không đối xứng

\r\n

THAM SỐ THUẬT TOÁN

\r\n

Hạn định tham số\r\n thuật toán

\r\n

\r\n Giá trị tham số thuật toán

\r\n

định danh tham số\r\n thuật toán này một cách công khai đối với xác minh chữ ký

\r\n

Khóa chung của BÊN\r\n THI HÀNH

\r\n

THAM SỐ THUẬT TOÁN

\r\n

Hạn định tham số\r\n thuật toán

\r\n

\r\n Giá trị tham số thuật toán

\r\n

định danh tham số\r\n thuật toán như một hàm mũ công bố cho việc xác minh chữ ký

\r\n

Môđun của BÊN CHỨNG\r\n NHẬN

\r\n

THAM SỐ THUẬT TOÁN

\r\n

Hạn định tham số\r\n thuật toán

\r\n

\r\n Giá trị tham số thuật toán

\r\n

Xác định tham số\r\n thuật toán như độ dài các mô đul của BÊN CHỨNG NHẬN (theo bít)

\r\n

Các môđun của BÊN\r\n CHỨNG NHẬN dài 512 bít

\r\n

KẾT QUẢ AN NINH

\r\n

Chữ ký số của chứng\r\n chỉ

\r\n

KẾT QUẢ HỢP LỆ

\r\n

Hạn định giá trị\r\n hợp lệ

\r\n

Giá trị hợp lệ

\r\n

Giá trị hợp lệ duy\r\n nhất là 1.

\r\n

Chữ ký số 512 bít

\r\n

CHỨNG CHỈ

\r\n

Chứng chỉ của Ngân\r\n hàng A (Bên tiếp nhận thông điệp)

\r\n

THAM CHIẾU CHỨNG\r\n CHỈ

\r\n

Khóa công bố của\r\n Ngân hàng A được sử dụng liên quan với chứng chỉ được tham chiếu là 00001001

\r\n

ĐUÔI AN NINH

\r\n

SỐ HIỆU THAM CHIẾU\r\n AN NINH

\r\n

Số tham chiếu của\r\n đuôi an ninh là 1

\r\n

SỐ LƯỢNG ĐOẠN AN\r\n NINH

\r\n

KẾT QUẢ AN NINH

\r\n

Chữ ký số của thông\r\n điệp

\r\n

KẾT QUẢ HỢP LỆ

\r\n

Hạn định giá trị\r\n hợp lệ

\r\n

Giá trị hợp lệ

\r\n

Giá trị hợp lệ duy\r\n nhất là 1.

\r\n

Chữ ký số 512 bít

\r\n

\r\n\r\n

Phụ lục D
\r\n(tham\r\nkhảo)

\r\n\r\n

Các hàm lọc đối với các kho bộ ký tự A\r\nvà C của UN/EDIFACT

\r\n\r\n

D.1. Bộ lọc EDA

\r\n\r\n

D.1.1. Cơ sở

\r\n\r\n

Việc lọc thập lục\r\nphân tăng gấp đôi số ký tự yêu cầu để biểu diễn dữ liệu nhị phân. Đây là sự lãng\r\nphí không gian. Các hàm lọc đã được tiêu chuẩn hóa và đang tồn tại khác hoặc là\r\nkhông thích hợp đối với các kho bộ ký tự A và B của UN/EDIFACT (ISO/IEC 646) bởi\r\nvì chúng ánh xạ tới hầu hết bộ ký tự đầy đủ có thể xuất bản của ISO (94 ký tự\r\nngoài 96 ký tự có thể xuất bản), hoặc là do chúng thực sự không hiệu quả về\r\nkhông gian so với lọc thập lục phân (bộ lọc Baudot).

\r\n\r\n

Do đó nên xác định\r\nmột hàm lọc đủ đơn giản và ánh xạ tới (một tập con của) kho bộ ký tự mức A của UN/EDIFACT,\r\nsẽ hiệu quả hơn bộ lọc thập lục phân.

\r\n\r\n

D.1.2. Kho bộ ký tự\r\nUN/EDIFACT

\r\n\r\n

Kho bộ ký tự A có 44\r\nký tự, việc sử dụng nó là không hạn chế. Trường hợp bổ sung thêm vào 44 ký tự đó,\r\nmột phần của bộ ký tự này gồm bốn ký tự dịch vụ và tám ký tự không cho phép\r\ntruyền TELEX.

\r\n\r\n

Tất cả các ký tự trên\r\ncũng là một phần của kho bộ ký tự B của UN/EDIFACT, các ký tự này không được\r\ndùng trong việc truyền TELEX, và nó gồm 82 ký tự thường và ba ký tự dịch vụ\r\nkhông - thể xuất bản được.

\r\n\r\n

D.1.3. Lọc hai thành\r\nba

\r\n\r\n

Để biểu diễn hai ký\r\ntự nhị phân bằng ba ký tự được lọc, yêu cầu tối thiểu 41 ký tự trong bộ ký tự\r\nnày: 41 ** 3 = 68 921 > 65 536 > 64 000 = 40 ** 3.

\r\n\r\n

D.1.4. Đặc tả bộ lọc\r\nEDA

\r\n\r\n

Có 44 ký tự được cho\r\nphép, tránh sử dụng phần ký tự trống trong 44 ký tự đó và lọc mỗi cặp ký tự đầu\r\nvào (nếu là lẻ, lọc ký tự cuối cùng trong hai lần kết quả) bằng:

\r\n\r\n

- việc tính toán giá\r\ntrị nhị phân của số nguyên không dấu được tạo ra bởi cặp ký tự này (giá trị này\r\nphụ thuộc khách quan vào bản chất LITTLE_ENDIAN /BIG_ENDIAN (Byte đầu tiên có\r\nnghĩa nhất hoặc ít nghĩa nhất) của máy tính sử dụng. Tiêu chuẩn hóa cho\r\nBIG_ENDIAN: byte đầu tiên có nghĩa nhất;

\r\n\r\n

- biểu diễn giá trị\r\nbằng một dãy ba số (hai cho byte lẻ cuối cùng), trong khoảng từ 0 đến 42 theo:

\r\n\r\n

- kết quả của phép\r\nchia cho 1849 (43 bình phương) (bỏ qua byte lẻ cuối cùng);

\r\n\r\n

- giá trị dư của 1849\r\nchia cho 43;

\r\n\r\n

- giá trị dư 43;

\r\n\r\n

- ánh xạ mỗi số trong\r\nbảng chữ cái mức A của UN/EDIFACT bởi bảng tương ứng:

\r\n\r\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n

\r\n 0 tới 9 \r\n	\r\n được biểu diễn bằng\r\n \r\n	\r\n 0 tới 9 \r\n
\r\n A tới Z \r\n	\r\n được biểu diễn bằng\r\n \r\n	\r\n 10 tới 35 \r\n
\r\n (), -. /= \r\n	\r\n được biểu diễn bằng\r\n \r\n	\r\n 36 tới 42 theo thứ\r\n tự. \r\n

\r\n\r\n

D.1.5. Giải lọc

\r\n\r\n

Để giải lọc: ánh\r\nxạ trong mỗi ký tự trong 43 ký tự trở lại giá trị của nó giữa 0 và 42,

\r\n\r\n

nếu\r\ncòn lại ít nhất ba ký tự được lọc, tính toán: cl * 1849 + c2 *43 + c3 = số\r\nnguyên ngắn;

\r\n\r\n

còn\r\nít nhất hai ký tự thì tính: c1 * 43 + c2 = giá trị ký tự.

\r\n\r\n

Lưu ý:

\r\n\r\n

a) số nguyên ngắn nên\r\n< 65 536;

\r\n\r\n

b) giá trị ký tự nên\r\n< 256;

\r\n\r\n

c) trong một máy tính\r\nLITTLE_ENDIAN, chuyển hai ký tự của giá trị số nguyên ngắn.

\r\n\r\n

D.2. Bộ lọc EDC

\r\n\r\n

D.2.1. Cơ sở

\r\n\r\n

Bộ lọc EDA được xây\r\ndựng để cho phép lọc sang kho mức A hoặc B của UN/EDIFACT. Tất nhiên, do kho ký\r\ntự này bị giới hạn theo các ký tự, mức mở rộng = 3/2 là khá tồi, mặc dù đã tốt\r\nhơn nhiều so với bộ lọc thập lục phân = 2/1.

\r\n\r\n

Trong các kho mức\r\nC,D,E và F, có thể đạt được dễ dàng một mức mở rộng tốt hơn nhiều.

\r\n\r\n

Thực tế, trong các\r\nkho ký tự này, chỉ các liên kết không thể cho phép chỉ gồm các giá trị nhị phân\r\ntừ 0/0 tới 1/15 và các giá trị 8/0 tới 9/15.

\r\n\r\n

Trong 256 giá trị nhị\r\nphân có thể thì 192 ký tự được cho phép.

\r\n\r\n

Một bộ lọc mức C, lý\r\ntưởng khi mức mở rộng thấp mà không yêu cầu tính toán dài, sẽ cho phép biểu\r\ndiễn 18 byte nhị phân thành 19 byte được lọc, nhưng không được từ 19 byte sang\r\n20 byte được lọc, bởi vì:

\r\n\r\n

192**19 > 256**18,\r\nvà

\r\n\r\n

192**20 < 256**19

\r\n\r\n

Mức mở rộng thực tế\r\nlà 8/7 do sự hạn chế của phép biến đổi các thao tác bít.

\r\n\r\n

D.2.2. Phép biến đổi\r\nlọc

\r\n\r\n

Để biến đổi một chuỗi\r\nbyte nhị phân sang kho ký tự mức C:

\r\n\r\n

- chia nhỏ chuỗi\r\nthành các chuỗi con bẩy - byte (chuỗi con cuối cùng có nhiều nhất bẩy byte);

\r\n\r\n

- thêm vào trước mỗi\r\nchuỗi con một byte điều khiển với giá trị bắt đầu 64 (bít 1 = 1),

\r\n\r\n

- đặt 1 trong mỗi bít\r\ncủa byte điều khiển, có vị trí 0 hoặc 2 đến 7 phụ thuộc vào phép biến đổi lọc được\r\náp dụng cho byte dữ liệu tương ứng của chuỗi con hoặc không;

\r\n\r\n

- Kiểm tra mỗi byte\r\ndữ liệu trong chuỗi con khi phép biến đổi được áp dụng bởi;

\r\n\r\n

- là (byte dữ\r\nliệu.and.64 = = 0) hoặc không?

\r\n\r\n

- Nếu đúng, thì đặt\r\nbít 1 là 1 trong byte dữ liệu và trong bít vị trí của byte điều khiển;

\r\n\r\n

- nếu không, thì giữ\r\nnguyên không thay đổi byte dữ liệu và byte điều khiển;

\r\n\r\n

- Tất cả giá trị lọc\r\nbắt buộc có bít 1 của mỗi byte = 1;

\r\n\r\n

- Các ký tự dịch vụ\r\nmặc định do đó bị loại khỏi kho ký tự lọc đích.

\r\n\r\n

D.2.3. Phép biến đổi\r\ngiải lọc

\r\n\r\n

Để biến đổi trở lại\r\nchuỗi được lọc thành chuỗi nhị phân:

\r\n\r\n

- phân chia chuỗi\r\nthành các chuỗi con tám - byte (chuỗi con cuối cùng có nhiều nhất tám byte);

\r\n\r\n

- coi mỗi byte bắt\r\nđầu của mỗi chuỗi con như một byte điều khiển, các byte khác là byte dữ liệu;

\r\n\r\n

- kiểm tra các vị trí\r\nbít 0 và 2 đến 7 của byte điều khiển;

\r\n\r\n

- các vị trí byte của\r\nchuỗi con tương ứng với thứ tự 1 tới 7,

\r\n\r\n

- nếu bít = 0, giữ\r\nnguyên byte dữ liệu của vị trí tương ứng;

\r\n\r\n

- nếu bít = 1, đặt\r\nbít 1 của byte dữ liệu tương ứng là 0.

\r\n\r\n

Phụ lục E
\r\n(tham\r\nkhảo)

\r\n\r\n

Thuật toán và dịch vụ an ninh

\r\n\r\n

E.1. Phạm vi và mục đích

\r\n\r\n

Phụ lục này đưa ra\r\nnhững ví dụ về khả năng liên kết các phần tử dữ liệu và các giá trị mã từ các\r\nnhóm đoạn an ninh. Các ví dụ được chọn nhằm minh họa một số kỹ thuật an ninh được\r\nsử dụng rộng rãi dựa trên các Tiêu chuẩn Quốc tế.

\r\n\r\n

Để trình bày tất cả\r\ncác khả năng liên kết là quá nhiều đối với phụ lục này. ở đây sự lựa chọn xem\r\nnhư một sự xác định về thuật toán hoặc các phương thức hoạt động. Bên sử dụng chọn\r\ncác kỹ thuật thích hợp để bảo vệ chống lại mối đe dọa an ninh.

\r\n\r\n

Mục đích của phụ lục\r\nnày là cung cấp cho bên sử dụng kỹ thuật an ninh đã chọn, với một điểm khởi đầu\r\ntoàn diện để tìm ra giải pháp phù hợp cho ứng dụng riêng của bên sử dụng.

\r\n\r\n

Để cho dễ đọc và dễ\r\nhiểu, vấn đề được chia thành hai phần, mỗi phần tập trung vào những nguyên tắc\r\ncơ bản khác nhau đối với việc áp dụng an ninh.

\r\n\r\n

Hai phần đó là:

\r\n\r\n

1. liên kết sử dụng\r\ncác thuật toán đối xứng và các đoạn an ninh thích hợp;

\r\n\r\n

2. liên kết sử dụng\r\ncác thuật toán không đối xứng và các đoạn an ninh thích hợp.

\r\n\r\n

Danh sách mã sử dụng\r\ntrong ma trận (một phần của danh sách mã đầy đủ)

\r\n *0501* \r\n	\r\n *Dịch vụ an ninh, đã\r\n mã hóa* \r\n	\r\n *0505* \r\n	\r\n *Chức năng lọc, đã mã\r\n hóa* \r\n
\r\n 1 \r\n	\r\n Không từ chối gốc \r\n	\r\n 6 \r\n	\r\n Bộ lọc EDC \r\n
\r\n 2 \r\n	\r\n Xác thực nguồn gốc\r\n thông điệp \r\n	\r\n \r\n	\r\n \r\n
\r\n 3 \r\n	\r\n Tính toàn vẹn \r\n	\r\n \r\n	\r\n \r\n
\r\n *0523* \r\n	\r\n *Thuật toán sử dụng,\r\n đã mã hóa* \r\n	\r\n *0525* \r\n	\r\n *Mật mã hóa phương\r\n thức hoạt động, đã mã hóa* \r\n
\r\n 1 \r\n	\r\n Hàm băm bên sở hữu \r\n	\r\n 16 \r\n	\r\n DSMR (Chữ ký Số với\r\n khôi phục lại Thông điệp) \r\n
\r\n 2 \r\n	\r\n Hàm đối xứng Bên sở\r\n hữu \r\n	\r\n \r\n	\r\n \r\n
\r\n 3 \r\n	\r\n Ký hiệu Bên phát\r\n hành(CA) \r\n	\r\n \r\n	\r\n \r\n
\r\n 4 \r\n	\r\n Hàm băm Bên phát\r\n hành (CA) \r\n	\r\n \r\n	\r\n \r\n
\r\n 6 \r\n	\r\n Ký hiệu bên sở hữu \r\n	\r\n \r\n	\r\n \r\n
\r\n *0527* \r\n	\r\n *Thuật toán, đã mã\r\n hóa* \r\n	\r\n *0531* \r\n	\r\n *Hạn định tham số\r\n thuật toán* \r\n
\r\n 1 \r\n	\r\n DES (Tiêu chuẩn mật\r\n mã hóa Dữ liệu) \r\n	\r\n 5 \r\n	\r\n Mã hóa khóa đối\r\n xứng \r\n
\r\n 8 \r\n	\r\n SHA (Thuật toán Băm\r\n An ninh) \r\n	\r\n 9 \r\n	\r\n Tên khóa đối xứng \r\n
\r\n 10 \r\n	\r\n RSA (Rivest,\r\n Shamir, Adleman) \r\n	\r\n 10 \r\n	\r\n Tên khóa mã hóa khóa \r\n
\r\n 11 \r\n	\r\n DSA (Thuật toán ký\r\n Số) \r\n	\r\n 12 \r\n	\r\n Môđun \r\n
\r\n 16 \r\n	\r\n SHA1 (Thuật toán\r\n Băm An ninh) \r\n	\r\n 13 \r\n	\r\n Hàm mũ \r\n
\r\n 37 \r\n	\r\n MAC (Mã Xác thực\r\n Thông điệp) \r\n	\r\n 14 \r\n	\r\n Độ dài môđun \r\n
\r\n 38 \r\n	\r\n DIM1 (Cơ chế Toàn\r\n vẹn Dữ liệu) \r\n	\r\n 25 \r\n	\r\n Tham số P của DSA \r\n
\r\n 40 \r\n	\r\n MDC2 (Mã phát hiện\r\n Sự thay đổi) \r\n	\r\n 26 \r\n	\r\n Tham số của Q của\r\n DSA \r\n
\r\n 42 \r\n	\r\n HDS (Hàm băm) \r\n	\r\n 27 \r\n	\r\n Tham số G của DSA \r\n
\r\n \r\n	\r\n \r\n	\r\n 28 \r\n	\r\n Tham số Y của DSA \r\n
\r\n *0563* \r\n	\r\n *Hạn định giá trị\r\n hợp lệ* \r\n	\r\n *0577* \r\n	\r\n *Hạn định bên tham\r\n gia an ninh* \r\n
\r\n 1 \r\n	\r\n Giá trị hợp lệ duy\r\n nhất \r\n	\r\n 1 \r\n	\r\n Bên gửi thông điệp \r\n
\r\n 2 \r\n	\r\n Tham số r của thuật\r\n toán DSA \r\n	\r\n 2 \r\n	\r\n Bên tiếp nhận thông\r\n điệp \r\n
\r\n 3 \r\n	\r\n Tham số s của thuật\r\n toán DSA \r\n	\r\n 3 \r\n	\r\n Chủ sở hữu chứng\r\n chỉ \r\n
\r\n \r\n	\r\n \r\n	\r\n 4 \r\n	\r\n Bên xác thực \r\n

\r\n\r\n

Các chữ viết tắt được\r\nsử dụng

\r\n a, b, c, e \r\n CA \r\n	\r\n = \r\n = \r\n	\r\n Biểu diễn của một\r\n số hiệu tham chiếu an ninh \r\n Tổ chức chứng nhận \r\n
\r\n Enc-key \r\n	\r\n = \r\n	\r\n Khóa mã hóa \r\n
\r\n G \r\n	\r\n = \r\n	\r\n Tham số khóa công\r\n bố G của DSA \r\n
\r\n Hash \r\n KEK-N \r\n	\r\n = \r\n = \r\n	\r\n Giá trị băm \r\n Tên khóa mã hóa khóa \r\n
\r\n Key-N \r\n	\r\n = \r\n	\r\n Tên khóa \r\n
\r\n KN \r\n MAC \r\n	\r\n = \r\n = \r\n	\r\n Tên khóa \r\n Mã xác thực thông điệp \r\n
\r\n Mod \r\n	\r\n = \r\n	\r\n Môđun \r\n
\r\n Mod-L \r\n P \r\n	\r\n = \r\n = \r\n	\r\n Độ dài môđun \r\n Tham số khóa công\r\n bố P của DSA \r\n
\r\n PK/CA \r\n Pub-K \r\n	\r\n = \r\n = \r\n	\r\n Khóa công bố của\r\n bên chứng nhận \r\n Khóa công bố \r\n
\r\n Q \r\n	\r\n = \r\n	\r\n Tham số khóa công\r\n bố Q của DSA \r\n
\r\n R \r\n S \r\n	\r\n = \r\n = \r\n	\r\n Kết quả tham số r\r\n của chữ ký DAS \r\n Kết quả tham số s\r\n của chữ ký DAS \r\n
\r\n Sig \r\n	\r\n = \r\n	\r\n Chữ ký \r\n
\r\n Y \r\n	\r\n = \r\n	\r\n Tham số khóa công\r\n bố Y của DSA \r\n

\r\n\r\n

E.2. Liên kết sử dụng\r\ncác thuật toán đối xứng và các đoạn an ninh tích hợp

\r\n\r\n

Ma trận trong Bảng\r\nE.1 thiết lập các mối quan hệ trong các trường hợp sau:

\r\n\r\n

- an ninh mức trao đổi\r\n/gói/nhóm/trao đổi (TCVN ISO 9735 - 5):2004;

\r\n\r\n

- sử dụng thuật toán\r\nđối xứng duy nhất;

\r\n\r\n

- các dịch vụ an ninh\r\nđã cung cấp là xác thực nguồn gốc thông điệp và toàn vẹn nội dung.

\r\n\r\n

- Xác thực nguồn gốc\r\nthông điệp được cung cấp bằng cách gắn thêm một MAC (Mã Xác thực Thông điệp) vào\r\nthông điệp. Hai ví dụ được đưa ra, cùng với một ví dụ về DES ở chế độ CBC với\r\nmột khóa bí mật mà Bên tiếp nhận thông điệp biết và chỉ được chỉ định bằng một\r\ntên khóa. Ví dụ thứ nhất theo ISO 8731-1. Ví dụ thứ hai dựa trên việc sử dụng\r\nthuật toán DES phù hợp với phương thức hoạt động được trình bày trong ISO/IEC\r\n9797. Khóa bí mật cần được mã hóa DES để truyền đi dưới một khóa mã hóa - khóa dùng\r\nchung cho cả Bên gửi và Bên tiếp nhận. Khóa mã hóa khóa này được chỉ định bằng\r\ntên của nó.

\r\n\r\n

- Toàn vẹn nội dung được\r\ncung cấp bằng một hàm băm dựa trên thuật toán DES trong chế độ MDC, phù hợp với\r\nISO 10118-2. Trong ví dụ thứ ba này, không có khóa bí mật dùng chung cho cả B\r\nvà Bên tiếp nhận. Giá trị băm được truyền đi không bảo vệ, do vậy dịch vụ an\r\nninh này có thể không có khả năng đảm bảo an toàn cho thông điệp.

\r\n\r\n

- Mặc dù Bên gửi và Bên\r\ntiếp nhận dùng chung các khóa, các cơ chế mã hóa không được thỏa thuận hoàn\r\ntoàn trước. Do đó tất cả các thuật toán và phương thức hoạt động sử dụng được\r\nđặt tên rõ ràng.

\r\n\r\n

- Chỉ trình bày các trường\r\nan ninh liên quan tới kỹ thuật an ninh, thuật toán và các phương thức hoạt động\r\nđược sử dụng trên thực tế.

\r\n\r\n

Bảng\r\nE.1 - Ma trận tương quan khi chỉ sử dụng thuật toán đối xứng

\r\n Thẻ \r\n		\r\n Tên \r\n	\r\n S \r\n	\r\n R \r\n	\r\n Xác\r\n thực nguồn gốc thông điệp ISO 8731-1 \r\n	\r\n Xác\r\n thực nguồn gốc thông điệp ISO 9797 \r\n	\r\n Toàn\r\n vẹn nội dung ISO/IEC 10118-2 \r\n		\r\n Chú\r\n thích \r\n
\r\n SG1 \r\n		\r\n \r\n	\r\n C \r\n	\r\n 99 \r\n	\r\n Một\r\n cho mỗi dịch vụ an ninh \r\n				\r\n 1 \r\n
\r\n USH \r\n		\r\n TIÊU ĐỀ AN NINH \r\n	\r\n M \r\n	\r\n 1 \r\n	\r\n \r\n				\r\n \r\n
\r\n 0501 \r\n		\r\n DỊCH VỤ AN NINH, ĐÃ\r\n MÃ HÓA \r\n	\r\n M \r\n	\r\n 1 \r\n	\r\n 2 \r\n	\r\n 2 \r\n	\r\n 3 \r\n		\r\n \r\n
\r\n 0534 \r\n		\r\n SỐ HIỆU THAM CHIẾU\r\n AN NINH \r\n	\r\n M \r\n	\r\n 1 \r\n	\r\n a \r\n	\r\n b \r\n	\r\n c \r\n		\r\n \r\n
\r\n 0505 \r\n		\r\n HÀM LỌC, ĐÃ MÃ HÓA \r\n	\r\n C \r\n	\r\n 1 \r\n	\r\n 6 \r\n	\r\n 6 \r\n	\r\n 6 \r\n		\r\n \r\n
\r\n S500 \r\n		\r\n CHI TIẾT ĐỊNH DANH\r\n AN NINH \r\n	\r\n C \r\n	\r\n 2 \r\n	\r\n \r\n				\r\n \r\n
\r\n 0577 \r\n		\r\n Hạn định bên tham\r\n gia an ninh \r\n	\r\n M \r\n	\r\n \r\n	\r\n 1 \r\n	\r\n 1 \r\n	\r\n 1 \r\n		\r\n 2 \r\n
	\r\n 0538 \r\n	\r\n Tên khóa \r\n	\r\n C \r\n	\r\n \r\n	\r\n Key\r\n - N \r\n	\r\n — \r\n	\r\n — \r\n		\r\n 3 \r\n
	\r\n S500 \r\n	\r\n CHI TIẾT ĐỊNH DANH\r\n AN NINH \r\n	\r\n C \r\n	\r\n 2 \r\n	\r\n \r\n				\r\n \r\n
	\r\n 0577 \r\n	\r\n Hạn định bên tham\r\n gia an ninh \r\n	\r\n M \r\n	\r\n \r\n	\r\n 2 \r\n	\r\n 2 \r\n	\r\n 2 \r\n		\r\n 4 \r\n
	\r\n USA \r\n	\r\n THUẬT TOÁN AN NINH \r\n	\r\n C \r\n	\r\n 3 \r\n	\r\n \r\n				\r\n \r\n
	\r\n S502 \r\n	\r\n THUẬT TOÁN AN NINH \r\n	\r\n M \r\n	\r\n 1 \r\n	\r\n \r\n				\r\n \r\n
	\r\n 0523 \r\n	\r\n Sử dụng thuật toán,\r\n đã mã hóa \r\n	\r\n M \r\n	\r\n \r\n	\r\n 2 \r\n	\r\n 2 \r\n	\r\n 2 \r\n	\r\n \r\n
	\r\n 0525 \r\n	\r\n Mật mã hóa phương\r\n thức hoạt động, đã mã hóa \r\n	\r\n C \r\n	\r\n \r\n	\r\n — \r\n	\r\n — \r\n	\r\n — \r\n	\r\n \r\n
	\r\n 0527 \r\n	\r\n Thuật toán, đã mã\r\n hóa \r\n	\r\n C \r\n	\r\n \r\n	\r\n 37 \r\n	\r\n 38 \r\n	\r\n 40 \r\n	\r\n \r\n
	\r\n S503 \r\n	\r\n THAM SỐ THUẬT TOÁN \r\n	\r\n C \r\n	\r\n 9 \r\n	\r\n \r\n	\r\n Một\r\n cho tên khóa mã hóa khóa \r\n	\r\n \r\n	\r\n \r\n
	\r\n 0531 \r\n	\r\n Hạn định tham số\r\n thuật toán \r\n	\r\n M \r\n	\r\n \r\n	\r\n — \r\n	\r\n 10 \r\n	\r\n — \r\n	\r\n 5 \r\n
	\r\n 0554 \r\n	\r\n Giá trị tham số\r\n thuật toán \r\n	\r\n M \r\n	\r\n \r\n	\r\n — \r\n	\r\n KEK\r\n - N \r\n	\r\n — \r\n	\r\n \r\n
	\r\n S503 \r\n	\r\n THAM SỐ THUẬT TOÁN \r\n	\r\n C \r\n	\r\n 9 \r\n	\r\n \r\n	\r\n Một\r\n cho khóa mã hóa \r\n	\r\n \r\n	\r\n \r\n
	\r\n 0531 \r\n	\r\n Hạn định tham số\r\n thuật toán \r\n	\r\n M \r\n	\r\n \r\n	\r\n — \r\n	\r\n 5 \r\n	\r\n — \r\n	\r\n 6 \r\n
	\r\n 0554 \r\n	\r\n Giá trị tham số\r\n thuật toán \r\n	\r\n M \r\n	\r\n \r\n	\r\n — \r\n	\r\n Enc\r\n - Key \r\n	\r\n — \r\n	\r\n \r\n
	\r\n Cấu trúc dữ liệu được\r\n bảo vệ (các đoạn/đối tượng (các)trao đổi/(các)gói/(các) nhóm của bên sử dụng) \r\n
	\r\n SGn \r\n	\r\n \r\n	\r\n C \r\n	\r\n 99 \r\n	\r\n Một\r\n cho mỗi dịch vụ an ninh \r\n			\r\n 1 \r\n
	\r\n UST \r\n	\r\n ĐUÔI AN NINH \r\n	\r\n M \r\n	\r\n 1 \r\n	\r\n \r\n	\r\n \r\n	\r\n \r\n	\r\n \r\n
	\r\n 0534 \r\n	\r\n SỐ HIỆU THAM CHIẾU\r\n AN NINH \r\n	\r\n M \r\n	\r\n 1 \r\n	\r\n A \r\n	\r\n b \r\n	\r\n c \r\n	\r\n \r\n
	\r\n 0588 \r\n	\r\n SỐ LƯỢNG ĐOẠN AN\r\n NINH \r\n	\r\n M \r\n	\r\n 1 \r\n	\r\n \r\n	\r\n \r\n	\r\n \r\n	\r\n \r\n
	\r\n USR \r\n	\r\n KẾT QUẢ AN NINH \r\n	\r\n C \r\n	\r\n 1 \r\n	\r\n \r\n			\r\n \r\n
	\r\n S508 \r\n	\r\n KẾT QUẢ HỢP LỆ \r\n	\r\n M \r\n	\r\n 2 \r\n	\r\n \r\n			\r\n 7 \r\n
	\r\n 0563 \r\n	\r\n Hạn định giá trị\r\n hợp lệ \r\n	\r\n M \r\n	\r\n \r\n	\r\n 1 \r\n	\r\n 1 \r\n	\r\n 1 \r\n	\r\n \r\n
	\r\n 0560 \r\n	\r\n Giá trị hợp lệ \r\n	\r\n C \r\n	\r\n \r\n	\r\n MAC \r\n	\r\n MAC \r\n	\r\n Hash \r\n	\r\n 8 \r\n
\r\n CHÚ THÍCH \r\n 1. Cả hai cấu trúc\r\n phải có số lần xuất hiện như nhau; \r\n 2. Bên gửi thông\r\n điệp; \r\n 3. Tên khóa bí mật\r\n dùng chung cho bên gửi và bên tiếp nhận; \r\n 4. Bên tiếp nhận\r\n thông điệp; \r\n 5. Khóa mã hóa khóa\r\n dùng chung cho bên gửi và bên tiếp nhận ở đây chỉ đề cập đến tên khóa mã hóa khóa; \r\n 6. Khóa bí mật được\r\n mã hóa theo với khóa mã hóa khóa; \r\n 7. Một số thuật\r\n toán ký (như DSA) yêu cầu hai kết quả tham số; \r\n 8. Các giá trị kết\r\n quả đối với “toàn vẹn” không được bảo vệ và có thể phải tách\r\n biệt nhau. \r\n

\r\n\r\n

E.3. Liên kết sử dụng\r\nkhóa không đối xứng và các đoạn an ninh thích hợp

\r\n\r\n

Ma trận trong Bảng\r\nE.2 thiết lập các mối quan hệ trong các trường hợp sau:

\r\n\r\n

- an ninh mức thông điệp/gói\r\ntrao đổi tích hợp (TCVN ISO 9735- 5:2004);

\r\n\r\n

- dịch vụ an ninh được\r\ncung cấp là không- từ chối gốc, có hai phương pháp với kỹ thuật tính toán chữ ký\r\nkhác nhau;

\r\n\r\n

- có hai thuật toán\r\nkhông đối xứng: RSA và DSA;

\r\n\r\n

- hai hàm - băm được\r\nchọn: DES trong chế độ MDC cùng với RSA, và SHA-1 cùng với DSA;

\r\n\r\n

- chứng chỉ được thừa\r\nnhận không trao đổi trước;

\r\n\r\n

- đoạn USC định danh chính\r\nxác hàm băm và hàm ký được tổ chức chứng nhận sử dụng để ký chứng chỉ. Bên tiếp\r\nnhận đã biết khóa công bố cần cho việc kiểm tra chữ ký chứng nhận của tổ chức chứng\r\nnhân. Khóa công bố này được chỉ định bằng tên trong đoạn USC;

\r\n\r\n

- chỉ bao gồm một\r\nchứng chỉ, cần cái thứ hai, nếu chỉ sử dụng một khóa công bố của bên tiếp nhận.

\r\n\r\n

Bảng\r\nE.2 - Ma trận tương quan khi sử dụng thuật toán không đối xứng

\r\n\r\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n

\r\n Thẻ \r\n	\r\n Tên \r\n	\r\n S \r\n	\r\n R \r\n	\r\n Không\r\n từ chối gốc (RSA) \r\n		\r\n Không\r\n từ chối gốc (DSA) \r\n	\r\n Chú\r\n thích \r\n
\r\n SG1 \r\n	\r\n \r\n	\r\n C \r\n	\r\n 99 \r\n	\r\n Một\r\n cho mỗi dịch vụ an ninh \r\n			\r\n 1 \r\n
\r\n USH \r\n	\r\n TIÊU ĐỀ AN NINH \r\n	\r\n M \r\n	\r\n 1 \r\n	\r\n \r\n			\r\n \r\n
\r\n 0501 \r\n	\r\n DỊCH VỤ AN NINH, ĐÃ\r\n MÃ HÓA \r\n	\r\n M \r\n	\r\n 1 \r\n	\r\n 1 \r\n		\r\n 1 \r\n	\r\n 2 \r\n
\r\n 0534 \r\n	\r\n SỐ HIỆU THAM CHIẾU\r\n AN NINH \r\n	\r\n M \r\n	\r\n 1 \r\n	\r\n d \r\n		\r\n e \r\n	\r\n \r\n
\r\n 0505 \r\n	\r\n HÀM LỌC, ĐÃ MÃ HÓA \r\n	\r\n C \r\n	\r\n 1 \r\n	\r\n 6 \r\n		\r\n 6 \r\n	\r\n \r\n
\r\n S500 \r\n	\r\n CHI TIẾT ĐỊNH DANH\r\n AN NINH \r\n	\r\n C \r\n	\r\n 2 \r\n	\r\n \r\n		\r\n \r\n	\r\n \r\n
\r\n 0577 \r\n	\r\n Hạn định bên tham gia\r\n an ninh \r\n	\r\n M \r\n	\r\n \r\n	\r\n 1 \r\n		\r\n 1 \r\n	\r\n 3 \r\n
\r\n S500 \r\n	\r\n CHI TIẾT ĐỊNH DANH\r\n AN NINH \r\n	\r\n C \r\n	\r\n 2 \r\n	\r\n \r\n		\r\n \r\n	\r\n \r\n
\r\n 0r577 \r\n	\r\n Hạn định bên tham gia\r\n an ninh \r\n	\r\n M \r\n	\r\n \r\n	\r\n 2 \r\n		\r\n 2 \r\n	\r\n 4 \r\n
\r\n USA \r\n	\r\n THUẬT TOÁN AN NINH \r\n	\r\n C \r\n	\r\n 3 \r\n	\r\n \r\n		\r\n \r\n	\r\n \r\n
\r\n S502 \r\n	\r\n THUẬT TOÁN AN NINH \r\n	\r\n M \r\n	\r\n 1 \r\n	\r\n \r\n		\r\n \r\n	\r\n \r\n
\r\n 0523 \r\n	\r\n Sử dụng thuật toán,\r\n mã hóa \r\n	\r\n M \r\n	\r\n \r\n	\r\n 1 \r\n		\r\n 1 \r\n	\r\n 5 \r\n
\r\n 0525 \r\n	\r\n Mật mã hóa phương thức\r\n hoạt động, đã mã hóa \r\n	\r\n C \r\n	\r\n \r\n	\r\n — \r\n		\r\n — \r\n	\r\n \r\n
\r\n 0527 \r\n	\r\n Thuật toán, đã mã\r\n hóa \r\n	\r\n C \r\n	\r\n \r\n	\r\n 42 \r\n		\r\n 16 \r\n	\r\n \r\n
\r\n SG2 \r\n	\r\n \r\n	\r\n C \r\n	\r\n 2 \r\n	\r\n Chỉ\r\n một: chứng chỉ Bên gửi \r\n			\r\n \r\n
\r\n USC \r\n	\r\n \r\n	\r\n M \r\n	\r\n 1 \r\n	\r\n \r\n			\r\n \r\n
\r\n 0536 \r\n	\r\n THAM CHIẾU CHỨNG CHỈ \r\n	\r\n C \r\n	\r\n 1 \r\n	\r\n Tham\r\n chiếu của chứng chỉ này \r\n			\r\n \r\n
\r\n S500 \r\n	\r\n CÁC CHI TIẾT ĐỊNH\r\n DANH AN NINH \r\n	\r\n C \r\n	\r\n 2 \r\n	\r\n (Bên\r\n sở hữu chứng chỉ) \r\n			\r\n \r\n
\r\n 0577 \r\n	\r\n Hạn định bên tham gia\r\n an ninh \r\n	\r\n M \r\n	\r\n \r\n	\r\n 3 \r\n		\r\n 3 \r\n	\r\n 6 \r\n
\r\n S500 \r\n	\r\n CHI TIẾT XÁC MINH\r\n AN NINH \r\n	\r\n C \r\n	\r\n 2 \r\n	\r\n (bên\r\n xác thực) \r\n			\r\n \r\n
\r\n 0577 \r\n	\r\n Hạn định bên tham gia\r\n an ninh \r\n	\r\n M \r\n	\r\n \r\n	\r\n 4 \r\n		\r\n 4 \r\n	\r\n 7 \r\n
\r\n 0538 \r\n	\r\n Tên khóa \r\n	\r\n C \r\n	\r\n \r\n	\r\n Tên\r\n (PK/CA) \r\n		\r\n Tên\r\n (PK/CA) \r\n	\r\n \r\n
\r\n USA \r\n	\r\n THUẬT TOÁN AN NINH \r\n	\r\n C \r\n	\r\n 3 \r\n	\r\n Chức\r\n năng chữ ký của Bên gửi \r\n			\r\n \r\n
\r\n S502 \r\n	\r\n THUẬT TOÁN AN NINH \r\n	\r\n M \r\n	\r\n 1 \r\n	\r\n \r\n			\r\n \r\n
\r\n 0523 \r\n	\r\n Sử dụng thuật toán,\r\n đã mã hóa \r\n	\r\n M \r\n	\r\n \r\n	\r\n 6 \r\n		\r\n 6 \r\n	\r\n 8 \r\n
\r\n 0525 \r\n	\r\n Sử dụng thuật toán,\r\n đã mã hóa \r\n	\r\n C \r\n	\r\n \r\n	\r\n 16 \r\n		\r\n — \r\n	\r\n \r\n
\r\n 0527 \r\n	\r\n THUẬT TOÁN, MÃ HÓA \r\n	\r\n C \r\n	\r\n \r\n	\r\n 10 \r\n		\r\n 11 \r\n	\r\n \r\n
\r\n S503 \r\n	\r\n THAM SỐ THUẬT TOÁN \r\n	\r\n C \r\n	\r\n 9 \r\n	\r\n (độ\r\n dài mô đun) \r\n		\r\n Tham\r\n số P của SA \r\n	\r\n \r\n
\r\n 0531 \r\n	\r\n Hạn định tham số\r\n thuật toán \r\n	\r\n M \r\n	\r\n \r\n	\r\n 14 \r\n		\r\n 25 \r\n	\r\n \r\n
\r\n 0554 \r\n	\r\n Giá trị tham số\r\n thuật toán \r\n	\r\n M \r\n	\r\n \r\n	\r\n Mod\r\n - L \r\n		\r\n P \r\n	\r\n \r\n
\r\n S503 \r\n	\r\n THAM SỐ THUẬT TOÁN \r\n	\r\n C \r\n	\r\n 9 \r\n	\r\n (mô\r\n đun) \r\n		\r\n Tham\r\n số Q của SA \r\n	\r\n \r\n
\r\n 0531 \r\n	\r\n Hạn định tham số\r\n thuật toán \r\n	\r\n M \r\n	\r\n \r\n	\r\n 12 \r\n		\r\n 26 \r\n	\r\n \r\n
\r\n 0554 \r\n	\r\n Giá trị tham số\r\n thuật toán \r\n	\r\n M \r\n	\r\n \r\n	\r\n Mod \r\n		\r\n Q \r\n	\r\n \r\n
\r\n S503 \r\n	\r\n THAM SỐ THUẬT TOÁN \r\n	\r\n C \r\n	\r\n 9 \r\n	\r\n (Hàm\r\n mũ công bố) \r\n		\r\n Tham\r\n số G của SA \r\n	\r\n \r\n
\r\n 0531 \r\n	\r\n Hạn định tham số\r\n thuật toán \r\n	\r\n M \r\n	\r\n \r\n	\r\n 13 \r\n		\r\n 27 \r\n	\r\n \r\n
\r\n 0554 \r\n	\r\n Giá trị tham số\r\n thuật toán \r\n	\r\n M \r\n	\r\n \r\n	\r\n Pub\r\n - K \r\n		\r\n G \r\n	\r\n \r\n
\r\n S503 \r\n	\r\n THAM SỐ THUẬT TOÁN \r\n	\r\n C \r\n	\r\n 9 \r\n	\r\n — \r\n		\r\n Tham\r\n số Y của SA \r\n	\r\n \r\n
\r\n 0531 \r\n	\r\n Hạn định tham số\r\n thuật toán \r\n	\r\n M \r\n	\r\n \r\n	\r\n — \r\n		\r\n 28 \r\n	\r\n \r\n
\r\n 0554 \r\n	\r\n Giá trị tham số\r\n thuật toán \r\n	\r\n M \r\n	\r\n \r\n	\r\n — \r\n		\r\n Y \r\n	\r\n \r\n
\r\n USA \r\n	\r\n THUẬT TOÁN AN NINH \r\n	\r\n C \r\n	\r\n 3 \r\n	\r\n (hàm\r\n băm của CA cho chữ ký của chứng chỉ) \r\n			\r\n \r\n
\r\n S502 \r\n	\r\n THUẬT TOÁN AN NINH \r\n	\r\n M \r\n	\r\n 1 \r\n	\r\n \r\n		\r\n \r\n	\r\n \r\n
\r\n 0523 \r\n	\r\n Sử dụng thuật toán,\r\n đã mã hóa \r\n	\r\n M \r\n	\r\n \r\n	\r\n 4 \r\n		\r\n 4 \r\n	\r\n 9 \r\n
\r\n 0525 \r\n	\r\n Sử dụng thuật toán,\r\n đã mã hóa \r\n	\r\n C \r\n	\r\n \r\n	\r\n 11 \r\n		\r\n — \r\n	\r\n \r\n
\r\n 0527 \r\n	\r\n Thuật toán, đã mã\r\n hóa \r\n	\r\n C \r\n	\r\n \r\n	\r\n 1 \r\n		\r\n 8 \r\n	\r\n \r\n
\r\n USA \r\n	\r\n THUẬT TOÁN AN NINH \r\n	\r\n C \r\n	\r\n 3 \r\n	\r\n (Chức\r\n năng ký của CA cho chữ ký của chứng chỉ) \r\n			\r\n \r\n
\r\n S502 \r\n	\r\n THUẬT TOÁN AN NINH \r\n	\r\n M \r\n	\r\n 1 \r\n	\r\n \r\n		\r\n \r\n	\r\n \r\n
\r\n 0523 \r\n	\r\n Sử dụng thuật toán,\r\n mã hóa \r\n	\r\n M \r\n	\r\n \r\n	\r\n 3 \r\n		\r\n 3 \r\n	\r\n 10 \r\n
\r\n 0525 \r\n	\r\n Sử dụng thuật toán,\r\n mã hóa \r\n	\r\n C \r\n	\r\n \r\n	\r\n 16 \r\n		\r\n — \r\n	\r\n \r\n
\r\n 0527 \r\n	\r\n Thuật toán, đã mã\r\n hóa \r\n	\r\n C \r\n	\r\n \r\n	\r\n 10 \r\n		\r\n 11 \r\n	\r\n \r\n
\r\n USR \r\n	\r\n KẾT QUẢ AN NINH \r\n	\r\n C \r\n	\r\n 1 \r\n	\r\n \r\n			\r\n \r\n
\r\n S508 \r\n	\r\n KẾT QUẢ HỢP LỆ \r\n	\r\n M \r\n	\r\n 2 \r\n	\r\n \r\n			\r\n 11 \r\n
\r\n 0563 \r\n	\r\n Hạn định giá trị\r\n hợp lệ \r\n	\r\n M \r\n	\r\n \r\n	\r\n 1 \r\n		\r\n 2 \r\n	\r\n \r\n
\r\n 0560 \r\n	\r\n Giá trị hợp lệ \r\n	\r\n C \r\n	\r\n \r\n	\r\n Sig \r\n		\r\n R \r\n	\r\n \r\n
\r\n S508 \r\n	\r\n KẾT QUẢ HỢP LỆ \r\n	\r\n M \r\n	\r\n 2 \r\n	\r\n \r\n			\r\n 11 \r\n
\r\n 0563 \r\n	\r\n Hạn định giá trị\r\n hợp lệ \r\n	\r\n M \r\n	\r\n \r\n	\r\n — \r\n		\r\n 3 \r\n	\r\n \r\n
\r\n 0560 \r\n	\r\n Giá trị hợp lệ \r\n	\r\n C \r\n	\r\n \r\n	\r\n — \r\n		\r\n S \r\n	\r\n \r\n
\r\n Cấu trúc dữ liệu được\r\n bảo vệ (các đoạn/đối tượng/(các)trao đổi/(các)gói (các) nhóm của bên sử dụng) \r\n
\r\n SGn \r\n	\r\n \r\n	\r\n C \r\n	\r\n 99 \r\n		\r\n Một\r\n cho mỗi dịch vụ an ninh \r\n		\r\n 1 \r\n
\r\n UST \r\n	\r\n ĐUÔI AN NINH \r\n	\r\n M \r\n	\r\n 1 \r\n		\r\n \r\n		\r\n \r\n
\r\n 0534 \r\n	\r\n SỐ HIỆU THAM CHIẾU\r\n AN NINH \r\n	\r\n M \r\n	\r\n 1 \r\n		\r\n d \r\n	\r\n e \r\n	\r\n \r\n
\r\n 0588 \r\n	\r\n SỐ LƯỢNG ĐOẠN AN\r\n NINH \r\n	\r\n M \r\n	\r\n 1 \r\n		\r\n \r\n	\r\n \r\n	\r\n \r\n
\r\n USR \r\n	\r\n KẾT QUẢ AN NINH \r\n	\r\n C \r\n	\r\n 1 \r\n		\r\n \r\n		\r\n \r\n
\r\n S508 \r\n	\r\n KẾT QUẢ HỢP LỆ \r\n	\r\n M \r\n	\r\n 2 \r\n		\r\n \r\n		\r\n 11 \r\n
\r\n 0563 \r\n	\r\n Hạn định giá trị\r\n hợp lệ \r\n	\r\n M \r\n	\r\n \r\n		\r\n 1 \r\n	\r\n 2 \r\n	\r\n \r\n
\r\n 0560 \r\n	\r\n Giá trị hợp lệ \r\n	\r\n C \r\n	\r\n \r\n		\r\n Sig \r\n	\r\n R \r\n	\r\n \r\n
\r\n S508 \r\n	\r\n KẾT QUẢ HỢP LỆ \r\n	\r\n M \r\n	\r\n 2 \r\n		\r\n \r\n		\r\n 11 \r\n
\r\n 0563 \r\n	\r\n Hạn định giá trị\r\n hợp lệ \r\n	\r\n M \r\n	\r\n \r\n		\r\n — \r\n	\r\n 3 \r\n	\r\n \r\n
\r\n 0560 \r\n	\r\n Giá trị hợp lệ \r\n	\r\n C \r\n	\r\n \r\n		\r\n — \r\n	\r\n S \r\n	\r\n \r\n
\r\n CHÚ THÍCH \r\n 1. Cả hai cấu trúc\r\n phải có cùng số lần xuất hiện; \r\n 2. Thừa nhận không\r\n - từ chối gốc bao Chức năng xác thực nguồn gốc thông điệp và toàn vẹn; \r\n 3. Bên gửi thông\r\n điệp; \r\n 4. Bên tiếp nhận\r\n thông điệp; \r\n 5. Bên gửi áp dụng\r\n hàm băm trên cấu trúc an ninh; \r\n 6. Bên sở hữu chứng\r\n chỉ: các chi tiết định danh giống như trong USH S500 cho Bên gửi thông điệp; \r\n 7. Bên xác thực: tổ\r\n chức chứng nhận (CA); \r\n 8. Chức năng chữ ký\r\n của Bên gửi; \r\n 9. Hàm băm của CA; \r\n 10. Chức năng chữ\r\n ký của CA; \r\n 11. Một số thuật\r\n toán ký (như DSA) yêu cầu hai kết quả tham số. \r\n

\r\n\r\n

Tài liệu tham khảo

\r\n\r\n

1. ISO/IEC 646:1991, Information\r\ntechnology - ISO 7 - bít coded character set for information interchange (Công\r\nnghệ thông tin - Bộ ký tự mã hóa 7 bít ISO cho trao đổi thông tin);

\r\n\r\n

2. ISO 8601:2000, Data\r\nelements and interchange formats - Information interchange - Representation of\r\ndates and times (Phần tử dữ liệu và định dạng trao đổi - Trao đổi thông tin -\r\nBiểu diễn ngày và giờ);

\r\n\r\n

3. ISO 8731-1:1987,\r\nBanking - Approved algorithms for message authentication - Part 1: DEA (Nghiệp vụ quản lý - Thuật\r\ntoán dành cho xác thực thông điệp - Phần 1: DEA);

\r\n\r\n

4. ISO/IEC 9797:1994,\r\nInformation technology - Security techniques - Data integrity mechanism using a\r\ncryptographic check function employing a block cipher algorithm (Công nghệ\r\nthông tin - Kỹ thuật an ninh - Cơ chế toàn vẹn dữ liệu sử dụng một Chức năng\r\nkiểm tra mã hóa với một thuật toán mã khối)

\r\n\r\n

5. ISO/IEC 10116:1997\r\nInformation technology - Security techniques - Modes of operation for an n -\r\nbít block cipher (Công nghệ thông tin - Kỹ thuật an ninh - Chế độ thao tác\r\nmột mã khối n - bít);

\r\n\r\n

6. ISO/IEC 10118-2:2000,\r\nInformation technology - Security techniques - Hash-functions - Part 2: Hash -\r\nfunctions using an n - bít block cipher (Công nghệ thông tin - Kỹ thuật an\r\nninh - Hàm băm - Phần 2: Hàm băm sử dụng một mã khối n - bít);

\r\n\r\n

7. ISO/IEC 10181-1:1996,\r\nInformation technology - Open Systems Interconnection - Security frameworks for\r\nopen systems: Overview (Công nghệ thông tin - Liên kết hệ thống mở - Cơ cấu\r\nan ninh hệ thống mở: Khái quát);

\r\n\r\n

8. ISO/IEC 10646-1:2000,\r\nInformation technology - Universal Multiple - Octet Coded Character Set (UCS) -\r\nPart 1: Architecture and Basic Multilingual Plane (Công nghệ thông tin - Bộ\r\nký tự mã hóa bội tám chung (UCS) - Phần 1: Mức đa ngữ cơ bản và kiến trúc);

\r\n\r\n

9. ISO/IEC 11770-1:1996,\r\nInformation technology - Security techniques - Key management - Part 1:\r\nFramework (Công nghệ thông tin - Kỹ thuật an ninh - Quản lý khóa - Phần 1:\r\nCơ cấu).

\r\n\r\n

MỤC\r\nLỤC

\r\n\r\n

Lời giới thiệu

\r\n\r\n

1. Phạm vi áp dụng

\r\n\r\n

2. Sự phù hợp

\r\n\r\n

3. Tiêu chuẩn viện\r\ndẫn

\r\n\r\n

4. Thuật ngữ và định\r\nnghĩa

\r\n\r\n

5. Quy tắc sử dụng\r\ncác nhóm đoạn tiêu đề đuôi an ninh cho EDI lô

\r\n\r\n

5.1. An ninh mức\r\nthông điệp/gói - an ninh thông điệp/gói tích hợp

\r\n\r\n

5.1.1. Khái quát

\r\n\r\n

5.1.2. Các nhóm đoạn\r\ntiêu đề và các đuôi an ninh

\r\n\r\n

5.1.3. Cấu trúc các\r\nnhóm đoạn tiêu đề và đuôi an ninh

\r\n\r\n

5.1.4. Giải thích\r\nđoạn dữ liệu

\r\n\r\n

5.1.5. Phạm vi áp\r\ndụng an ninh

\r\n\r\n

5.2. Nguyên tắc sử\r\ndụng

\r\n\r\n

5.2.1. Lựa chọn dịch\r\nvụ

\r\n\r\n

5.2.2. Tính xác thực

\r\n\r\n

5.2.3. Tính toàn vẹn

\r\n\r\n

5.2.4. Không từ chối\r\ngốc

\r\n\r\n

5.3. Các bộ lọc và\r\nbiểu diễn nội bộ theo cú pháp EDIFACT

\r\n\r\n

6. Quy tắc sử dụng\r\nnhóm đoạn tiêu đề và đuôi an ninh của nhóm và trao đổi cho EDI lô

\r\n\r\n

6.1. An ninh mức nhóm\r\nvà mức trao đổi - an ninh thông điệp tích hợp

\r\n\r\n

6.2. Nhóm đoạn tiêu\r\nđề và đuôi an ninh

\r\n\r\n

6.3. Cấu trúc các\r\nnhóm đoạn tiêu đề và đuôi an ninh

\r\n\r\n

6.4. Phạm vi áp dụng\r\nan ninh

\r\n\r\n

Phụ lục A (tham khảo) Các\r\nmối đe dọa và giải pháp cho an ninh EDIFACT

\r\n\r\n

A.1. Giới thiệu

\r\n\r\n

A.2. Các mối đe dọa an\r\nninh

\r\n\r\n

A.3. Các giải pháp an\r\nninh - Các dịch vụ cơ bản và các nguyên tắc sử dụng

\r\n\r\n

A.3.1. Khái quát

\r\n\r\n

A.3.2. Toàn vẹn thứ\r\ntự

\r\n\r\n

A.3.3. Toàn vẹn nội\r\ndung

\r\n\r\n

A.3.4. Xác thực gốc

\r\n\r\n

A.3.5. Không - từ chối\r\ngốc

\r\n\r\n

A.3.6. Không - từ\r\nchối nhận của bên tiếp nhận

\r\n\r\n

A.3.7. Độ tin cậy về\r\nnội dung

\r\n\r\n

A.3.8. Mối quan hệ\r\ngiữa các dịch vụ an ninh

\r\n\r\n

Phụ lục B (tham khảo) Cách\r\nbảo vệ một cấu trúc EDIFACT

\r\n\r\n

B.1. Khái quát

\r\n\r\n

B.2. Thỏa thuận song\r\nphương/bên thứ ba

\r\n\r\n

B.3. Khía cạnh thực tế

\r\n\r\n

B.4. Thủ tục xây dựng\r\nmột cấu trúc EDIFACT an ninh

\r\n\r\n

B.5. Thứ tự các dịch\r\nvụ an ninh áp dụng

\r\n\r\n

B.6. An ninh thông\r\nđiệp phân tách tại mức thông điệp/gói

\r\n\r\n

B.6.1. Các yêu cầu\r\nnghiệp vụ

\r\n\r\n

B.6.2. An ninh thông\r\nđiệp phân tách được sử dụng bởi bên gửi

\r\n\r\n

B.6.3. An ninh thông điệp\r\nphân tách được sử dụng bởi bên tiếp nhận

\r\n\r\n

B.7. An ninh thông\r\nđiệp phân tách tại mức nhóm hoặc mức trao đổi

\r\n\r\n

Phụ lục C (tham khảo) Các ví\r\ndụ về bảo vệ thông điệp

\r\n\r\n

C.1. Giới thiệu

\r\n\r\n

C.2. Ví dụ 1: xác\r\nthực nguồn gốc thông điệp

\r\n\r\n

C.2.1. Tình huống

\r\n\r\n

C.2.2. Chi tiết an\r\nninh

\r\n\r\n

C.3. Ví dụ 2: Không -\r\ntừ chối gốc, kỹ thuật thứ nhất

\r\n\r\n

C.3.1. Tình huống

\r\n\r\n

C.4. Ví dụ 3: không\r\ntừ chối gốc, kỹ thuật thứ hai

\r\n\r\n

C.4.1. Tình huống

\r\n\r\n

C.4.2. Chi tiết an\r\nninh

\r\n\r\n

Phụ lục D (tham khảo) Các\r\nhàm lọc đối với các kho bộ ký tự A và C của UN/EDIFACT

\r\n\r\n

D.1. Bộ lọc EDA

\r\n\r\n

D.1.1. Cơ sở

\r\n\r\n

D.1.2. Kho bộ ký tự\r\nUN/EDIFACT

\r\n\r\n

D.1.3. Lọc hai thành\r\nba

\r\n\r\n

D.1.5. Giải lọc

\r\n\r\n

D.2. Bộ lọc EDC

\r\n\r\n

D.2.1. Cơ sở

\r\n\r\n

D.2.3. Phép biến đổi\r\ngiải lọc

\r\n\r\n

Phụ lục E (tham khảo) Thuật\r\ntoán và dịch vụ an ninh

\r\n\r\n

E.1. Phạm vi và mục\r\nđích

\r\n\r\n

E.2. Liên kết sử dụng\r\ncác thuật toán đối xứng và các đoạn an ninh tích hợp

\r\n\r\n

E.3. Liên kết sử dụng\r\nkhóa không đối xứng và các đoạn an ninh thích hợp

\r\n\r\n

Tài liệu tham khảo

\r\n\r\n

\r\n\r\n\r\n\r\n\r\n"

Từ khóa: Tiêu chuẩn Việt Nam TCVNISO9735-5:2004, Tiêu chuẩn Việt Nam số TCVNISO9735-5:2004, Tiêu chuẩn Việt Nam TCVNISO9735-5:2004 của Bộ Khoa học và Công nghệ, Tiêu chuẩn Việt Nam số TCVNISO9735-5:2004 của Bộ Khoa học và Công nghệ, Tiêu chuẩn Việt Nam TCVNISO9735 5:2004 của Bộ Khoa học và Công nghệ, TCVNISO9735-5:2004

File gốc của Tiêu chuẩn quốc gia TCVN ISO 9735-5:2004 (ISO 9735-5:2002) về Trao đổi dữ liệu điện tử trong quản lý hành chính, thương mại và vận tải (EDIFACT) – Các quy tắc cú pháp mức ứng dụng (số hiệu phiên bản cú pháp: 4, số hiệu phát hành cú pháp: 1). Phần 5: Quy tắc an ninh cho EDI lô (tính xác thực, tính toàn vẹn và không từ chối gốc) đang được cập nhật.

Tiêu chuẩn quốc gia TCVN ISO 9735-5:2004 (ISO 9735-5:2002) về Trao đổi dữ liệu điện tử trong quản lý hành chính, thương mại và vận tải (EDIFACT) – Các quy tắc cú pháp mức ứng dụng (số hiệu phiên bản cú pháp: 4, số hiệu phát hành cú pháp: 1). Phần 5: Quy tắc an ninh cho EDI lô (tính xác thực, tính toàn vẹn và không từ chối gốc)

- File PDF đang được cập nhật

- File Word Tiếng Việt đang được cập nhật

Cơ quan ban hành	Bộ Khoa học và Công nghệ
Số hiệu	TCVNISO9735-5:2004
Loại văn bản	Tiêu chuẩn Việt Nam
Người ký	Đã xác định
Ngày ban hành	2005-01-14
Ngày hiệu lực
Lĩnh vực	Xây dựng - Đô thị
Tình trạng	Còn hiệu lực

TT	Tên sản phẩm	Giá tiền	Đăng ký
1	Gói cơ bản – 1 năm	350.000 ₫	Đăng nhập
2	Gói cơ bản – 2 năm	700.000 ₫	Đăng nhập
3	Gói cơ bản – 3 năm	1.000.000 ₫	Đăng nhập
4	Gói cơ bản – 6 tháng	180.000 ₫	Đăng nhập
5	Gói cơ bản – 5 năm	1.600.000 ₫	Đăng nhập
6	Gói nâng cao – 1 năm	1.100.000 ₫	Đăng nhập
7	Gói nâng cao – 2 năm	2.300.000 ₫	Đăng nhập
8	Gói nâng cao – 3 năm	3.400.000 ₫	Đăng nhập
9	Gói nâng cao – 6 tháng	594.000 ₫	Đăng nhập
10	Gói nâng cao – 5 năm	5.800.000 ₫	Đăng nhập

Xây dựng - Đô thị

Chính sách mới

Tin văn bản

Tóm tắt

NỘI DUNG

HỖ TRỢ KHÁCH HÀNG

Chọn gói sản phẩm

Xây dựng - Đô thị

Chính sách mới

Tin văn bản

Tóm tắt

NỘI DUNG

HỖ TRỢ KHÁCH HÀNG

Đăng nhập

Đăng ký

Chọn gói sản phẩm