1.3.2.1. Các giao din ng dng chu!n phía reader
Trước đây, không có một giao diện chuẩn nào cho reader (không phụ thuộc reader). Lí do rất đơn giản: không giống như thẻ, reader không có bất kỳ một chuẩn nào, do vậy mà giao diện giao tiếp với chúng cũng không tuân theo một chuẩn nào. Hầu hết các nhà sản xuất đều cố gắng đưa vào sản phẩm của mình những tính năng khác biệt nhằm cạnh tranh với đối thủ, hơn nữa hầu hết các hệ
thống triển khai ứng dụng Smart Card đều khép kín, nghĩa là với một kiểu reader và thẻ nhất định.
Tuy nhiên, tình hình hiện giờđã đổi khác: Smart Card ngày càng được ứng dụng rộng rãi và cộng đồng những người phát triển phần mềm cho Smart Card muốn xây dựng những ứng dụng mà chúng có thể hoạt động với bất kỳ loại reader và thẻ nào (hay ít nhất thì cũng là hầu hết các loại). Có rất nhiều cố gắng được đưa ra nhằm đạt tới điều này, tiêu biểu là PC/SC của Microsoft, Multos của MAOSCO và OpenCard Framework của IBM. Trong số này, đáng chú ý nhất là PC/SC của Microsoft, nó được coi là nền tảng được phân phối nhiều nhất hiện nay bởi một trong những công ty phần mềm hàng đầu thế giới. Ngoài những nền tảng với mục
đích chung như PC/SC còn có những chuẩn giao diện được đưa ra nhằm phục vụ
trong một số lĩnh vực cụ thể như thanh toán, mật mã… Bảng sau đây mô tả một số
Bảng 1-2 Các chuẩn giao diện ứng dụng (API)
API Nhà cung cấp Lĩnh vực
EMV’96 Europay, MasterCard, Visa Thanh toán
Đặc tả Visa ICC Visa Thanh toán
C-SET Europay Thanh toán
SET 2.0 Visa, MasterCard, Amex Thanh toán
Visa Open Platform Visa Thanh toán
Cryptographic API Microsoft Mã hóa
PKCS#11 RSA Mã hóa
Phần tiếp theo chúng ta sẽ xem xét một trong những chuẩn có nhiều hứa hẹn nhất hiện nay: chuẩn PC/SC.
1.3.2.2. Chu!n PC/SC
Khởi xướng và phát triển bởi hàng loạt các công ty tên tuổi như Apple, Gemplus, Hewlett-Packard, IBM, Microsoft, Philips, Schlumberger, Siemens, Toshiba, Sun Microsystems đứng đầu là Microsoft nhằm định nghĩa một kiến trúc chung nhằm kết hợp công nghệ Smart Card vào các hệ thống máy tính cá nhân.
Đặc tả cho kiến trúc này được đưa ra vào năm 1996 và được gọi là Interoperability Specification for ICCs and Personal Computer Systems thường được biết đến với cái tên PC/SC.
Tham vọng to lớn của PC/SC là nhằm đưa ra một đặc tả cho tất cả các hệ
thống Smart Card giúp cho các nhà sản xuất reader và các nhà sản xuất Smart Card tích hợp các sản phẩm của mình với nhau một cách dễ dàng, người phát triển
ứng dụng lúc này không phải quan tâm đến từng kiểu reader hay Smart Card khác nhau nữa, họ chỉ việc viết một ứng dụng tuân theo chuẩn PC/SC và nó sẽ chạy giống nhau trên bất kỳ hệ thống Smart Card nào.
1.3.2.3. Kin trúc PC/SC
Hình 1-10 thể hiện kiến trúc của PC/SC. Trong hình này ICC (Integrated Circuit Card) chỉ Smart Card, IFD (Interface Device) chỉ reader. Chúng ta sẽ xem xét khái quát một số thành phần của kiến trúc này.
IFD Handler
IFD Handler thường là một phần mềm mức thấp bên trong PC hỗ trợ kênh I/O nối IFD với PC và cho phép truy cập các chức năng của IFD.
ICC Resource Manager
Trình quản lí tài nguyên ICC là điểm mấu chốt trong toàn bộ kiến trúc của PC/SC. Nó chịu trách nhiệm quản lí các kiểu tài nguyên ICC nhằm hỗ trợ điều khiển giao tiếp với IFD và qua IFD tới từng kiểu ICC khác nhau. ICC Resource Manager được coi như thành phần mức hệ thống của toàn bộ kiến trúc không thể
thiếu được, mỗi một hệ thống chỉ có một ICC Resource Manager. ICC Resource Manager giải quyết 3 vấn đề sau đây.
Thứ nhất nó chịu trách nhiệm nhận dạng và kiểm soát tài nguyên, bao gồm: Kiểm soát các IFD đã cài đặt và đảm bảo các ứng dụng khác có thể lấy được những thông tin này
Kiểm soát các kiểu ICC cùng với Service Provider (sẽ nói sau) và các giao diện hỗ trợ tương ứng của chúng (adsbygoogle = window.adsbygoogle || []).push({});
Kiểm soát các sự kiện đưa và lấy thẻ ra khỏi IFD.
Hình 1-8 Kiến trúc PC/SC
Thứ hai, nó chịu trách nhiệm điều khiển và định vị các IFD và tài nguyên Thứ ba, nó hỗ trợ nguyên lí transaction (khái niệm tương tự trong cơ sở dữ
o Service Provider
Trình cung cấp dịch vụ chịu trách nhiệm cung cấp các chức năng của từng kiểu IFD và ICC cụ thể thông qua một giao diện lập trình bậc cao.
ICC Service Prodiver (ICCSP) hay ICCOS Service Provider (ICCOSSP): là giao diện cung cấp các chức năng của ICC hoặc hệđiều hành ICC.
Application Domain Service Provider (ADSP): là khái niệm xuất hiện trong đặc tả 2.0 cung cấp giao diện các chức năng của các ứng dụng trên thẻ của nhà sản xuất Smart Card. Trong đặc tả 1.0 các ICCSP được ánh xạ vào Resource Manager thông qua chuỗi ATR tuy nhiên với các loại Smart Card đa ứng dụng thì không thể làm như vậy. ADSP là giải pháp hỗ trợ Smart Card đa ứng dụng, nó dùng một cơ chếđộng thông qua trình định vị ADSP (ADSP Locator) và hệ thống nhận dạng thẻ mới.
Ngoài ra còn có một số Service Provider khác như Cryptographic Service Provider (cung cấp các chức năng mã hóa) và IFD Service Provider. Chi tiết về
các Service Provider này có thể tìm thấy trong đặc tả của PC/SC. Trong phần kế
tiếp chúng ta sẽ xem xét hai thành phần quan trọng nhất trong kiến trúc PC/SC và khía cạnh lập trình của chúng: Resource Manager và ICCSP.
1.3.2.4. ICC Resource Manager
o Quy ước gọi hàm
Các hàm quản lí của ICC Resource Manager đều được gọi theo mẫu sau (số
lượng tham số và kiểu của thamg số tùy thuộc vào từng hàm):
RESPONSECODE FunctionName( IN DWORD Parameter1, OUT BYTE Parameter2, IN OUT BYTE Parameter3 )
Trong đó RESPONSECODE là tập các giá trị được định nghĩa trước trả về
trạng thái thực sau khi thực hiên hàm (thành công hay thất bại…).
o Lớp RESOURCEMANAGER
Chức năng của lớp này là quản lí context: một context là một số định danh 32 bit bắt buộc phải được thiết lập, các hành động sau này đều phải dựa trên một context nào đó (khái niệm rất hay gặp trong lập trình Windows). Lớp này chỉ có hai hàm chính: thiết lập và hủy một context:
RESPONSECODE EstablishContext(...) // thiết lập context RESPONSECODE ReleaseContext() // hủy context
o Lớp RESOURCEDB
Một trong những chức năng của Resource Manager là quản lí tất cả các kiểu ICC, IFD và tài nguyên liên quan. Lớp RESOURCEDB mục đích là quản lí cơ sở dữ liệu tài nguyên này, nó cho phép thêm, xửa và xóa các ICC và IFD. Ngoài ra nó còn cho phép tạo thành các nhóm để dễ dàng quản lí. Lớp RESOURCEDB thừa kế trực tiếp từ lớp RESOURCEQUERY. Một số hàm cơ
bản của lớp này bao gồm:
RESPONSECODE IntroduceReader(...) // Thêm một reader mới vào CSDL RESPONSECODE ForgetReader(...) // Loại một reader ra khỏi CSDL RESPONSECODE IntroduceReaderGroup(...) // Tạo một nhóm mới RESPONSECODE ForgetReaderGroup(...) // Xóa một nhóm
RESPONSECODE AddReaderToGroup(...) // Thêm một reader vào một nhóm RESPONSECODE RemoveReaderFromGroup(...) // Loại reader ra khỏi nhóm RESPONSECODE IntroduceCardType(...) // Thêm một kiểu thẻ vào CSDL RESPONSECODE ForgetCardType(...) // Loại một kiểu thẻ khỏi CSDL
Chi tiết về các hàm này xem trong đặc tả phần 5 của PC/SC
o Lớp RESOURCEQUERY
Lớp này thực hiện công việc truy vấn tới CSDL, nó có các hàm trả về danh sách các reader, nhóm, kiểu thẻ...
Sau đây là một số hàm của lớp này:
RESPONSECODE ListReaderGroups(...) RESPONSECODE ListReaders(...) RESPONSECODE ListCardType(...) (adsbygoogle = window.adsbygoogle || []).push({});
RESPONSECODE GetProviderId(...) // Trả về ICCSP tương ứng với kiểu thẻ
RESPONSECODE ListInterfaces(...) // Trả về danh sách các số GUID giao diện
Chi tiết về lớp RESOURCEQUERY được miêu tả trong đặc tả phần 5 của PC/SC.
o Lớp SCARDTRACK
Lớp này đóng gói các hàm theo dõi sự có mặt (vắng mặt) của thẻ trong reader. Các hàm trong lớp này dùng một cấu trúc thông tin trạng thái
SCARD_READERSTATE lấy về trạng thái của reader. Hàm quan trọng nhất của lớp này là hàm LocateCard():
RESPONSECODE LocateCard(...) // trả về thông tin trạng thái của reader
Chi tiết về các hàm của lớp SCARDTRACK được miêu tả trong đặc tả
phần 5 của PC/SC.
o Lớp SCARDCOMM
Lớp này đóng gói các chức năng giao tiếp với reader và thẻ, nó cung cấp các hàm quản lí kết nối, điều khiển transaction, gửi và nhận dữ liệu, xác định trạng thái thẻ.
Chi tiết về các hàm khác và các tham số trong lớp SCARDCOMM được miêu tả chi tiết trong đặc tả phần 5 của PC/SC.
1.3.2.5. ICCSP
Các dịch vụ ICCSP cung cấp chia thành 3 mục: Dịch vụ File
Dịch vụ xác thực
Dịch vụ mã hóa
Các lớp SCARD, FILEACCESS, CHVERIFICATION, CARDAUTH, CRYPTPROV, CRYPTHASH và CRYPTKEY là các giao diện cung cấp các dịch vụ của ICC tương ứng với 3 mục trên. Lớp SCARD là lớp bắt buộc trong khi các lớp còn lại là tùy chọn và đối tượng của chúng thường được khởi tạo thông qua
đối tượng của lớp SCARD. Hình sau đây thể hiện quá trình tạo đối tượng của các
lớp này.
Hình 1-9 Các lớp giao diện
o Lớp SCARD
Lớp này định nghĩa một loạt các hàm giao tiếp với ICC, nó cũng chịu trách nhiệm quản lí context giao tiếp với ICC.
Các hàm sau đây tạo đối tượng các lớp còn lại:
RESPONSECODE CreateFileAccess(...) // Tạo một đối tượng FileAccess
RESPONSECODE CreateCHVerification(...) // Tạo một đối tượng CHVerification RESPONSECODE CreateCardAuth(...) // Tạo một đối tượng CardAuth
RESPONSECODE CreateCryptProv(...) // Tạo một đối tượng CryptProv
Một số hàm quan trọng khác của lớp SCARD:
RESPONSECODE AttachByHandle(...) //Chuyển một handle tới một context có sẵn RESPONSECODE AttechByIFD(...) // Tạo một context dựa vào reader
o Lớp FILEACCESS
Các chức năng làm việc với hệ thống file được triển khai trong lớp này. Nó cung cấp các hàm làm việc với thư mục (file DF), file EF (read, write, delete...)... Chi tiết các hàm này được miêu tảđầy đủ trong đặc tả phần 6 của PC/SC. (adsbygoogle = window.adsbygoogle || []).push({});
o Lớp CHVERIFICATION
Là lớp đóng gói các hàm liên quan tới việc kiểm thông qua mã PIN. Nó cung cấp các hàm Verify() kiểm tra PIN, hàm đổi PIN, hàm Unblock() “mở khóa” PIN... Chi tiết các hàm có thể xem trong đặc tả phần 6 của PC/SC.
o Lớp CARDAUTH và CRYPTPROV
Các lớp này triển khai các hàm thực hiện việc xác thực và mã hóa. Chi tiết các lớp này được miêu tả trong đặc tả phần 6 của PC/SC.
1.3.2.6. Các chu!n khác
o Multos
Multos là hệ điều hành Smart Card phát triển trong dự án Mondex. Giống như JavaCard nó hỗ trợ lập trình phía thẻ nhưng phát triển bằng C, đây cũng là
điểm mạnh của Multos.
o OpenCard Framework
Thiết lập bởi IBM cùng với Netscape, NCI và SUN, OpenCard Framework
được phát triển cùng thời điểm với PC/SC nhưng với mục đích tích hợp Smart Card vào hệ thống mạng máy tính.
o EMV’96
EMV được phát triển với mục đích mô tả một hệ thống xử lí thanh toán nhất quán giúp cho các nhà sản xuất phát triển các hệ thống phần cứng phục vụ
cho mục đích này. Các hệ thống thương mại điện tử xuất hiện và phát triển mạnh bắt buộc MasterCard và Visa bắt tay vào phát triển một chuẩn mới SET (Secured Electronic Transaction), EMV’96 giờđây được coi như tiền thân của SET.
o SET 2.0 và Visa Open Platform
SET 2.0 là phiên bản kế tiếp của SET với mục đích hỗ trợ triệt để Smart Card, có thể coi SET 2.0 là bước kế tiếp trong quá trình cải tiến EMV’96. Một phiên bản khác của SET là C-SET (Chip Secured Electronic Transaction) với mục
đích điều chỉnh SET cho phù hợp với luật pháp của Pháp. Visa Open Platform là bản sửa đổi dựa đặc tả JavaCard nhằm vào môi trường đa ứng dụng.
1.3.3. Ứng dụng phía thẻ
1.3.3.1. Các khía cnh trong phát trin ng dng
Phát triển ứng dụng chạy trên thẻ không đơn thuần như việc phát triển ứng dụng truyền thống. Người phát triển phải cân nhắc một loạt các vấn đề như phần cứng (dung lượng bộ nhớ, tốc độ xử lí…), bảo mật và truy cập file (PIN, mã hóa…) và thậm chí là cả khả năng bị ngắt điện đột ngột (do rút thẻ ra khỏi reader).
o Bộ nhớ
Bộ nhớ RAM trong Smart Card không được tính bằng đơn vị Mb hay Kb mà là byte. Thường thì những Smart Card có dung lượng bộ nhớ nhỏ nhất vào khoảng 128 byte, Smart Card có dung lượng bộ nhớ lớn vào khoảng 640 byte. Vì dung lượng RAM nhỏ như vậy nên vấn đề sử dụng sao cho hợp lí và hiệu quả nhất
được đặt lên hàng đầu (chưa kể một số vấn đề khác như quản lí stack), rất may, đa số các trình biên dịch đều hỗ trợ việc này rất đáng kể.
Một dạng bộ nhớ khác trong Smart Card là bộ nhớ không mất (Nonvolatile Memory: NVM). Bộ nhớ NVM phải được ghi theo khối cùng lúc 4, 16 byte hoặc nhiều hơn do đó khi tiến hành ghi một ô nhớ NVM nào đó, một loạt các ô nhớ bên cạnh cũng bịảnh hưởng theo. Mặc dù các thao tác ghi với bộ nhớ NVM trong suốt với người lập trình thông qua các hàm API nhưng hiểu rõ bản chất của vấn đề đôi khi vẫn giúp tránh được những sai lầm. Ngoài ra, mặc dù được quảng cáo là tồn tại rất lâu nhưng bộ nhớ NVM vẫn có thể bị “mòn”, thực tế cho thấy 10 năm là khoảng thời gian khá dài đối với một bộ nhớ NVM, do vậy, việc backup và bảo trì dữ liệu khi làm việc với bộ nhớ NVM cũng cần được cân nhắc.
o Ngắt điện đột ngột
Một “đặc tính” của hệ thống Smart Card là thẻ có thể được rút ra bất ngờ
và do đó nguồn điện bị ngắt đột ngột. Người lập trình phải cân nhắc các biện pháp bảo đảm tính toàn vẹn và nhất quán dữ liệu đểđối phó với tình huống như vậy. Có một số hệ điều hành Smart Card triển khai một cách tương tự như transaction trong cơ sở dữ liệu tuy nhiên số đó là rất ít, người lập trình không còn cách nào khác là phải tự mình viết mã đểđảm bảo tính toàn vẹn của dữ liệu.
o Biên dịch và nạp vào thẻ
Không như các phần mềm truyền thống khác, việc đưa một phần mềm chạy trên thẻ vào hoạt động và sử dụng khá phức tạp. Không phải người sử dụng Smart Card nào cũng sẵn sàng nạp vào thẻ của họ một phần mềm mới, thường thì người ta sử dụng kỹ thuật ký điện tửđể xác thực “lai lịch” của phần mềm. Một vấn đề
nữa phải cân nhắc là chương trình được viết ra liệu có hoàn toàn tương thích với nền tảng hệđiều hành của Smart Card hay không bởi đơn giản là chúng không có (adsbygoogle = window.adsbygoogle || []).push({});
1.3.3.2. Tp các hàm API
Một trong các chức năng của phần mềm chạy trên thẻ là giao tiếp với phần mềm phía reader để thực thi một chức năng nào đó. Trong giao tiếp này, phần mềm phía reader gửi tới thẻ một chỉ thị lệnh nào đó, phía thẻ sau khi nhận được chỉ thị sẽ dùng các lệnh tương ứng trong dịch vụ của mình và thực thi chúng. Các hàm giao tiếp ứng dụng API chính là tập các hàm gọi thực thi các giao diện lệnh tương ứng được gửi tới thẻ. Sau đây chúng ta sẽ xem xét một số API tiêu biểu.
o ISO 7816-4:
Tập lệnh ISO 7816-4 chuẩn bao gồm 18 lệnh nhưđã được mô tả trong phân loại thẻ:
ReadBinary(byte fileId, short offset, byte buffer[]) WriteBinary(byte fileId, short offset, byte buffer[]) UpdateBinary(byte fileId, short offset, byte buffer[]) EraseBinary(byte fileId, byte offset)
ReadRecord(byte record_number, byte mode, byte buffer[]) WriteRecord(byte record_number, byte mode, byte buffer[]) AppendRecord(byte record_number, byte mode, byte buffer[]) UpdateRecord(byte record_number, byte mode, byte buffer[]) GetData(short mode, byte buffer[])
PutData(short mode, byte buffer[])
SelectFile(byte mode, byte info, byte name[]) Verify(byte mode, byte key[])
InternalAuthenticate(byte algorithm, byte mode, byte challenge[]) ExternalAuthenticate(byte algorithm, byte mode, byte response[]) GetChallenge(byte challenge[])
ManageChannel(byte operation, byte channel_number) GetResponse(byte response[])
Envelope(byte buffer[])
Hiện nay trên thị trường dường như không có loại Smart Card nào triển khai đầy đủ tập lệnh ISO 7816-4, đa số chúng đều triển khai một tập con của tập lệnh này.
o GSM 11.14
SIM (Subscriber Interface Module) là một loại Smart Card gắn vào điện thoại di động GSM. Tổ chức ETSI của Châu Âu đã đưa ra rất nhiều chuẩn mô tả
SIM và giao tiếp giữa chúng và điện thoại di động GSM.
Không giống như giao tiếp giữa reader và thẻ như mô tả trong các phần trước đây, mã chạy trên SIM còn cho phép gọi một số dịch vụ của điện thoại di
động. Do vậy, mã chạy trên SIM được chia thành 2 mảng: một dành cho dịch vụ
trên SIM và một cho dịch vụ trên điện thoại. Tập API thứ nhất tương tự như ISO 7816-4, tập API thứ hai bao gồm một số lệnh cơ bản sau đây: