Nghiên cứu sử dụng USB token để bảo vệ khóa bí mật trong giao dịch điện tử trên nền web

Nghiên cứu sử dụng USB token để bảo vệ khóa bí mật trong giao dịch điện tử trên nền web

DANH MỤC HÌNH VẼ 4

DANH MỤC BẢNG 5

MỞ ĐẦU 6

CHƯƠNG I: GIỚI THIỆU 7

CHƯƠNG II: LĨNH VỰC ỨNG DỤNG 9

CHƯƠNG III: MỘT SỐ BẢN MÃ THAM CHIẾU 11

CHƯƠNG IV: MỘT SỐ ĐỊNH NGHĨA 17

CHƯƠNG V: CÁC BIỂU TƯỢNG VÀ CHỮ VIẾT TẮT 21

CHƯƠNG VI: MIÊU TẢ TỔNG QUAN 25

6.1- Giới thiệu : 25

6.2- Thiết kế mục tiêu : 25

6.3- Mô hình tổng quát : 26

6.4- Tổng quan logic của một token 28

6.5- Người dùng : 30

6.6- Trình ứng dụng và sự sử dụng của Cryptoki : 31

6.6-1 Trình ứng dụng và các tiến trình : 31

6.6-2 Trình ứng dụng và các luồng : 32

6.7- Các phiên : 33

6.7-1 Các trạng thái của phiên chỉ đọc : 34

6.7-2 Các trạng thái của phiên đọc/ghi : 35

6.7-3 Đối tượng được phép truy nhập bởi các phiên : 37

6.7-4 Các phiên sự kiện : 38

6.7-5 Các phiên xử lý và các đối tượng xử lý : 39

6.7-6 Các khả năng của các phiên : 40

6.8- Tổng quan về chức năng : 41

CHƯƠNG VII: ỨNG DỤNG USB TOKEN VÀO THƯƠNG MẠI ĐIỆN TỬ CỦA VERISIGN 46

7.1 - Tổng quan về các giải pháp và dịch vụ cho hệ thống xác thực hợp nhất .46

7.2 - Các thành phần xác thực mạnh 47

7.3 - Thẻ token OTP cứng 48

7.3-1 Thẻ token chứa khóa PKI 49

7.3-2 Thẻ token lai giữa OTP và khóa PKI 49

7.3-3 Thẻ token OTP trên điện thoại di động hoặc thiết bị PDA 51

7.3-4 Xác thực dựa trên tin nhắn SMS 51

7.4 - Quy trình phát hành thẻ token OTP (thẻ bảo mật một thời điểm sinh một khóa) 52

7.4-1 Kích hoạt thẻ OTP 53

7.4-2 Đưa ra hình thức xác thực bằng tin nhắn SMS 54

7.4-3 Các dịch vụ chứng thực 55

7.4-4 Chứng thực nhân tố thứ nhất : 55

7.4-5 Xác thực nhân tố thứ hai 55

7.4-6 Chứng thực SDK 55

7.4-7 Xác nhận tính hợp lệ trong đám đông (in the clound) 56

7.4-8 Chứng thực dựa trên giả thuyết 56

7.4-9 Các ứng dụng tự phục vụ 57

7.4-10 Các dịch vụ quản lý 58

7.4-11 Các dịch vụ quản trị 58

7.4-12 Kiểm toán dấu vết 59

7.5 - Cấu trúc kỹ thuật của giải pháp xác thực hai thành phần 59

7.5-1 Mô hình In-the-cloud 60

7.5-2 Mô hình In-Premise 61

7.6 - Các ứng dụng tự phục vụ khách hàng (người dùng) 63

7.7 - Gói phần mềm lập trình phát triển quản lý (SDK) cho modul chứng thực……… 67

7.7-1 Modul chứng thực 68

7.7-2 Quy trình xác nhận tính hợp lệ 69

7.8 - Tổng quan về gói phần mềm lập trình phát triển quản lý (SDK) 71

7.8-1 Kiến trúc gói phần mềm lập trình phát triển quản lý 72

7.8-2 Chức năng gói phần mềm lập trình phát triển quản lý 72

TỔNG KẾT 74

TÀI LIỆU THAM KHẢO 77

DANH MỤC HÌNH VẼ

Hình 6-1 Mô hình Cyptoki tổng quát 26

Hình 6-2 Hệ thống phân cấp đối tượng 28

Hình 6-3 Trạng thái phiên Read/Only 35

Hình 6-4 Trạng thái phiên đọc/ghi 36

Hình 7-2 Kết nạp và hoàn thiện thẻ bảo mật (token) mềm 53

Hình 7-3 Kích hoạt thẻ OTP 54

Hình 7-4 Mô hình triển khai thực hiện giải pháp 59

Hình 7-5 Kiến trúc triển khai giải pháp theo mô hình In-the-cloud 60

Hình 7-6 Kiến trúc triển khai giải pháp theo mô hình In-premise 62

Hình 7-7 Giao diện về quản trị token của người dùng 65

Hình 7-8 Giao diện người dùng tự kích hoạt 66

Hình 7-9 Giao diện người dùng tự kiểm tra thẻ token 67

Hình 7-10 Giao diện đồng bộ token 67

Hình 7-11 Môi trường xác thực sử dụng cơ chế một hời điểm một mật khẩu – OTP 69

Hình 7-12 Kiến trúc gói phần mềm lập trình phát triển quản lý (SDK) 72

DANH MỤC BẢNG

Bảng 5-1 Các ký hiệu 21

Bảng 5-2 Các tiền tố 21

Bảng 5-3 Bộ các ký tự 23

Bảng 6-1 Miêu tả trạng thái của phiên 35

Bảng 6-2 Các trạng thái phiên Read/Write 36

Bảng 6-3 Truy cập tới các loại đối tượng khác nhau bởi các loại phiên khác nhau 37

Bảng 6-4 Các phiên sự kiện 38

Bảng 6-5 Tóm tắt về chức năng của Cryptoki 45

MỞ ĐẦU

Trước tiên xin được cảm ơn sự hướng dẫn của Thạc sỹ Vũ Bảo Thạch

và Kỹ sư Nguyễn Đức Tân đã giúp đỡ rất nhiều trong quá trình thực hiện đồ

án này

Nhờ có sự hướng dẫn của Thạc sỹ Thạch và Kỹ sư Tân, đồ án về :

“Ứng dụng công nghệ USB Token trong việc bảo đảm an toàn thương mạiđiện tử” đã được hoàn thành

Phạm vi và mục đích thực hiện đồ án này là : nghiên cứu về một sốthuật toán và úng dụng của công nghệ USB Token trong việc đảm bảo an toànthương mại điện tử ở Việt Nam, đặc biệt là đối với một số ngân hàng Đồ áncũng giới thiệu về cách thức sử dụng công nghệ USB Token như thế nào

