1.3.1. Phát triển ứng dụng cho Smart Card
Về cơ bản, người ta chia ứng dụng cho Smart Card thành 2 loại:
Ứng dụng chủ (host software): là kiểu ứng dụng chạy trên máy tính có kết nối tới Smart Card, kiểu ứng dụng này còn gọi là ứng dụng phía reader. Hiện nay, các
ứng dụng viết cho Smart Card phần lớn thuộc kiểu ứng dụng này. Ứng dụng phía reader thường được viết bằng một trong các ngôn ngữ bậc cao thường thấy như C, C++, Java, VB…và thường dùng các thư viện và điều khiển thiết bị (driver) thương mại của các hãng sản xuất Smart Card.
Ứng dụng phía thẻ: là ứng dụng chạy hoàn toàn trên thẻ. Chúng thường
được viết bằng một ngôn ngữ trung gian như Java (cho JavaCard), ngôn ngữ mức máy như Forth hoặc một ngôn ngữ bậc thấp như assembly. Ứng dụng kiểu này thường được dùng với mục đích tùy biến hoặc cải tiến tính năng của Smart Card hoặc dùng để kết hợp và hỗ trợ các ứng dụng phía reader để triển khai các tính năng mới.
1.3.1.1. Quy trình phát trin ng dng cho Smart Card
o Phát triển mặt nạ (Mask)
Chương trình lưu trên chip của Smart Card được gọi là mặt nạ (mask). Thuật ngữ này bắt nguồn từ việc một mẫu các bit được mạ vào thành phần silicon (ROM). Nếu chương trình được lưu trong ROM trong quá trình chế tạo thì nó
được gọi là mặt nạ cứng (hard mask). Chương trình được lưu trên bộ nhớ có thể
ghi được EPROM sau quá trình sản xuất được gọi là mặt nạ mềm (soft mask).
o Viết mã
Việc phát triển mã thường phải cân nhắc rất nhiều yếu tố như loại thẻ, dung lượng bộ nhớ nhỏ, tốc độ tính toán chậm... Thường mã được viết ra chỉ áp dụng cho một hoặc một số kiểu Smart Card nhất định.
o Giả lập chip
Giả lập chip giúp cho việc phát triển ứng dụng Smart Card trở nên dễ dàng, nhanh chóng và tiết kiệm hơn. Tuy có ưu điểm như vậy nhưng việc giả lập chip vẫn không hoàn toàn đảm bảo được phần mềm sẽ không có lỗi.
o Test
Đểđảm bảo chất lượng ứng dụng, các nhà sản xuất thường đưa ra một phần cứng đặc biệt tương ứng với từng loại sản phẩm. Phần cứng này có cấu tạo và chức năng giống hệt như một Smart Card thực sự nhưng nó cho phép theo dõi, can thiệp và chỉnh sửa chương trình chạy bên trong nó.
o Phân tích giao thức
Giao tiếp giữa reader và thẻ là giao tiếp qua kênh một chiều (half-duplex), tương tự như giao tiếp giữa một PC và một mạng máy tính, trong môi trường này, người ta có thể dễ dàng quan sát các bit dữ liệu được truyền qua lại giữa reader và thẻ. Điều này được tiền hành trong quá trình phân tích giao thức thông qua một trình phân tích giao thức.
1.3.1.2. Các công c phát trin ng dng cho Smart Card
Phát triển ứng dụng cho Smart Card-giống như phát triển ứng dụng truyền thống-cũng cần một loạt các công cụ và nền tảng hỗ trợ. Phần tiếp theo sẽ xem xét một loạt các công cụ và nền tảng cơ bản hỗ trợ việc phát triển ứng dụng cho Smart Card bao gồm từ các trình soạn thảo (editor), trình giả lập, gỡ rối cho tới các hàm giao diện lập trình (API).
o Công cụ cho ứng dụng phía đầu đọc thẻ (reader)
Thực tế là ứng dụng phía reader cũng đơn thuần là một ứng dụng truyền thống, chỉ có điều là nó sử dụng các công cụ, thư viện đặc biệt để làm việc với Smart Card (thông qua reader). Dưới đây, chúng ta sẽ xem xét một số công cụđặc biệt như vậy.
Smart Card SDK và các hàm giao diện ứng dụng (API)
Hiện nay, số lượng các Smart Card SDK là rất nhiều, một số trong chúng dựa vào một reader cụ thể. Đáng chú ý là PC/SC của Microsoft và OpenCard Framework của IBM.
1.3.1.3. Công c cho ng dng phía th o Trình biên dịch
Công cụ cơ bản không thể thiếu được khi phát triển các ứng dụng chạy hoàn toàn trên Smart Card là các trình biên dịch. Thường thì có 2 kiểu trình biên dịch như vậy, một ứng dụng có thể được viết bằng một ngôn ngữ cấp thấp như
assembly rồi dùng một trình dịch assembler để dịch hoặc có thể viết bằng một ngôn ngữ bậc cao (chẳng hạn như C) và dùng một trình biên dịch ngôn ngữ bậc cao để biên dịch chúng. Ưu điểm của kiểu thứ nhất là chương trình rất nhỏ gọn và chạy rất nhanh tuy nhiên ứng dụng thường chỉ chạy được trên một số loại Smart Card nhất định. Ưu điểm của kiểu thứ hai là ứng dụng có tính khả chuyển cao, thích hợp cho các ứng dụng thương mại.
o Trình giả lập và gỡ rối
Việc dùng trình giả lập khi phát triển ứng dụng chạy trên Smart Card giúp tiết kiệm được rất nhiều công sức và chi phí. Tuy nhiên, đôi khi ứng dụng chạy rất tốt trên trình giả lập nhưng lại gặp lỗi khi chạy trên card thật, lúc đó là lúc người ta sẽ dùng một trình test (có cấu tạo vật lý và logic hệt như một Smart Card thật nhưng cho phép theo dõi và can thiệp vào chương trình đang chạy).
o Hệđiều hành Smart Card (adsbygoogle = window.adsbygoogle || []).push({});
Trên thị trường hiện nay có rất nhiều hệ điều hành của các hãng sản xuất
đưa ra. Người ta có thể dựa trên các hệ điều hành này để phát triển một hệ điều hành riêng. Đáng chú ý trong số này là MULTOS của hãng Mondex. Ngoài ra ACOS của Advanced Card System (bộ AC-KIT của hãng được sử dụng khi tiến hành luận văn này) cũng là một trong những hệđiều hành Smart Card như vậy.
1.3.2. Ứng dụng phía thiết bịđọc thẻ (reader)
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 (adsbygoogle = window.adsbygoogle || []).push({});
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
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 (adsbygoogle = window.adsbygoogle || []).push({});
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(...)
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 (adsbygoogle = window.adsbygoogle || []).push({});
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.
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à