Phần này dành cho ngƣời sử dụng, ngƣời mua phần mềm.
Khi mua phần mềm A, họ đƣợc cung cấp
o Tập tin cài đặt phần mềm A
o Thiết bị USB Dongle
o Driver cho thiết bị USB Dongle
Các thiết lập:
o Cài đặt phần mềm A
o Cài driver cho thiết bị lên máy tính (cho lần đầu tiên sử dụng)
Gắn USB Dongle vào máy tính và sử dụng phần mềm. Hệ thống sẽ tự động kiểm tra thiết bị có trên máy tính hay không. Trong quá trình đang sử dụng phần mềm A, nếu không phát hiện USB Dongle chƣơng trình sẽ bị khóa.
8.4. Các tính năng ngăn chặn việc phá khóa
Các yếu tố bảo vệ chống phá khóa, những yếu tố này gây trở ngại không nhỏ đến các cracker khi tiến hành can thiệp bẻ khóa phần mềm:
1. Tấn công qua phần mềm:
a. Không biết format lệnh trao đổi
b. Không biết cách xác thực license khi nhận đƣợc c. Không biết cách parse khóa từ serial Number d. Mỗi thiết bị có khóa mã hóa khác nhau 2. Tấn công qua phần cứng: làm giả thiết bị
9 Trình bày ở mục 6.4
100
a. Không có chuỗi License
b. Không biết cách parse khóa từ serial Number c. Không biết format lệnh trao đổi
d. Chip có cơ chế code read protection, nên không thể đọc vùng thông tin của chip
3. Capture dữ liệu truyền ( Man in the middle) a. Dữ liệu bị mã hóa, không hiểu đƣợc
b. Hệ thống có xử lý checksum nên việc thay đổi nội dung sẽ bị phát hiện c. Không biết format lệnh trao đổi để phân tích
d. Mỗi USB Dongle có khóa mã hóa khác nhau, bên cạnh đó các chuỗi thông tin chứng thực qua lại thay đổi theo thời gian, không có qui tắc nào nên việc capture sẽ gây khó hiểu và không tính toán đƣợc.
8.5. Cơ chế bảo vệ
Về phần mềm:
Giao tiếp có mã hóa AES, hàm băm, check sum, phát sinh chuỗi ngẫu nhiên thay đổi liên tục, độ dài chuỗi cũng thay đổi, không cố định.
Về phần cứng:
Cơ chế bảo vệ thiết bị code read protection, đặc trƣng của dòng chip LPC của NXP: cơ chế cho phép xác lập những mức bảo mật trong hệ thống để việc truy cập vào vùng Flash trên chip và sử dùng ISP bị ngăn cấm. 0x000001FC là vị trí địa chỉ trong Flash để ghi vào những giá trị đặc biệt thực hiện việc này. Ta có 3 chế độ sau:
Tên Dạng Mô tả
CRP1 0x12345678 Truy cập vào chip thông qua JTAG bị khóa. Chỉ cho phép cập nhật xuống một phần của vùng Flash qua lệnh ISP. Cụ thể:
Không thể truy cập vùng RAM thấp hơn địa chỉ 0x4000 0200
101 Không thể copy RAM vào vùng Sector 0 của Flash (adsbygoogle = window.adsbygoogle || []).push({});
Lệnh xóa sector 0 chỉ đƣợc thực hiện khi xóa luôn hết tất cả các Sector
Lệnh so sánh bị khóa
CRP2 0x87654321 Truy cập vào chip thông qua JTAG và các lệnh ISP sau không còn hiệu lực:
Đọc/ghi bộ nhớ
Lệnh Go, Copy, So sánh
CRP3 0x43218765 Là chế độ bảo vệ cao nhất, bao gồm các ngăn cấm trên.
CRP3 đƣợc bật khi firmware đã chắc chắn và thiết bị đƣợc triển khai sử dụng.
Bảng 8–1: Bảng ghi chú các cơ chế bảo mật của dòng LPC
8.6. Đánh giá
Chƣơng trình chạy ổn định, không phát sinh lỗi hay treo máy, đƣợc kiểm tra trên cả WinXP và Win7, đƣợc thực hiện thông qua các test case sau:
Test Case ID
Test Case
Description Expected Result Actual Result
Test Result
1
Phần mềm chạy khởi động khi USB Dongle đã đƣợc cắm
Phần mềm phát hiện và chứng thực thành công với USB Dongle --> Phần mềm đƣợc cho phép chạy bình thƣờng Phần mềm đƣợc cho phép chạy bình thƣờng Pass 2 Phần mềm chạy khởi động khi USB Dongle không đƣợc cắm
Phần mềm không phát hiện USB Dongle --> Báo lỗi, phần mềm không đƣợc phép sử dụng
Báo lỗi, phần mềm
không sử dụng đƣợc Pass
3
Khi phần mềm đang chạy, rút USB Dongle ra
Phần mềm không phát hiện USB Dongle --> Báo lỗi, phần mềm bị khóa, không sử dụng đƣợc Báo lỗi, phần mềm bị khóa, không sử dụng đƣợc Pass 4 Phần mềm bị khóa theo Test Case ID 2, ngƣời
Phần mềm không phát hiện USB Dongle --> Báo lỗi, phần mềm
Báo lỗi, phần mềm
102
dùng Retry lại nhiều lần nhƣng USB Dongle vẫn không đƣợc cắm
không đƣợc phép sử dụng
5
Phần mềm bị khóa theo Test Case ID 2, gắn USB Dongle vào (adsbygoogle = window.adsbygoogle || []).push({});
Phần mềm phát hiện và chứng thực thành công với USB Dongle --> Phần mềm đƣợc cho phép chạy bình thƣờng Phần mềm đƣợc cho phép chạy bình thƣờng Pass 6 Phần mềm bị khóa theo Test Case ID 3, ngƣời dùng Retry lại nhiều lần nhƣng USB Dongle vẫn không đƣợc cắm
Phần mềm không phát hiện USB Dongle --> Báo lỗi, phần mềm không đƣợc phép sử dụng
Báo lỗi, phần mềm
không sử dụng đƣợc Pass
7
Phần mềm bị khóa theo Test Case ID 3, gắn lại USB Dongle
Phần mềm phát hiện và chứng thực thành công với USB Dongle --> Phần mềm đƣợc cho phép chạy bình thƣờng Phần mềm đƣợc cho phép chạy bình thƣờng Pass 8
Làm lại tất cả các test case
trên cả trăm lần Nhƣ mong muốn ở trên
Đúng kết quả mong
muốn Pass
9
Chạy phần mềm test trên
WIN XP OK OK Pass
10
Chạy phần mềm test trên
WIN 7 OK OK Pass
11
Chay thử phần mềm có chứng thực USB Dongle trong 24 giờ liên tục
OK OK Pass
103
CHƢƠNG 9:
Tổng kết, đánh giá những kết quả đạt được và hướng phát triển trong tương lai
9.1. Kết quả đạt đƣợc
Nhóm đã hoàn thành việc thiết kế và xây dựng thiết bị USB Dongle dựa trên hai chip chính là LPC2103 và FT232R. Kiến trúc hệ thống đƣợc trình bày trong chƣơng 6 đƣợc hiện thực hóa, đƣợc cài đặt thành công và thực nghiệm. Nhƣ mục tiêu đề ra, nhóm có sản phẩm là thiết bị USB Dongle và có cung cấp các hàm thƣ viện xem nhƣ là bộ công cụ phát triển hệ thống bên cạnh là phần mềm mẫu để demo việc chứng thực.
Nhóm đã hoàn thành các nội dung nhƣ đăng kí.
STT Các nội dung, công việc
chủ yếu cần đƣợc thực hiện Nội dung
Phần trình bày tƣơng ứng
01 Nghiên cứu chuẩn USB 2.0 Tài liệu, báo cáo Chƣơng 1, chƣơng 2 (adsbygoogle = window.adsbygoogle || []).push({});
02 Nghiên cứu phƣơng pháp mã hóa khóa để tích hợp vào thiết bị USB Dongle
Tài liệu, báo cáo Chƣơng 4, chƣơng 6
03 Thiết kế phần cứng Thiết bị Chƣơng 5
04 Xây dựng driver cho USB Dongle Báo cáo, cài đặt Chƣơng 5, chƣơng 6
05 Xây dựng firmware cho USB Dongle Cài đặt Chƣơng 6, chƣơng 7
06 Xây dựng công cụ hỗ trợ phát triển SDK Cài đặt Chƣơng 6, chƣơng 7 07 Xây dựng một phần mềm mẫu chạy trên
PC để nhận USB Dongle nhằm chứng thực phần mềm có bản quyền.
104
08 Kiểm thử và triển khai thử nghiệm. Quy trình kiểm thử, tài liệu báo cáo
Chƣơng 8
Sản phẩm kết quả yêu cầu
ST
T Tên sản phẩm Kết quả
01 Thiết bị USB Dongle Lƣu trữ khóa đƣợc mã hóa để sử dụng phần mềm, nhằm chứng thực phần mềm đƣợc sử dụng hợp pháp, có đăng ký.
Driver trên WinXP, Vista, Windows 7 để máy tính nhận đƣợc thiết bị USB Dongle. Đạt 02 trợ SDK /C++/.Net Đƣợc đóng gói, dễ cài đặt. Đạt
Lẽ dĩ nhiên, phƣơng pháp bảo vệ nào cũng khó có thể đƣợc coi là hoàn hảo, là không thể bị bẻ khóa. Trên tinh thần theo giả định việc bẻ khóa phần mềm nhƣ tìm cây kim trong đống rơm, vấn đề ở đây là chúng ta cố gắng làm sao để cây kim đƣợc ẩn núp sâu và đống rơm phải phức tạp để làm hạn chế và nản lòng những kẻ muốn bẻ khóa phần mềm với mục đích dùng miễn phí. Với cách tiếp cận của nhóm theo hƣớng xử lý cả phần mềm và phần cứng, phần nào giúp ―đống rơm‖ phức tạp hơn.
105
9.2. Hƣớng phát triển
:
Phát triển USB dongle cho hệ thống mạng, nghĩa là nếu chạy gắn USB vào một Server thì ứng dụng cũng có thể hoạt động tốt trên các máy client.
Phát triển theo một giao thức chuẩn, chung trên phạm vi toàn thế giới, nhằm mục đích giải quyết trƣờng hợp hạn hữu, phần mềm A đang đƣợc thiết kế bảo vệ theo thiết bị USB Dongle của một hãng X nào đó muốn chuyển sang dùng thiết bị USB Dongle của một hang Y khác, giúp các nhà phát triển phần mềm dễ dàng trong việc chuyển đổi.
Nhóm luôn muốn nhận những đóng góp, chia sẻ từ các chuyên gia để có những cách thức, mô hình giải pháp tân tiến hơn.
106 [1] Chung Quang Khánh, Nguyễn Thị Cẩm Loan, "Nghiên cứu và xây dựng USB Host Stack cho hệ thống
nhúng ARM7," Tp. Hồ Chí Minh, 2009.
[2] Dân trí. Vi phạm bản quyền phần mềm. [Online]. http://dantri.com.vn/c25/s119-486007/vi-pham-
ban-quyen-phan-mem-giam-so-luong-tang-gia-tri.htm
[3] Business Software Alliance. (2011) BSA Global Software Piracy Study. [Online]. http://portal.bsa.org/globalpiracy2010/
[4] founded by Philips NXP, LPC2101/02/03 User manual., May 2009.
[5] FTDI, FT232R USB UART IC Datasheet Version 2.09.: Future Technology Devices International Ltd, 2010.
[6] Wikipedia. Advanced Encryprion Standard. [Online]. http://vi.wikipedia.org/wiki/AES (adsbygoogle = window.adsbygoogle || []).push({});
[7] Wikipedia. Message Digest Algorithm 5. [Online]. http://vi.wikipedia.org/wiki/MD5
[8] Wikipedia. Globally Unique Identifier. [Online].
http://en.wikipedia.org/wiki/http://en.wikipedia.org/wiki/Globally_unique_identifier [9] FTDI, FTChipID Programmer's Guide.: Future Technology Devices International Ltd, 2006.
[10] FTDI, Software Application Development, D2XX Programmer's Guide.: Future Technology Devices International Ltd, 2011.
[11] I.J. Jozwiak and K. Marczak, "A Hardware-Based Software Protection Systems - Analysis of Security Dongles with Time Meters," Szklarska , June 2007.
[12] Pavol Cerven, Crackproof Your Software. San Francisco: No Starch Press, Inc., 2002.
[13] Min Chen, "Software Product Protection," 2001.
[14] OZ SHY, JACQUES-FRANCOIS THISSE, "A Strategic Approach to Software Protection," 1999.
[15] Petar Djekic , Claudia Loebbecke, "Preventing application software piracy: An empirical investigation of technical copy protections," 2007.
107 [17] Nguyễn Đình Thúc, Bùi Doãn Khánh, Mã hóa và mật mã.
108
: Driver và các khái niệm liên quan
1. Driver là gì?
Driver trong thực tế thƣờng đƣợc hiểu là bộ phận dùng để điều khiển và giao tiếp giữa ứng dụng và thiết bị thông qua hệ điều hành (Windows).
Hình 0-1 – Mô hình giao tiếp Driver và thiết bị
Driver thƣờng vận hành giống nhƣ các dịch vụ trên hệ thống. Chẳng hạn nhƣ:
Chạy ẩn trong hệ thống, tách biệt với tiến trình của ứng dụng, và có thể đƣợc truy cập bởi nhiều ngƣời dùng.
Có chu kỳ sống lâu dài.
Driver có chu kỳ sống bằng với thiết bị. Driver đƣợc khởi động khi Windows phát hiện ra một thiết bị mới đƣợc gắn vào và driver sẽ đƣợc tắt đi khi thiết bị đƣợc rút ra. Hồi đáp các yêu cầu truy xuất I/O (Input/Output) từ bên ngoài.
Các yêu cầu truy xuất thƣờng đƣợc tạo ra bởi các ứng dụng từ Windows, hoặc thỉnh thoảng bởi các driver khác.
Không có giao diện ngƣời dùng.
Ngƣời dùng thƣờng tƣơng tác với driver bằng cách trực tiếp dùng các ứng dụng để tạo ra các lệnh yêu cầu truy xuất I/O.
Driver đƣợc thực thi trong một không gian địa chỉ khác với địa chỉ của ứng dụng tạo ra các lệnh yêu cầu truy xuất I/O.
109 Giao tiếp giữa dịch vụ của nhân hệ điều hành Windows và thiết bị thông qua các giao diện lập trình đặc biệt đƣợc gọi là DDI.
Các driver đều dựa vào các mô hình truy xuất I/O của Windows, chúng khác với các mô hình truy xuất mà ứng dụng và các dịch vụ thƣờng dùng.
Các driver có thể giao tiếp trực tiếp với các thành phần khác trong kernel.
Các driver kernel-mode thƣờng chạy toàn bộ trong chế độ kernel của nhân hệ điều hành. Còn driver UMDF phải giao tiếp với một driver kernel-mode bên dƣới mới có thể vận chuyễn đƣợc dữ liệu vào ra thiết bị.
2. Khái quát về WDM và WDF
WDM – Windows Driver Model, đƣợc xem là một mô hình, một bộ khung phát triển driver do Microsoft phát triển dành riêng cho hệ điều hành Windows.
WDF – Windows Driver Foundation là tập hợp các công cụ và mô hình thiết kế driver của Microsoft và đƣợc kế thừa lại từ WDM, và đƣợc xem là đứa con của WDM. Hiện nay, Microsoft đã release bản WDF 1.7 và kèm theo đó là bộ công cụ phát triển Driver (adsbygoogle = window.adsbygoogle || []).push({});
Windows Driver Kit do chính hãng cung cấp.
Hình 0-2 – Mô hình phát triển Driver của Windows
Để có thể hiểu đƣợc chính xác các khái niệm một cách xuyên suốt trong quá trình thiết kế Driver, cần phải lƣu ý 2 vấn đề cơ bản sau:
110 WDF đƣợc thiết kế dựa trên mô hình driver sơ khai ban đầu, đó là WDM, bằng cách WDF tạo nên các lớp trừu tƣợng và đóng gói lại thành các đối tƣợng. Do đó, để hiểu đƣợc WDF, chúng ta cần phải nắm rõ một số định nghĩa từ WDM.
Ở mức trừu tƣợng, các driver WDF và WDM có cùng một cấu trúc và điều khiển các lệnh truy xuất dữ liệu nhƣ nhau. Hầu hết các phần thảo luận trong các phần sau đều áp dụng đƣợc cho cả WDF và WDM, chỉ có phần cài đặt là có sự khác biệt.
WDF là một mô hình theo đối tƣợng (object model), nhƣ đối tƣợng Driver (Driver Object), đối tƣợng thiết bị (Device Object), bộ nhớ, v.v…Nghĩa là việc lập trình driver trên WDF hầu hết chủ yếu thông qua các đối tƣợng. Đồng thời, các đối tƣợng trong WDF đều có sự kế thừa, do đó, nếu cần ta có thể kế thừa và tạo ra các đối tƣợng mới tùy vào nhu cầu của thiết bị cần cung cấp những chức năng và yếu tố vật lý nhƣ thế nào.
Mỗi đối tƣợng trong WDF đều có các thuộc tính, phƣơng thức, sự kiện và chu kỳ sống riêng của đối tƣợng, trong đó:
Thuộc tính: Đƣợc xem nhƣ là các đặc điểm mô tả về đối tƣợng.
Phƣơng thức: Các phƣơng thức thực hiện trên chính đối tƣợng hay thực hiện trực tiếp lên các đối tƣợng khác.
Sự kiện: Sự kiện là các xử lý biến cố mà driver WDF chọn ra để thực hiện xử lý biến cố khi sự kiện đó đƣợc xảy ra. Trong driver KMDF, đó là các hàm sự kiện callback. Ví dụ nhƣ việc tạo ra đối tƣợng Driver hay các sự kiện thay đổi nguồn cung cho thiết bị sẽ làm phát sinh ra các biến cố của sự kiện và ta có thể cài đặt các xử lý biến cố đó (nếu cần).
Mô hình WDF cung cấp hầu hết các loại mô hình driver cho một lƣợng lớn các loại thiết bị hiện nay. Tuy nhiên, nhìn chung WDF cũng chỉ có 2 dạng Framework cơ bản dùng cho việc phát triển driver, đó là:
UMDF – User-Mode Driver Framework. KMDF – Kernel-Mode Driver Framework.
Thông thƣờng, khi tiến hành thiết kế Driver cho một loại thiết bị, đứng ở góc độ ngƣời phát triển driver, ta thƣờng chọn Driver KMDF, vì nó cho phép ta can thiệp và xử lý ở mức độ kernel, mức nhân hệ thống, đồng thời việc can thiệp và giao tiếp với phần cứng sẽ tốt hơn.
111 Trong phần sau, khi đề cập đến Driver, chúng tôi chỉ đề cập trọng tâm chủ yếu vào Driver dạng KMDF.
3. Kiến trúc WDF
Do WDF là một mô hình theo đối tƣợng, do đó kiến trúc WDF cũng là một kiến trúc theo đối tƣợng và có dạng phân tầng. Nhìn chung, WDF có 5 tầng đối tƣợng cơ bản.
Hình 0-3 – Kiến trúc WDF Applications
Ứng dụng thông thƣờng có một handle thiết bị và gọi các hàm Windows API tƣơng ứng để gửi các lệnh request tới thiết bị. Ứng dụng hầu nhƣ không biết và không cần biết là nó đang giao tiếp với một driver WDM hay WDF.
Kernel Subsystems
Bao gồm bộ phận quản lý nhập xuất (I/O manager), bộ phận quản lý Plug and Play (PnP manager), v.v….Kernel subsystem có thể đƣợc xem nhƣ là một dịch vụ của hệ thống. Kernel Subsystem sẽ nhận các lệnh request từ ứng dụng và đóng gói thành các IRPs và dùng nó để giao tiếp với framework. Khi các request từ ứng dụng đƣợc hoàn tất, từ đây, kernel subsystem sẽ gửi trả kết quả về cho ứng dụng
112
The Framework's Upper Edge
Góc trên của framwork đƣợc xem nhƣ là một lớp trừu tƣợng giữa Windows và Driver.