Cấu trúc đồ án gồm có 7 chương chính

1 Giới thiệu về công nghệ USB Token

2 Các lĩnh vực ứng dụng của công nghệ USB Token

3 Một số bảng mã tham chiếu trong công nghệ USB Token

4 Một số định nghĩa được sử dụng

5 Các biểu tượng và chữ viết tắt

6 Miêu tả tổng quan về công nghệ USB Token

7 Ứng dụng công nghệ USB Token trong thương mại điện tử củaVeriSign

Do thời gian nghiên cứu và trình độ hiểu biết có hạn nên đồ án thực

hiện còn nhiều thiếu sót Em xin chân thành cảm ơn Ths Vũ Bảo Thạch và

Kỹ sư Nguyễn Đức Tân đã nhiệt tình hướng dẫn và tạo mọi điều kiện để em

hoàn thành đồ án

Sinh viên

CHƯƠNG I: GIỚI THIỆU

Khi mật mã bắt đầu có sự thừa nhận và ứng dụng rộng rãi, có một điềungày càng rõ ràng là : để nó có được hiệu quả như các công nghệ cơ bản chophép, nó phải có tiêu chuẩn tương thích Mặc dù các nhà cung cấp có thể thoảthuận về các kỹ thuật mật mã cơ bản, nhưng tính tương thích giữa các sự thựchiện là do không mang nghĩa bảo đảm Khả năng cộng tác đòi hỏi phải tuânthủ nghiêm ngặt để đồng ý hay chống lại các chuẩn.

Hướng tới mục tiêu đó, RSA Laboratories đã phát triển, hợp tác với cácđại diện của các ngành công nghiệp, viện hàn lâm và chính phủ, một tâp hợpcác tiêu chuẩn đã ra đời, được gọi là Public-Key Cryptography Standards(chuẩn mật mã khóa công khai), viết tắt là PKCS

PKCS được cung cấp bởi RSA Laboratories để phát triển cho các hệthống máy tính có sử dụng công nghệ khóa công khai và các công nghệ cóliên quan.RSA Laboratories có ý định cải thiện và tinh chỉnh các tiêu chuẩnkết hợp với phát triển hệ thống máy tính, với mục tiêu là sản xuất tiêu chuẩn

mà hầu hết nếu các nhà phát triển thông qua

Vai trò của RSA Laboratories trong quá trình tạo các chuẩn gồm có bốnphần:

1 Xuất bản một cách cẩn thận bằng văn bản tài liệu mô tả các tiêuchuẩn

2 Trưng cầu ý kiến và lời khuyên từ các nhà phát triển và người dùng

về những thay đổi hữu ích hoặc cần thiết và mở rộng

3 Xuất bản sửa đổi tiêu chuẩn khi thích hợp

4 Cung cấp hướng dẫn thực hiện và triển khai việc tham chiếu

Trong quá trình phát triển PKCS, RSA Laboratories vẫn giữ quyền cuốicùng về mỗi tài liệu, mặc dù các nhận xét đầu vào rõ ràng là có ảnh hưởng.Tuy nhiên, mục tiêu của RSA Laboratories là tăng cường sự phát triển củacác tiêu chuẩn chính thức, không phải để cạnh tranh bằng công việc này Vì

vậy, khi một tài liệu PKCS được chấp nhận như một tài liệu cơ sở cho mộttiêu chuẩn chính thức, RSA Laboratories tuyên bố từ bỏ "quyền sở hữu caonhất" của tài liệu, nhường đường cho quá trình phát triển tiêu chuẩn mở.RSA Laboratories có thể tiếp tục phát triển các tài liệu liên quan, tất nhiên,theo các điều khoản được mô tả ở trên.

Tài liệu và thông tin về PKCS có sẵn tại địa chỉ trực tuyếnhttp://www.rsasecurity.com/rsalabs/PKCS/ Cụ thể ta sẽ tìm hiểu vềPKCS#11

CHƯƠNG II: LĨNH VỰC ỨNG DỤNG

Tiêu chuẩn này quy định cụ thể một giao diện lập trình ứng dụng (API),được gọi là "Cryptoki " đối với các thiết bị giữ thông tin mật mã và thực hiệncác chức năng mã hóa Cryptoki, phát âm là "crypto-key" và là viết tắt của

"giao diện mã thông báo mật mã ", đó là một cách tiếp cận đối tượng đơngiản, giải quyết các mục tiêu của công nghệ độc lập (với bất kỳ loại thiết bị)

và chia sẻ tài nguyên (nhiều thiết bị ứng dụng đa truy cập), đại diện cho cácứng dụng logic được chia sẻ chung của thiết bị được gọi là một "mật mãtoken"

Tài liệu này quy định cụ thể các loại dữ liệu và chức năng có sẵn chomột ứng dụng đòi hỏi phải có dịch vụ mật mã bằng cách sử dụng ngôn ngữlập trình ANSI C Các loại dữ liệu và chức năng thông thường sẽ được cungcấp thông qua các tập tin header C bởi nhà cung cấp từ một thư viện Cryptoki.Tập tin header Generic ANSI C cho Cryptoki có sẵn từ các trang PKCS Web.Tài liệu và các bản nâng câp cho Cryptoki cũng sẽ có sẵn từ cùng một nơi

Tài liệu bổ sung có thể cung cấp một giao diện ngôn ngữ độc lậpCryptoki đồng thời cam kết ràng buộc giữa Cryptoki và các ngôn ngữ lậptrình khác

Cryptoki phân lập một ứng dụng từ các chi tiết của thiết bị mật mã Cácứng dụng không phải thay đổi giao diện cho mỗi loại thiết bị khác nhau hoặc

để chạy trong một môi trường khác nhau, do đó, ứng dụng có thể được cầmtay

Một số cơ chế mã hóa (thuật toán) được hỗ trợ trong phiên bản này.Ngoài ra, các cơ chế mới có thể được thêm vào sau đó mà không thay đổigiao diện ban đầu Nó có thể là cơ chế bổ sung sẽ được công bố theo thời giantrong các tài liệu riêng biệt; nó cũng có thể cho phép nhà cung cấp token xácđịnh cơ chế riêng của họ (mặc dù, vì mục tiêu của tính tương hợp, đăng kýthông qua quá trình PKCS là thích hợp hơn)

Cryptoki được dự định dành cho các thiết bị mật mã học gắn liền vớimột người sử dụng, do đó, một số tính năng mà có thể đính kèm được trongmột mục đích chung ban đầu được bỏ qua Ví dụ, Cryptoki không có các biệnpháp phân biệt nhiều người dùng Tiêu điểm là chìa khóa của một người sửdụng và có lẽ một số ít chứng chỉ liên quan đến chúng Hơn nữa, trọng tâm là

về mật mã học Trong khi các thiết bị khác có thể thực hiện nhiều chức nănghữu ích không mật mã, chức năng như vậy là trái với các giao diện khác

CHƯƠNG III: MỘT SỐ BẢN MÃ THAM CHIẾU

– C 1990.

Using Reversible Public Key Cryptography for the Financial Services Industry (rDSA) 1998.

for the Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography 2003.

for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA) 1998.

for the Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography 2001.

Structure and Vocabularies World Wide Web Consortium, January

Data System Specifications: Part 406: Airlink Security 1993.

FIPS PUB 46–3 NIST FIPS 46-3: Data Encryption Standard (DES) October 25,

1999 URL: http://csrc.nist.gov/publications/fips/index.ht ml

Encryption Standard. April 1, 1981 URL: http://csrc.nist.gov/publications/fips/index.ht m

FIPS PUB 81 NIST FIPS 81: DES Modes of Operation December 1980 URL:

URL: http://csrc.nist.gov/publications/fips/index.html

26, 2001 URL: http://csrc.nist.gov/publications/fips/index.ht m l

Interface Programmers Guide, Revision 1.52 November 1995.

(GCS-API), Base - Draft 2 February 14, 1995.

ISO/IEC 7816-1 ISO Information Technology — Identification Cards — Integrated

Circuit(s) with Contacts — Part 1: Physical Characteristics 1998.

ISO/IEC 7816-4 ISO Information Technology — Identification Cards —

Integrated Circuit(s) with Contacts — Part 4: Interindustry Commands for Interchange 1995.

ISO/IEC 8824-1 ISO Information Technology Abstract Syntax Notation One (ASN.1):

Specification of Basic Notation 2002.

ISO/IEC 8825-1 ISO Information Technology—ASN.1 Encoding Rules: Specification

of Basic Encoding Rules (BER), Canonical Encoding Rules (CER),

and Distinguished Encoding Rules (DER) 2002.

ISO/IEC 9594-1 ISO Information Technology — Open Systems Interconnection — The

Directory: Overview of Concepts, Models and Services 2001.

ISO/IEC 9594-8 ISO Information Technology — Open Systems Interconnection — The

Directory: Public-key and Attribute Certificate Frameworks 2001.

Digital Signature Scheme Giving Message Recovery — Part 2: Integer factorization based mechanisms 2002.

2 Micro Edition November 2002 URL:

http://jcp.org/jsr/detail/118.jsp

Version 1.0, February 2003 URL: http://www obiletransaction.org m

Standard, Release 2.1, July 1993.

URL: http://www.rsasecurity.com/rsalabs/pkcs/pkcs-1/index.html

November 1993 URL: http://www.rsasecurity.co m 3/index.html

March 25, 1999 URL: http://www.rsasecurity.co m 5/index.html

/rsalabs/pkcs/pkcs-PKCS #7 RSA Laboratories Cryptographic Message Syntax Standard v1.5,

November 1993 URL: http://www.rsasecurity.co m 7/index.html

November 1993 URL: http://www.rsasecurity.co m 8/index.html

October 2000 URL: http://www.rsasecurity.co m 11/index.html

URL: http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/index.html

v1.0, June 1999 URL: http://www.rsasecurity.co m 12/index.html

Laboratories, April 1992 URL: http://ietf.org/rfc/rfc1319.txt

Laboratory for Computer Science and RSA Data Security, Inc., April

1992 URL: http://ietf.org/rfc/rfc1321.txt

Electronic Mail: Part I: Message Encryption and Authentication Procedures IAB IRTF PSRG, IETF PEM WG,

Mail Extensions (MIME) Part One: Format of Internet Message Bodies November 1996 URL: http://ietf.org/rfc/rfc2045.txt

RFC 2246 T Dierks & C Allen RFC 2246: The TLS Protocol Version 1.0.

Certicom, January 1999 URL: http://ietf.org/rfc/rfc2246.txt

Alis Technologies, January 1998 URL: http://ietf.org/rfc/rfc2279.txt

Features for Display, Print, and Fax March 1999 URL:

http://ietf.org/rfc/rfc2534.txt

URL: http://ietf.org/rfc/rfc2630.txt

Program Interface Version 2, Update 1. RSA Laboratories, January 2000 URL: http://ietf.org/rfc/rfc2743.txt

C- bindings Iris Associates, January 2000.

URL: http://ietf.org/rfc/rfc2744.txt

for Efficient Cryptography (SEC) 1: Elliptic Curve Cryptography.

Version 1.0, September 20, 2000.

for Efficient Cryptography (SEC) 2: Recommended Elliptic Curve Domain Parameters Version 1.0, September 20, 2000.

http://ietf.org/rfc/rfc2246.txt

2001 URL: http://www.wapforu m .org/

WAP-261-WTLS-20010406-a April 2001 URL: http://www.wapforu .org/ m

The Directory: Overview of Concepts, Models and Services February

2001.

Identical to ISO/IEC 9594-1

— The Directory: Public-key and Attribute Certificate Frameworks.

March 2000 Identical to ISO/IEC 9594-8

(ASN.1): Specification of Basic Notation July 2002.

Identical to ISO/IEC 8824-1

Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER) July 2002.

Identical to ISO/IEC 8825-1

CHƯƠNG IV: MỘT SỐ ĐỊNH NGHĨA

Một số định nghĩa ứng dụng trong chuẩn này:

Application Any computer program that calls the Cryptoki

interface.

ASN.1 Abstract Syntax Notation One, as defined in X.680.

Attribute A characteristic of an object.

BATON MISSI’s BATON block cipher.

cipher.

CAST3 Entrust Technologies’ proprietary symmetric block

cipher.

CAST5 Another name for Entrust Technologies’

symmetric block cipher CAST128 CAST128 is the preferred name.

CAST128 Entrust Technologies’ symmetric block cipher.

81

encipherment method specified by International Business Machines Corporation and based on DES.

Certificate A signed message binding a subject name and a public

key, or a subject name and a set of attributes

Cryptographic Device A device storing cryptographic information and

possibly performing cryptographic functions May be implemented as a smart card, smart disk, PCMCIA card, or with some other technology, including

ECDSA Elliptic Curve DSA, as in ANSI X9.62.

ECMQV Elliptic Curve Menezes-Qu-Vanstone

FASTHASH MISSI’s FASTHASH message-digesting algorithm.

JUNIPER MISSI’s JUNIPER block cipher.

defined in RFC 1319.

defined in RFC 1321.

Mechanism A process for implementing a cryptographic operation.

Object An item that is stored on a token May be data, a

certificate, or a key.

PKCS Public-Key Cryptography Standards.

cipher.

Reader The means by which information is exchanged with a

device.

Session A logical connection between an application token.

SHA-1 The (revised) Secure Hash Algorithm with a 160-bit

message digest, as defined in FIPS PUB 180-2.

