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
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.4 MB, 74 trang )
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
TÀI LIỆU THAM KHẢO......................................................................................................................74
1
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Ẽ
Hình 7-2. Kết nạp và hoàn thiện thẻ bảo mật (token) mềm............................................................50
Hình 7-3. Kích hoạt thẻ OTP............................................................................................................51
Hình 7-4. Mô hình triển khai thực hiện giải pháp............................................................................56
Hình 7-5. Kiến trúc triển khai giải pháp theo mô hình In-the-cloud................................................57
Hình 7-6. Kiến trúc triển khai giải pháp theo mô hình In-premise...................................................59
Hình 7-7. Giao diện về quản trị token của người dùng....................................................................62
Hình 7-8. Giao diện người dùng tự kích hoạt..................................................................................63
Hình 7-9. Giao diện người dùng tự kiểm tra thẻ token....................................................................64
Hình 7-10. Giao diện đồng bộ token................................................................................................64
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.....................66
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)............................................69
2
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 BẢNG
Bảng 5-1. Các ký hiệu......................................................................................................................19
Bảng 5-2. Các tiền tố......................................................................................................................19
Bảng 5-3. Bộ các ký tự.....................................................................................................................21
3
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
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àn
thương mại điện tử ở Việt Nam, đặc biệt là đối với một số ngân hàng. Đồ án
cũ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.
2.
3.
4.
5.
6.
7.
Giới thiệu về công nghệ USB Token
Các lĩnh vực ứng dụng của công nghệ USB Token
Một số bảng mã tham chiếu trong công nghệ USB Token
Một số định nghĩa được sử dụng
Các biểu tượng và chữ viết tắt
Miêu tả tổng quan về công nghệ USB Token
Ứng dụng công nghệ USB Token trong thương mại điện tử của
VeriSign
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
4
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
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ều
ngày càng rõ ràng là : để nó có được hiệu quả như các công nghệ cơ bản cho
phé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ực
hiện là do không mang nghĩa bảo đảm. Khả năng cộng tác đòi hỏi phải tuân
thủ 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ợp
cá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ẩn
kế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ốn
phầ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êu
chuẩ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ối
cù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ủa
cá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ột
5
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
tiêu chuẩn chính thức, RSA Laboratories tuyên bố từ bỏ "quyền sở hữu cao
nhấ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ến
Cụ thể ta sẽ tìm hiểu về
PKCS#11
6
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
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ện
cá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 đơn
giả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 cho
mộ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 cung
cấ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ập
Cryptoki đồng thời cam kết ràng buộc giữa Cryptoki và các ngôn ngữ lập
trì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ầm
tay.
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 đổi
giao diện ban đầu. Nó có thể là cơ chế bổ sung sẽ được công bố theo thời gian
trong 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).
7
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
Cryptoki được dự định dành cho các thiết bị mật mã học gắn liền với
một người sử dụng, do đó, một số tính năng mà có thể đính kèm được trong
một mục đích chung ban đầu được bỏ qua. Ví dụ, Cryptoki không có các biện
phá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ăng
hữ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.
8
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
CHƯƠNG III: MỘT SỐ BẢN MÃ THAM CHIẾU
ANSI C
ANSI/ISO. American National Standard for Programming Languages
– C. 1990.
ANSI X9.31
Accredited Standards Committee X9. Digital
Signatures
Using Reversible Public Key Cryptography for the Financial
Services Industry (rDSA). 1998.
ANSI X9.42
Accredited Standards Committee X9. Public Key Cryptography
for the Financial Services Industry: Agreement of Symmetric Keys
Using Discrete Logarithm Cryptography. 2003.
ANSI X9.62
Accredited Standards Committee X9. Public Key Cryptography
for the Financial Services Industry: The Elliptic Curve Digital
Signature Algorithm (ECDSA). 1998.
ANSI X9.63
Accredited Standards Committee X9. Public Key Cryptography
for the Financial Services Industry: Key Agreement and Key
Transport Using Elliptic Curve Cryptography. 2001.
CC/PP
W3C. Composite Capability/Preference Profiles (CC/PP):
Structure and Vocabularies. World Wide Web Consortium, January
2004. URL: />
CDPD
Ameritech Mobile Communications et al.
Cellular Digital Packet
Data System Specifications: Part 406: Airlink Security. 1993.
FIPS PUB 46–3 NIST. FIPS 46-3: Data Encryption Standard (DES). October 25,
1999. URL: />FIPS PUB 74
NIST. FIPS 74: Guidelines for Implementing and Using the NBS Data
Encryption
Standard.
April
1,
1981.
URL:
/>
9
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
FIPS PUB 81
NIST. FIPS 81: DES Modes of Operation. December 1980. URL:
/>
FIPS PUB 113
NIST.
FIPS 113: Computer Data Authentication. May 30, 1985.
URL: />FIPS PUB 180-2 NIST. FIPS 180-2: Secure Hash Standard. August 1, 2002. URL:
/>FIPS PUB 186-2 NIST. FIPS 186-2: Digital Signature Standard. January 27, 2000.
URL: />FIPS PUB 197
NIST. FIPS 197: Advanced Encryption Standard (AES). November
26, 2001. URL: />
FORTEZZA CIPG
NSA, Workstation Security Products.
FORTEZZA Cryptologic
Interface Programmers Guide, Revision 1.52. November 1995.
GCS-API
X/Open Company Ltd. Generic Cryptographic Service API (GCSAPI), 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 —
Integrated Circuit(s) with Contacts
Commands for Interchange. 1995.
Identification Cards —
— Part 4: Interindustry
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.
10
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
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.
ISO/IEC 9796-2 ISO. Information Technology — Security Techniques —
Digital Signature Scheme Giving Message Recovery — Part
2: Integer factorization based mechanisms. 2002.
Java MIDP
Java Community Process. Mobile Information Device Profile for Java
2 Micro Edition. November 2002. URL:
/>
MeT-PTD
MeT. MeT PTD Definition – Personal Trusted Device Definition,
Version 1.0, February 2003. URL:
PCMCIA
Personal Computer Memory Card International Association. PC Card
Standard, Release 2.1,. July 1993.
PKCS #1
RSA Laboratories. RSA Cryptography Standard. v2.1, June 14, 2002.
URL: />
PKCS #3
RSA Laboratories. Diffie-Hellman Key-Agreement Standard. v1.4,
November 1993. URL: />
PKCS #5
RSA Laboratories. Password-Based Encryption Standard. v2.0,
March 25, 1999. URL: />
PKCS #7
RSA Laboratories. Cryptographic Message Syntax Standard. v1.5,
November 1993. URL: />
11
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
7/index.html
PKCS #8
RSA Laboratories. Private-Key Information Syntax Standard. v1.2,
November 1993. URL: />
PKCS #11-C
RSA Laboratories. PKCS #11: Conformance Profile Specification,
October 2000. URL: />
PKCS #11-P
RSA Laboratories. PKCS #11 Profiles for mobile devices, June 2003.
URL: />
PKCS #12
RSA Laboratories. Personal Information Exchange Syntax Standard.
v1.0, June 1999. URL: />
RFC 1319
B. Kaliski. RFC 1319: The MD2 Message-Digest Algorithm. RSA
Laboratories, April 1992. URL: />
RFC 1321
R. Rivest. RFC 1321: The MD5 Message-Digest Algorithm. MIT
Laboratory for Computer Science and RSA Data Security, Inc., April
1992. URL: />
RFC 1421
J. Linn. RFC 1421: Privacy Enhancement for Internet
Electronic Mail: Part I: Message Encryption and Authentication
Procedures. IAB
IRTF PSRG, IETF PEM
WG,
February
1993. URL: />
RFC 2045
Freed, N., and N. Borenstein. RFC 2045: Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Message
Bodies. November 1996. URL: />
RFC 2246
T. Dierks & C. Allen. RFC 2246: The TLS Protocol Version 1.0.
Certicom, January 1999. URL: />
12
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
RFC 2279
F. Yergeau. RFC 2279: UTF-8, a transformation format of ISO 10646
Alis Technologies, January 1998. URL: />
RFC 2534
Masinter, L., Wing, D., Mutz, A., and K. Holtman. RFC 2534: Media
Features for Display, Print, and
Fax. March 1999. URL:
/>RFC 2630
R. Housley. RFC 2630: Cryptographic Message Syntax. June 1999.
URL: />
RFC 2743
J. Linn. RFC 2743: Generic Security Service Application
Program Interface Version 2, Update 1.
RSA
Laboratories,
January 2000. URL: />
RFC 2744
J. Wray. RFC 2744: Generic Security Services API Version 2:
C- bindings. Iris Associates, January 2000.
URL: />
SEC 1
Standards for Efficient Cryptography Group (SECG). Standards
for Efficient Cryptography (SEC) 1: Elliptic Curve Cryptography.
Version 1.0, September 20, 2000.
SEC 2
Standards for Efficient Cryptography Group (SECG). Standards
for Efficient Cryptography (SEC) 2: Recommended Elliptic
Curve Domain Parameters. Version 1.0, September 20, 2000.
TLS
IETF. RFC 2246: The TLS Protocol Version 1.0 . January 1999. URL:
/>
WIM
WAP. Wireless Identity Module. — WAP-260-WIM-20010712-a. July
2001. URL: />
WPKI
WAP. Wireless PKI. — WAP-217-WPKI-20010424-a. April 2001.
13
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
URL: />WTLS
WAP. Wireless Transport Layer Security Version — WAP-261-WTLS20010406-a. April 2001. URL: />
X.500
ITU-T. Information Technology — Open Systems Interconnection —
The Directory: Overview of Concepts, Models and Services. February
2001.
Identical to ISO/IEC 9594-1
X.509
ITU-T. Information Technology — Open Systems Interconnection
— The Directory: Public-key and Attribute Certificate Frameworks.
March 2000. Identical to ISO/IEC 9594-8
X.680
ITU-T. Information Technology — Abstract Syntax Notation One
(ASN.1): Specification of Basic Notation. July 2002.
Identical to ISO/IEC 8824-1
X.690
ITU-T. Information Technology — ASN.1 Encoding Rules:
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:
API
Application
Application programming interface.
Any computer program that calls the Cryptoki
interface.
14
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
ASN.1
Attribute
BATON
BER
Abstract Syntax Notation One, as defined in X.680.
A characteristic of an object.
MISSI’s BATON block cipher.
Basic Encoding Rules, as defined in X.690.
CAST
Entrust Technologies’ proprietary symmetric block
cipher.
CAST3
Entrust Technologies’ proprietary symmetric block
cipher.
CAST5
Another name for Entrust Technologies’
symmetric block cipher CAST128. CAST128 is
the preferred name.
CAST128
CBC
Entrust Technologies’ symmetric block cipher.
Cipher-Block Chaining mode, as defined in FIPS PUB
81
CDMF
Certificate
Commercial Data Masking Facility, a block
encipherment method specified by International
Business Machines Corporation and based on DES.
A signed message binding a subject name and a public
key, or a subject name and a set of attributes
CMS
Cryptographic Message Syntax (see RFC 2630)
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
software-only
15
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
Cryptoki
Cryptoki library
The Cryptographic Token Interface defined in this
standard.
A library that implements the functions specified in
this standard.
DER
Distinguished Encoding Rules, as defined in X.690.
DES
Data Encryption Standard, as defined in FIPS PUB 46-3
DSA
Digital Signature Algorithm, as defined in FIPS PUB
186-2
EC
ECB
ECDH
ECDSA
ECMQV
FASTHASH
IDEA
JUNIPER
KEA
LYNKS
MAC
Elliptic Curve
Electronic Codebook mode, as defined in FIPS PUB 81
Elliptic Curve Diffie-Hellman.
Elliptic Curve DSA, as in ANSI X9.62.
Elliptic Curve Menezes-Qu-Vanstone
MISSI’s FASTHASH message-digesting algorithm.
Ascom Systec’s symmetric block cipher.
MISSI’s JUNIPER block cipher.
MISSI’s Key Exchange Algorithm.
A smart card manufactured by SPYRUS.
Message Authentication Code.
MD2
RSA Security's MD2 message-digest algorithm, as
defined in RFC 1319.
MD5
RSA Security's MD5 message-digest algorithm, as
defined in RFC 1321.
Mechanism
A process for implementing a cryptographic operation.
16
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
MQV
Menezes-Qu-Vanstone
OAEP
Optimal Asymmetric Encryption Padding for RSA.
Object
An item that is stored on a token. May be data, a
certificate, or a key.
PIN
PKCS
PRF
Personal Identification Number.
Public-Key Cryptography Standards.
Pseudo random function.
PTD
Personal Trusted Device, as defined in MeT-PTD
RSA
The RSA public-key cryptosystem.
RC2
RSA Security’s RC2 symmetric block cipher.
RC4
RSA Security’s proprietary RC4 symmetric stream
cipher.
RC5
RSA Security’s RC5 symmetric block cipher.
Reader
The means by which information is exchanged with a
device.
Session
A logical connection between an application token.
SET
The Secure Electronic Transaction protocol.
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.
17
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
Slot
SKIPJACK
SSL
Subject Name
SO
A logical reader that potentially contains a token.
MISSI’s SKIPJACK block cipher.
The Secure Sockets Layer 3.0 protocol.
The X.500 distinguished name of the entity to which a
key is assigned.
A Security Officer user.
TLS
Transport Layer Security.
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.
WIM
Wireless Identification Module.
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 :
18
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
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ệu
sau :
/* 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 */
19
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
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_BYTE_PTR
CK_CHAR_PTR
CK_UTF8CHAR_PTR
CK_ULONG_PTR
CK_VOID_PTR
/* Pointer to a CK_BYTE
/* Pointer to a CK_CHAR
/* Pointer to a CK_UTF8CHAR
/* Pointer to a CK_ULONG
/* Pointer to a void */
*/
*/
*/
*/
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 :
NULL_PTR
/* A NULL pointer */
Đ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à đôi
khi có thể là 64 bit). Tuy nhiên, những chi tiết này không ảnh hưởng đến một
20
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
ứng dụng, giả sử nó được biên dịch với tập tin Cryptoki header phù hợp với
cá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ập
lụ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 String
củ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
21
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
lập (đúng) hoặc bỏ thiết lập (sai). Để thuận tiện, Cryptoki định nghĩa các
macro 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ày
củ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) :
#ifndef CK_DISABLE_TRUE_FALSE
#ifndef FALSE
#define FALSE CK_FALSE
#endif
#ifndef TRUE
#define TRUE CK_TRUE
#endif
#endif
22
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
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à đĩa
mềm thông minh là công cụ lý tưởng để thực hiện mật mã hóa khóa công
khai, vì chúng cung cấp một cách để lưu trữ các thành phần khóa bí mậtquan
trọ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ủa
mộ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êng
khô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ày
cà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 ứng
dụ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ên
thẻ 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ững
phươ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ủa
mộ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ương
tá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óm
tắ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ới
nhiều thiết bị tại một thời gian nhất định.
23
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
Đó 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ựng
một trong những hoạt động và dịch vụ với các chức năng mà Cryptoki cung
cấ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 Application
Programming Interface" (RFC 2743 và RFC 2744) và "Generic
Cryptographic 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ình
nà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ông
bá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ề
24
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
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ột
tập lệnh nào đó, các lệnh này thường được truyền qua các trình điều khiển
thiế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ết
nố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ần
thiết.
Cryptoki có khả năng được thực hiện như một thư viện hỗ trợ các chức
nă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ợp
nà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ể thay
thế 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ật
mậ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ện
lậ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ì
25