SHA-256 The Secure Hash Algorithm with a 256-bit message

digest, as defined in FIPS PUB 180-2.

SHA-384 The Secure Hash Algorithm with a 384-bit message

digest, as defined in FIPS PUB 180-2.

SHA-512 The Secure Hash Algorithm with a 512-bit message

digest, as defined in FIPS PUB 180-2.

Slot A logical reader that potentially contains a token.

SKIPJACK MISSI’s SKIPJACK block cipher.

Subject Name The X.500 distinguished name of the entity to which a

key is assigned.

Token The logical view of a cryptographic device defined by

Cryptoki.

User The person using an application that interfaces to

Cryptoki.

UTF-8 Universal Character Set (UCS) transformation format

(UTF) that represents ISO 10646 and UNICODE strings with a variable number of octets.

WTLS Wireless Transport Layer Security.

CHƯƠNG V: CÁC BIỂU TƯỢNG VÀ CHỮ VIẾT TẮT

Sau đây là một số ký hiệu và các tiền tố được dùng trong chuẩn này :

Bảng 5-1 Các ký hiệu

Bảng 5-2 Các tiền tố

Cryptoki dựa trên kiểu ANSI C và được định nghĩa theo một số kiểu dữ liệusau :

/* an unsigned 8-bit value */

typedef unsigned char CK_BYTE;

/* an unsigned 8-bit character */

typedef CK_BYTE CK_CHAR;

/* an 8-bit UTF-8 character */

typedef CK_BYTE CK_UTF8CHAR;

/* a BYTE-sized Boolean flag */

typedef CK_BYTE CK_BBOOL;

/* an unsigned value, at least 32 bits long */

typedef unsigned long int CK_ULONG;

/* a signed value, the same size as a CK_ULONG */

typedef long int CK_LONG;

/* at least 32 bits; each bit is a Boolean flag */

typedef CK_ULONG CK_FLAGS;

Cryptoki còn sử dụng một số cách gõ tắt đối với một số các loại dữ liệu

mà có thể thực hiện độc lập Một số cách gõ như sau :

CK_UTF8CHAR_PTR /* Pointer to a CK_UTF8CHAR */

Cryptoki còn định nghĩa đối với CK_VOID_PTR như sau :

CK_VOID_PTR_PTR /* Pointer to a CK_VOID_PTR */

Ngoài ra, Cryptoki định nghĩa một C-style NULL như sau :

Điều đó dẫn đến nhiều các dữ liệu và các loại con trỏ sẽ thay đổi đôi chút

từ một môi trường khác (ví dụ, một CK_ULONG đôi khi sẽ có 32 bit, và đôikhi có thể là 64 bit) Tuy nhiên, những chi tiết này không ảnh hưởng đến một

ứng dụng, giả sử nó được biên dịch với tập tin Cryptoki header phù hợp vớicác thư viện Cryptoki mà ứng dụng được liên kết.

Tất cả các con số và các giá trị thể hiện trong tài liệu này là số thập phân,trừ khi chúng đứng trước bởi "0x", trong trường hợp đó chúng là giá trị thậplục phân

Các kiểu dữ liệu CK_CHAR bao gồm các ký tự từ bảng sau, lấy từ ANSI

C :

Bảng 5-3 Bộ các ký tự

Các kiểu dữ liệu CK_UTF8CHAR dùng UTF-8 mã hóa các ký tựUnicode theo quy định trong RFC2279 UTF-8 tuân theo các chuẩn quốc tếtrong khi đó vẫn duy trì tính tương thích ngược với định nghĩa Local Stringcủa PKCS # 11 phiên bản 2,01

Trong Cryptoki, các kiểu dữ liệu CK_BBOOL là một kiểu Boolean cóthể đúng hoặc sai Giá trị số 0 có nghĩa là sai, và một giá trị khác 0 có nghĩa làđúng sự thật Tương tự, một flag bit riêng lẻ, CKF_ , cũng có thể được thiết

lập (đúng) hoặc bỏ thiết lập (sai) Để thuận tiện, Cryptoki định nghĩa cácmacro sau đây để sử dụng với các giá trị của CK_BBOOL:

#define CK_FALSE 0

#define CK_TRUE 1

Đối với tính tương thích ngược, các tập tin tiêu đề cho phiên bản nàycủa Cryptoki cũng định nghĩa TRUE và FALSE như sau(CK_DISABLE_TRUE_FALSE có thể được thiết lập bởi các nhà cung cấpứng dụng) :

CHƯƠNG VI: MIÊU TẢ TỔNG QUAN 6.1- Giới thiệu :

Thiết bị điện toán di động như thẻ thông minh, thẻ PCMCIA, và đĩamềm thông minh là công cụ lý tưởng để thực hiện mật mã hóa khóa côngkhai, vì chúng cung cấp một cách để lưu trữ các thành phần khóa bí mậtquantrọng của một cặp khóa bí mật/khóa công khai an toàn dưới sự kiểm soát củamột người dùng duy nhất Với thiết bị như vậy, một ứng dụng mã hóa, thay vìthực hiện các hoạt động mật mã riêng của mình nó sử dụng các thiết bị đểthực hiện các hoạt động với các thông tin nhạy cảm như các khóa riêngkhông bao giờ được tiết lộ Như các ứng dụng khác được phát triển cho mật

mã khóa công khai, một giao diện lập trình chuẩn cho các thiết bị này ngàycàng trở nên có giá trị

6.2- Thiết kế mục tiêu :

Cryptoki được dự định từ lúc bắt đầu để có một giao diện giữa các ứngdụng và tất cả các loại thiết bị cầm tay mã hóa (như là những người dựa trênthẻ thông minh, thẻ PCMCIA, và đĩa mềm thông minh) Đã có một số chuẩn(theo thông lệ hay chính thức) cho giao diện của các thiết bị này ở cấp một số

Ví dụ, các đặc tính cơ học và kết nối điện đều được xác định, như là nhữngphương pháp để cung cấp các lệnh và nhận được kết quả

Những gì đã được định nghĩa vẫn được duy trì cho từng câu lệnh cụ thểcủa mật mã học Nó sẽ không chỉ đơn giản là đủ để định nghĩa câu lệnh càiđặt cho từng loại thiết bị, vì làm như thế sẽ không giải quyết vấn đề chung củamột giao diện ứng dụng độc lập của thiết bị đó Để làm giải quyết vấn đề đóvẫn còn một mục tiêu dài hạn, và chắc chắn sẽ góp phần vào khả năng tươngtác Mục tiêu chính của Cryptoki có một giao diện lập trình cấp thấp mà tómtắt các chi tiết của các thiết bị, và đưa ra cho các ứng dụng một mô hình phổbiến của thiết bị mật mã, được gọi là một "mật mã token" (hoặc đơn giản là

"token")

Một mục tiêu thứ hai là tài nguyên chia sẻ Khi hệ điều hành máy tính

để bàn đa chức năng trở nên phổ biến hơn, một thiết bị duy nhất cần được

chia sẻ giữa nhiều ứng dụng Ngoài ra, một ứng dụng sẽ có thể giao diện vớinhiều thiết bị tại một thời gian nhất định.

Đó không phải là mục tiêu của Cryptoki tạo được một giao diện chung

để hoạt động mã hóa hoặc dịch vụ bảo vệ, mặc dù chắc chắn có thể xây dựngmột trong những hoạt động và dịch vụ với các chức năng mà Cryptoki cungcấp Cryptoki là nhằm bổ sung, không phải là cạnh tranh, như vậy mới có thểđưa ra và đang phát triển các giao diện như là "Generic an ApplicationProgramming Interface" (RFC 2743 và RFC 2744) và "GenericCryptographic Service API" (GCS-API) từ X / Open

6.3- Mô hình tổng quát :

Mô hình chung của Cryptoki được minh họa trong hình sau Mô hìnhnày bắt đầu với một hoặc nhiều ứng dụng mà cần phải thực hiện một số hoạtđộng mật mã, và kết thúc với một hoặc nhiều thiết bị mã hóa, mà trên đó một

số hoặc tất cả các hoạt động đang thực sự thực hiện Một người dùng có thểhoặc không được liên kết với một ứng dụng

Hình 6-1 Mô hình Cyptoki tổng quát

Cryptoki cung cấp một giao diện cho một hoặc nhiều thiết bị mã hoáđang hoạt động trong hệ thống thông qua một số "khe" Mỗi khe tương ứng

với một giao diện đầu đọc vật lý hoặc thiết bị khác có thể chứa một mã thôngbáo Một token thường được "hiện diện trong khe" khi một thiết bị mã hóa cótrong đầu đọc Tất nhiên, từ khi Cryptoki cung cấp một quan điểm logic vềcác khe cắm và thẻ, có thể có cách diễn giải khác về mặt vật lý Có thể lànhiều khe cắm có thể chia sẻ cùng một đầu đọc vật lý Điểm quan trọng làmột hệ thống có một số số khe, và các ứng dụng có thể kết nối với thẻ ở bất

kỳ khe nào hoặc tất cả các khe

Một thiết bị mã hóa có thể thực hiện một số hoạt động mật mã bởi mộttập lệnh nào đó, các lệnh này thường được truyền qua các trình điều khiểnthiết bị tiêu chuẩn, ví dụ như cho các dịch vụ thẻ PCMCIA, dịch vụ socket.Cryptoki làm cho mỗi thiết bị mật mã dò tìm một cách logic như mọi thiết bịkhác, bất kể công nghệ thực hiện Vì vậy, các ứng dụng không cần phải kếtnối trực tiếp đến các trình điều khiển thiết bị (thậm chí chúng biết những thiết

bị có liên quan); Cryptoki giấu những chi tiết này Thật vậy, các "thiết bị cơbản" có thể được thực hiện hoàn toàn bằng phần mềm (ví dụ, như một quátrình đang chạy trên một máy chủ), không có phần cứng đặc biệt là điều cầnthiết

Cryptoki có khả năng được thực hiện như một thư viện hỗ trợ các chứcnăng trong giao diện và các ứng dụng sẽ được kết nối vào thư viện đó Mộtứng dụng có thể được liên kết đến Cryptoki trực tiếp; cách khác, Cryptoki cóthể là một thư viện “chia sẻ" (hoặc thư viện liên kết động), trong trường hợpnày, ứng dụng sẽ liên kết thư viện động Thư viện chia sẻ là khá đơn giản đểtạo ra trong các hệ điều hành như Microsoft Windows và OS / 2, và có thể đạtđược mà không có quá nhiều khó khăn trong UNIX và các hệ thống DOS

Cách tiếp cận động chắc chắn có nhiều lợi ích khi các thư viện mớiđược làm sẵn có, nhưng từ góc độ an ninh, có một số nhược điểm Đặc biệt,nếu thư viện có thể dễ dàng thay thế, có khả năng một kẻ tấn công có thể thaythế bằng một thư viện giả nhằm chặn mã PIN của người dùng Do đó, từ quanđiểm bảo mật, kết nối trực tiếp nói chung là thích hợp hơn, mặc dù kỹ thuậtmật mã chữ ký số có thể ngăn ngừa rất nhiều các rủi ro an ninh của liên kếtđộng Trong mọi trường hợp, cho dù là trực tiếp hoặc liên kết động, giao diệnlập trình giữa ứng dụng và thư viện Cryptoki vẫn giữ nguyên

Các loại thiết bị và khả năng hỗ trợ sẽ phụ thuộc vào thư viện Cryptoki

cụ thể Tiêu chuẩn này quy định cụ thể chỉ dành các giao diện cho thư viện,không phải tính năng của nó Đặc biệt, không phải tất cả các thư viện sẽ hỗtrợ tất cả các cơ chế (thuật toán) được định nghĩa trong giao diện này (vìkhông phải tất cả các thẻ dự kiến sẽ hỗ trợ tất cả các cơ chế), và các thư viện

sẽ có khả năng chỉ hỗ trợ một tập hợp của tất cả các loại thiết bị mã hóa cósẵn (Tất nhiên các loại càng chi tiết càng tốt, và nó được dự đoán rằng cácthư viện sẽ được phát triển dể có thể hỗ trợ nhiều loại mã thông báo, thay vìchỉ những mã từ một nhà cung cấp duy nhất.) Người ta dự đoán rằng các ứngdụng được phát triển là giao diện của Cryptoki, tiêu chuẩn thư viện và token

sẽ nổi bật lên

6.4- Tổng quan logic của một token

Tổng quan logic Cryptoki của một token là một thiết bị mà các đốitượng lưu trữ và có thể thực hiện chức năng mã hóa Cryptoki định nghĩa baloại đối tượng: dữ liệu, chứng chỉ, và các khóa Một đối tượng dữ liệu đượcxác định bởi một ứng dụng Một giấy đối tượng chứng chỉ lưu trữ một chứngchỉ Một đối tượng khóa lưu trữ một chìa khóa mật mã Các khóa có thể làmột khóa công khai, một khóa riêng, hoặc một khóa bí mật, mỗi loại khóa cónhiều phân nhóm để sử dụng trong từng cơ chế cụ thể Tổng quan này đượcminh họa trong hình sau đây:

Hình 6-2.

Hệ thống phân cấp đối tượng

Các đối tượng cũng được phân loại theo suốt cuộc đời và tính chất củachúng Các đối tượng "Token " ở trạng thái sẵn sàng cho tất cả các ứng dụng

kết nối với các mã thông báo rằng có thẩm quyền, và vẫn duy trì trên các

“token” thậm chí ngay cả sau khi các “phiên” (kết nối giữa một ứng dụng vàcác token) được đóng cửa và các mã thông báo được lấy ra từ khe của nó

"Đối tượng phiên" mang tính tạm thời hơn: bất cứ khi nào một phiên đóngcửa bằng bất kỳ nào, tất cả các đối tượng được tạo ra bởi phiên đó có thể tựđộng bị phá hủy Ngoài ra, các đối tượng phiên chỉ sãn sàng cho các ứng đãdụng tạo ra chúng

Ngoài ra việc phân loại cũng định nghĩa các yêu cầu truy cập Các ứngdụng không cần phải đăng nhập vào các mã thông báo để xem các đối tượng

"public", tuy nhiên, để xem các đối tượng "private", một người dùng phảiđược xác thực với một token bởi một mã PIN hoặc một số phương pháp mãthông báo phụ thuộc khác (ví dụ như một thiết bị sinh trắc học)

Một token có thể tạo ra và phá hủy các đối tượng, thao tác chúng, vàtìm kiếm cho chúng Nó cũng có thể thực hiện chức năng mã hóa đối với cácđối tượng Một token có thể có một số máy khởi phát nội bộ ngẫu nhiên

Điều quan trọng để phân biệt giữa tổng quan logic của một token vàthực hiện thực tế, bởi vì không phải tất cả các thiết bị mã hóa sẽ có khái niệmnày của các "đối tượng", hoặc có thể thực hiện tất cả các loại chức năng mãhóa Nhiều thiết bị chỉ đơn giản là sẽ phải cố định nơi lưu trữ cho các khóacủa một thuật toán cố định, và có khả năng thực hiện một cài đặt được giớihạn của các hoạt động Vai trò của Cryptoki là để chuyển đổi sang tổng quanlogic, lập bản đồ thuộc tính đến các yếu tố lưu trữ cố định và tiếp tục như vậy.Không phải tất cả các thư viện Cryptoki và các token cần hỗ trợ mọi loại đốitượng Dự kiến tiêu chuẩn "profile" sẽ được phát triển, xác định bộ các thuậttoán để được hỗ trợ

"Thuộc tính" là đặc tính phân biệt một trường hợp của một đối tượng.Trong Cryptoki, có những thuộc tính nói chung, chẳng hạn như cho dù đốitượng là bí mật hoặc công khai Ngoài ra còn có thuộc tính là đặc trưng chomột loại đối tượng, như là một module hoặc số mũ cho các khóa RSA

6.5- Người dùng :

Phiên bản này của Cryptoki công nhận hai loại người dùng token Mộtloại là một Security Officer (SO) Loại khác là người sử dụng bình thường

Chỉ có những người dùng thông thường được phép truy cập vào các đối tượngprivate trên token, và truy cập đó được cấp chỉ sau khi người dùng bìnhthường đã được chứng thực Một số token cũng có thể yêu cầu người dùngphải xác thực trước khi bất kỳ chức năng mã hóa nào được thực hiện trên cáctoken, thậm chí nó có thể ko liên quan đến các đối tượng private Vai trò của

SO là để khởi tạo một mã thông báo và để thiết lập mã PIN người dùng bìnhthường (hoặc các định nghĩa khác, bởi một số phương pháp ngoài phạm vicủa phiên bản Cryptoki này, làm thế nào người dùng bình thường có thể đượcchứng thực), và có thể thao tác với một số đối tượng public Người dùngthông thường không thể đăng nhập cho đến khi SO có thiết lập mã PIN củangười dùng đó

Khác với sự hỗ trợ cho hai loại người dùng, Cryptoki không giải quyếtcác mối quan hệ giữa SO và một nhóm người dùng Đặc biệt, SO và ngườidùng bình thường có thể được cùng là một người hoặc có thể khác nhau,nhưng những vấn đề như vậy là ngoài phạm vi của tiêu chuẩn này

Đối với mã PIN được nhập vào thông qua một ứng dụng, Cryptoki chỉgiả định chúng là những chuỗi các ký tự có độ dài biến đổi từ các thiết lậptrong Bảng 3 Bất kỳ sự chuyển đổi đến yêu cầu của thiết bị là mặt trái đối vớithư viện Cryptoki Các vấn đề sau đây được vượt quá phạm vi của Cryptoki :

 Bất kỳ tư liệu không cần thiết của mã PIN

 Làm thế nào các mã PIN được tạo ra (do người sử dụng, bởiứng dụng, hoặc bằng một số phương tiện khác)

Mã PIN được cung cấp bởi một số phương tiện khác hơn là thông quamột ứng dụng (ví dụ, mã PIN được nhập thông qua một PINpad trên token) làtrừu tượng nhiều hơn Cryptoki biết làm thế nào để chờ đợi (nếu cần), nhưvậy PIN sẽ được cung cấp và sử dụng, và ít hơn nữa

6.6- Trình ứng dụng và sự sử dụng của Cryptoki :

Với Cryptoki, một ứng dụng bao gồm một không gian địa chỉ duy nhất

và tất cả các luồng điều khiển chạy trong nó Một ứng dụng sẽ trở thành một

"Cryptoki ứng dụng" bằng cách gọi chức năng C_Initialize Cryptoki từ một

trong những luồng của nó; sau khi cuộc gọi này được thực hiện, ứng dụng cóthể gọi các chức năng Cyptoki khác Khi ứng dụng được thực hiện xong bằngcách sử dụng Cryptoki, nó gọi hàm Cryptoki C_Finalize và không còn là mộtứng dụng Cryptoki nữa.

6.6.1 Trình ứng dụng và các tiến trình :

Nói chung, trên hầu hết các nền tảng, phần đã trình bày trước mangnghĩa là một ứng dụng bao gồm một tiến trình đơn lẻ

Hãy xem xét một quá trình UNIX P mà trở thành một ứng dụng

Cyptoki bằng cách gọi C_Initialize, và sau đó sử dụng fork () gọi hệ thống

để tạo ra một tiến trình con C Vì P và C có không gian địa chỉ riêng biệt(hoặc khi một trong số chúng thực hiện một hoạt động viết, nếu hệ điều hànhtheo sau đó có các bản sao mô hình), chúng không phải là một phần của cùngmột ứng dụng Do đó, nếu C có nhu cầu sử dụng Cryptoki, nó cần thực hiệncuộc gọi riêng cho C_Initialize của nó Hơn nữa, nếu C cần phải được đăngnhập vào các token nó sẽ truy cập thông qua Cryptoki, nó cần phải đăng nhậpvào chúng thậm chí ngay cả khi P đã đăng nhập, kể từ đây P và C là các ứngdụng hoàn toàn riêng biệt

Trong trường hợp này (khi C là con của một tiến trình mà nó là mộtứng dụng Cryptoki), sự giao tiếp của Cryptoki là không xác định nếu C cốgắng sử dụng nó mà không gọi C_Initialize riêng của mình Lý tưởng nhất,như một nỗ lực sẽ trả về giá trị CKR_CRYPTOKI_NOT_INITIALIZED, tuy

nhiên, vì cách hoạt động của fork (), nhấn mạnh vào giá trị này lại có thể có

một ảnh hưởng xấu đến hiệu suất của các thư viện Vì vậy, sự giao tiếp củaCryptoki trong hoàn cảnh này là ko xác định Các ứng dụng nên chắc chắnkhông cố gắng tận dụng lợi thế của bất kỳ "các phím tắt tiềm năng" mà có thể

có (hoặc có thể không!) có sẵn vì điều này

Trong kịch bản quy định trên, C thực sự nên gọi C_Initialize hay khôngtùy vào nhu cầu sử dụng Cryptoki, nếu nó không cần phải sử dụng Cryptoki,

nó nên gọi C_Finalize ngay lập tức sau đó Điều này (có tiến trình con ngaylập tức gọi C_Initialize và sau đó gọi C_Finalize nếu tiến trình cha mẹ đang

sử dụng Cryptoki) được coi là lập trình thực hành Cryptoki tốt, vì nó có thể

ngăn chặn sự tồn tại của trùng lặp nguồn lực mà được tạo ra tại thời điểm các

fork () gọi , tuy nhiên, nó không phải là yêu cầu của Cryptoki.

đa luồng với các thư viện:

1 Các ứng dụng có thể xác định rằng nó sẽ không được truy cập vào thưviện đồng thời từ nhiều luồng, và vì thế thư viện không cần phải lo lắng

về việc thực hiện bất kỳ loại khóa vì mục tiêu của luồng an toàn

2 Các ứng dụng có thể xác định rằng nó sẽ được truy cập vào thư việnđồng thời từ nhiều luồng, và các thư viện phải có khả năng sử dụng hệđiều hành đồng bộ hóa tự nhiên ban đầu để bảo đảm các giao tiếp luồng

an toàn hợp lý

3 Các ứng dụng chỉ rõ rằng nó sẽ có thể truy cập vào thư viện đồng thời

từ nhiều luồng, và các thư viện phải sử dụng một bộ các ứng dụng đồng

bộ hóa được hỗ trợ từ đầu để bảo đảm sự hợp thức cho giao tiếp củacác luồng an toàn

4 Các ứng dụng có thể chỉ rõ rằng nó sẽ có thể truy cập vào thư việnđồng thời từ nhiều luồng, và các thư viện phải sử dụng hoặc các ứngdụng đồng bộ hóa được hỗ trợ từ đầu, hoặc thiết lập một hệ thống cácứng dụng đồng bộ hóa được hỗ trợ từ đầu để bảo đảm sự hợp thức chogiao tiếp của các luồng an toàn

Các loại thứ 3 và thứ 4 của hành động được liệt kê ở trên là thích hợpcho các ứng dụng đa luồng mà không sử dụng mô hình hệ điều hành ban đầu.Các ứng dụng đồng bộ hóa ban đầu được hỗ trợ bao gồm bốn chức năng xửlý: các đối tượng mutex (loại trừ lẫn nhau) trong mô hình luồng của ứng dụng.Các đối tượng Mutex là đối tượng đơn giản mà có thể ở một trong hai trạngthái tại bất kỳ thời điểm nhất định: mở khóa hoặc bị khóa Nếu một cuộc gọiđược thực hiện bởi một luồng để khóa một mutex mà nó đã bị khóa, nên các

khối luồng (chờ đợi) cho đến khi mutex được mở khóa, sau đó nó khóa lại vàtrở lại cuộc gọi Nếu nhiều hơn một luồng đang bị chặn trên một mutex cụthể, và rằng mutex đó trở thành không bị khóa, sau đó chính xác là một trongnhững luồng đó sẽ nhận được khóa trên các mutex và trở lại kiểm soát vớingười gọi (các luồng đang chặn khác sẽ tiếp tục khóa và chờ đợi đến lượt củachúng).

Ngoài việc cung cấp ở trên luồng xử lý thông tin cho một thư việnCryptoki lúc khởi tạo, một ứng dụng cũng có thể xác định có hoặc không đềcác luồng ứng dụng thực hiện các cuộc gọi thư viện có thể sử dụng hệ điềuhành ban đầu gọi để tạo các luồng mới

6.7- Các phiên :

Cryptoki yêu cầu mở một ứng dụng một hoặc nhiều phiên với mộttoken để được truy cập vào các đối tượng và chức năng của token Một phiêncung cấp một kết nối logic giữa ứng dụng và token Một phiên có thể là mộtphiên đọc / ghi (R / W) hoặc một phiên chỉ đọc (R / O) Phiên đọc / ghi vàphiên chỉ đọc tham chiếu việc truy cập vào các đối tượng của token, khôngphải vào các đối tượng của phiên Trong cả hai loại phiên, một ứng dụng cóthể tạo, đọc, viết và phá hủy các đối tượng của phiên, và đọc các đối tượngtoken Tuy nhiên, chỉ trong một phiên đọc / ghi một ứng dụng có thể tạo,chỉnh sửa, và phá hủy các đối tượng token

Sau khi mở một phiên, một ứng dụng truy cập vào các đối tượng publiccủa token Tất cả các luồng của một ứng dụng có thể truy cập một cách chínhxác cùng các phiên và các đối tượng của các phiên Để được truy cập vào cácđối tượng private của token, người dùng thông thường phải đăng nhập vàđược xác thực

Khi một phiên đóng cửa, bất kỳ đối tượng mà được tạo ra trong phiên

đó được tiêu huỷ Điều này giữ nguyên ngay cả đối với các đối tượng củaphiên mà "đang được sử dụng" bởi phiên khác Tức là, nếu một ứng dụng duynhất có nhiều phiên mở với một token, và nó sử dụng một trong số chúng đểtạo ra một đối tượng phiên, sau đó là đối tượng phiên đó có thể nhìn thấythông qua bất kỳ các phiên nào của ứng dụng Tuy nhiên, ngay sau khi phiên

đã được sử dụng để tạo các đối tượng được đóng lại, đối tượng được tiêu huỷ

Cryptoki hỗ trợ nhiều phiên chạy trên nhiều token Một ứng dụng cóthể có một hoặc nhiều phiên với một hoặc nhiều token Nói chung, một token

có thể có nhiều phiên với một hoặc nhiều ứng dụng Một token riêng biệt cóthể cho phép một ứng dụng chỉ có một số phiên giới hạn, hoặc chỉ hạn chế sốphiên đọc / ghi

Một phiên mở có thể ở trong một số tình trạng Trạng thái phiên quyếtđịnh quyền truy cập tới các đối tượng và chức năng mà có thể được thực hiệntrên chúng Các trạng thái phiên được mô tả trong mục 6.7.1 và mục 6.7.2

6.7.1 Các trạng thái của phiên chỉ đọc :

Một phiên chỉ đọc có thể ở một trong hai trạng thái, như minh họatrong hình sau Khi phiên làm việc đó lần đầu được mở ra, đó là trong trạngthái "R / O phiên public" (nếu ứng dụng không có các phiên trước đó đã mởđược đăng nhập) hay trạng thái "R / O chức năng người dùng" (nếu ứng dụng

đã có một phiên mở đã được đăng nhập) Lưu ý rằng các phiên SO chỉ đọckhông tồn tại

Hình 6-3 Trạng thái phiên Read/Only

Bảng sau miêu tả các trạng thái của phiên :

Trạng thái Miêu tả

Phiên R/O

Public

Các ứng dụng đã mở một phiên họp chỉ đọc Ứng dụng này đã sự truy cập chỉ đọc vào các đối tượng token public và truy cập đọc/ghi đối với các đối tượng của phiên public

Các chức năng

người dùng R/O

Người dùng thông thường đã được chứng thực đối với các token Ứng dụng này truy cập chỉ đọc vào tất cả các đối tượng token (public hay private) và truy cập đọc/ghi vào tất cả các đối tượng của phiên (public hay private)

Bảng 6-1 Miêu tả trạng thái của phiên

6.7.2 Các trạng thái của phiên đọc/ghi :

Một phiên đọc/ghi có thể ở một trong ba trạng thái, như minh họa tronghình sau Khi phiên được mở ra, đó là trong hoặc trạng thái "phiên R / Wpublic" (nếu ứng dụng không có các phiên mở trước đó đã được đăng nhập),các trạng thái "R / W chức năng người dùng" (nếu ứng dụng đã mở phiên màngười dùng thông thường đăng nhập vào), hoặc trạng thái "chức năng R / WSercủity Officer " (nếu ứng dụng đã có một phiên mở mà SO đã đăng nhậpvào)

Hình 6-4 Trạng thái phiên đọc/ghi

Các trạng thái của phiên được miêu tả trong bảng :

Phiên R/W public Các ứng dụng đã mở một phiên đọc / ghi Ứng

dụng này có sự truy cập đọc / ghi vào tất cả các đối tượng public

Các chức năng R/W

SO

Các Sercurity Officer đã được chứng thực với các token Ứng dụng này chỉ truy cập đọc / ghi duy nhất vào đối tượng public trên token, khôngphải các đối tượng private Các SO có thể thiết lập mã PIN của người dùng thông thường

Các chứng nằng

người dùng R/W

Người dùng thông thường đã được chứng thực với các token Ứng dụng này đã truy cập đọc / ghi vào tất cả các đối tượng

Bảng 6-2 Các trạng thái phiên Read/Write

6.7.3 Đối tượng được phép truy nhập bởi các phiên :

Bảng sau đây tóm tắt các loại truy cập vào từng loại phiên đối với từngloại đối tượng Một loại được của phiên đã hoặc truy cập chỉ đọc, truy cập đọc/ ghi, hoặc truy cập thông thường tới một loại đối tượng nhất định

Lưu ý rằng việc tạo hoặc xóa một đối tượng yêu cầu truy cập đọc / ghivào nó, ví dụ như, một phiên "chức năng người dùng R / O" không thể tạohoặc xóa một đối tượng token

Bảng 6-3 Truy cập tới các loại đối tượng khác nhau bởi các loại phiên

khác nhau

Như đã chỉ ra, việc truy cập tới một đối tượng phiên cụ thể trong Bảng

6 bị hạn chế đến các phiên thuộc về các ứng dụng mà sở hữu đối tượng (ví dụ,trong đó tạo ra đối tượng)

6.7.4 Các phiên sự kiện :

Sự kiện của phiên gây ra các trạng thái thay đổi Bảng dưới đây mô tảcác sự kiện:

Bảng 6-4 Các phiên sự kiện

Khi thiết bị được lấy ra, tất cả các phiên của tất cả các ứng dụng được

tự động thoát ra Hơn nữa, tất cả các phiên bất kỳ ứng dụng có với thiết bịđóng lại (hành động này sau này đã không có mặt trong phiên bản 1.0 củaCryptoki)-một ứng dụng không thể có một phiên với một token mà không có

ở hiện tại Thực tế, Cryptoki có thể không được liên tục theo dõi có haykhông token, và do đó sự vắng mặt của token không được chú ý cho đến khimột chức năng Cryptoki được thực thi Nếu là token lại đưa vào khe trước đó,Cryptoki không bao giờ có thể biết rằng nó đã mất tích.

Trong Cryptoki, tất cả các phiên mà một ứng dụng đã có một tokenphải có cùng một tên đăng nhập / đăng xuất trạng thái (tức là, cho một ứngdụng nhất định và token, một trong những điều sau đây: tất cả các phiên làphiên public; tất cả các phiên là phiên SO; hoặc tất cả phiên là phiên ngườidùng) Khi một phiên của ứng dụng đăng nhập vào một token, tất cả các phiêncủa ứng dụng đó với token đó đều ở trạng thái đã đăng nhập, và khi một phiênđăng xuất khỏi token, tất cả các phiên của ứng dụng đó với cùng token dềuđăng xuất Tương tự như vậy,ví dụ, nếu một ứng dụng đã có một phiên ngườidùng R / O mở với một token, và sau đó sẽ mở ra một phiên R / W với token

đó, phiên R / W được tự động đăng nhập

Điều này ngụ ý rằng một ứng dụng nhất định có thể không đồng thời cócác phiên SO và các phiên người dùng mở ra với một token cụ thể Nó cũngngụ ý rằng nếu một ứng dụng có một phiên R / W Sercurity Officer với mộttoken, sau đó nó có thể không mở một phiên R / O với token đó, kể từ đó cácphiên R / O Sercurity Officer không tồn tại Đối với lý do tương tự, nếu mộtứng dụng có một phiên R/O mở, sau đó nó có thể không đăng nhập bất kỳphiên khác vào các token là Sercurity Officer

6.7.5 Các phiên xử lý và các đối tượng xử lý :

Một phiên xử lý là một giá trị Cryptoki được gán xác định một phiên

Đó là một trong nhiều cách gần giống như một tập tin xử lý, và quy định chứcnăng để chỉ ra chức năng của phiên nào họp nên hoạt động Tất cả các luồngcủa một ứng dụng có sự truy cập ngang bằng tới tất cả các phiên xử lý Theo

đó, bất cứ điều gì có thể được hoàn thành với một tập tin xử lý cụ thể bởi mộtluồng cũng có thể được hoàn thành với tập tin xử lý đó bởi bất kỳ các luồngkhác của cùng một ứng dụng