thiết kế xây dựng thiết bị usb dongle - bảo vệ phần mềm có bản quyền

Control transfer Setup stage Token packet Data packet Handshakepacket Data stage Status stage Setup transaction transactionsData transactionStatus Hình 1-7 Các thành phần cơ bản trong C

TP HỒ CHÍ MINH TP HỒ CHÍ MINH

CHƯƠNG TRÌNH VƯỜN ƯƠM SÁNG TẠO KHOA HỌC VÀ CÔNG NGHỆ TRẺ

Chủ nhiệm đề tài: TRẦN NGUYÊN ĐẠI HÃN

Cơ quan chủ trì: TRUNG TÂM PHÁT TRIỂN

KHOA HỌC VÀ CÔNG NGHỆ TRẺ

TP Hồ Chí Minh, tháng 10 năm 2011

TÓM TẮT NỘI DUNG NGHIÊN CỨU

Không chỉ ở các nước đang phát triển mà cả các nước phát triển, tình trạng vi phạm bản quyền phần mềm máy tính đều rất phổ biến Hiện tại, đây đang là thực tế nhức nhối ở Việt Nam

Phần mềm ra đời và để bảo hộ các quyền của tác giả, chủ sở hữu của nó; do đó cần có một giải pháp hợp lý và khả thi để hạn chế việc xâm phạm và sử dụng những phần mềm không có đăng ký Qua đó mới khuyến khích việc phát triển phần mềm, tạo

sự yên tâm trong việc sử dụng phần mềm hợp pháp, bản quyền phần mềm phải được tôn trọng và thực thi để thúc đẩy sự phát triển xã hội và công nghệ

Với sự phát triển ngày càng nhanh chóng của công nghệ thông tin như hiện nay thì nhu cầu bảo vệ các sản phẩm phần mềm, những sản phẩm trí tuệ ngày càng được quan tâm và có ý nghĩa hết sức quan trọng

Việc ứng dụng hệ thống nhúng trong bảo vệ sử dụng phần mềm có bản quyền là một trong những hướng mới vào thời điểm hiện tại Một thiết bị được sản xuất tương thích để đảm bảo rằng khi có nó tích hợp vào thì phần mềm sẽ được đăng ký và sử dụng hợp pháp

Từ những tính cấp thiết và ý nghĩa nêu trên, đề tài ―Thiết kế và xây dựng thiết bị USB Dongle – bảo vệ phần mềm có bản quyền‖ đã được nhóm xây dựng, có chức năng chứng thực quyền sử dụng các phần mềm có bản quyền

SUMMARY OF RESEARCH CONTENT

Not only in the developing countries, developed countries included, the situation pirated computer software were very popular Currently, this is a really problem in Vietnam

To protect the rights of copyright owners of it We need a reasonable solution and feasible to limit the infringement of licensed software Thereby encouraging the development of new software, creating peace of mind in the use of legitimate software, software copyrights should be respected and implemented to promote social development and technology

Today, with the increasingly development of information technology, the need to protect the software product, the brainchild growing interest and of paramount importance

The application of embedded systems in the protection of software copyright is one of the new direction in the present time A device made compatible to ensure that when it is integrated into the software will be registered and used legally

From the urgency and the sense mentioned above, the project "Design and construction equipment USB Dongle - protect software copyright" was team building, for the right to use the software All rights reserved

Lời nói đầu

Thành phố Hồ Chí Minh đang chuyển mình mạnh mẽ trong sự nghiệp công nghiệp hóa, hiện đại hóa, vấn đề đặt ra là phải xây dựng một nguồn nhân lực trẻ có kiến thức và kỹ năng cao về khoa học công nghệ, vừa tìm tòi nghiên cứu – sáng tạo vừa mở rộng ứng dụng – triển khai

Chương trình Vườn Ươm Sáng tạo khoa học kỹ thuật trẻ đã ra đời, mở ra cơ hội mới cho đội ngũ sáng tạo trẻ được góp măt vào hoạt động khoa học công nghệ cùng các bậc chuyên gia giỏi và giàu kinh nghiệm và tạo ra môi trường để những nhà khoa học trẻ phát huy tối đa năng lực sáng tạo

Nhờ chương trình Vườn Ươm này, mà nhóm có cơ hội mạnh dạn tham gia và thử thách mình để thực hiện một đề tài nghiên cứu Nhóm xin chân thành cảm ơn Sở KHCN Tp.HCM và Thành đoàn Tp.HCM đã tạo điều kiện đầu tư tốt nhất để nhóm hoàn thành đề tài Cám ơn các Thầy/Cô trong hội đồng đánh giá đã có nhiều góp ý và cung cấp tư liệu tham khảo Cám ơn các bạn thành viên của nhóm và SELab đã nhiệt tình làm việc trong 01 năm qua để đạt kết quả tốt nhất

Tp.HCM, ngày 10 tháng 10 năm 2011

Chủ nhiệm đề tài

Trần Nguyên Đại Hãn

Trung tâm phát triển khoa học và công nghệ trẻ

Thời gian thực hiện đề tài:

Từ 07/2010 đến 10/2011

Mục tiêu: (theo đề cương đã được duyệt)

Nhằm hạn chế cũng như khắc phục tình trạng các phần mềm bị bẻ khóa Việc xây dựng USB Dongle như là một giải pháp nhằm mang lại cho những nhà sản xuất phần mềm một hướng tiếp cận về bảo mật, bảo vệ sản phầm của mình trong việc sử dụng bất hợp pháp

Đề tài nghiên cứu thiết kế và xây dựng kiểm thử thiết bị USB Dongle hoàn chỉnh, gồm có:

Thiết bị USB Dongle

ụ hỗ trợ SDK

Nội dung: (theo đề cương đã được duyệt)

1 Nghiên cứu chuẩn USB 2.0

2 Nghiên cứu phương pháp mã hóa khóa để tích hợp vào thiết bị USB Dongle

3 Xây dựng driver cho USB Dongle

4 Xây dựng firmware cho USB Dongle

5 Xây dựng công cụ hỗ trợ phát triển SDK - tương tác đọc USB Dongle lấy lên thông tin định danh để đăng kí sử dụng cho ứng dụng phần mềm cần chứng thực

6 Phần mềm mẫu chạy trên PC có sử dụng USB dongle làm bảo vệ chống sử dụng trái phép nếu không đăng kí

7 Kiểm thử và triển khai thử nghiệm

TT Các nội dung, công việc

chủ yếu cần được thực hiện

Phần trình bày tương

ứng

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

04 Xây dựng driver cho USB Dongle Báo cáo, cài đặt

05 Xây dựng firmware cho USB Dongle Cài đặt

06 Xây dựng công cụ hỗ trợ phát triển SDK Cài đặt

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

Cài đặt

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

Danh sách các cán bộ tham gia thực hiện đề tài:

STT Tên tổ chức, cá nhân Cơ quan

công tác

Nội dung công việc tham gia

Mục lục

TÓM TẮT NỘI DUNG NGHIÊN CỨU 3

SUMMARY OF RESEARCH CONTENT 4

Lời nói đầu 5

Mục tiêu: (theo đề cương đã được duyệt) 7

Nội dung: (theo đề cương đã được duyệt) 7

Mục lục 10

Danh sách các hình 13

Danh sách các bảng 16

Danh sách chữ viết tắt 18

CHƯƠNG 1: 19

1.1 Giới thiệu về các chuẩn USB (1) 19

1.2 Đặc trưng cơ bản 20

1.3 Phương thức truyền dữ liệu 23

1.3.1 Các kiểu truyền dữ liệu 23

1.3.2 Cấu trúc lưu trữ các Packet 34

1.4 Các loại Request chuẩn 36

1.4.1 Get_Status 37

1.4.2 Set_Feature 38

1.4.3 Clear_Feature 39

1.4.4 Set_Address 40

1.4.5 Get_Descriptor 41

1.4.6 Set_Descriptor 42

1.4.7 Get_Configuration 42

1.4.8 Set_Configuraion 43

1.4.9 Get_Interface 43

1.4.10 Set_Interface 44

1.4.11 Synch_Frame 44

1.5 Các loại Descriptor chuẩn 44

1.6 Cấu trúc lưu trữ các Descriptor 46

1.6.1 Device descriptor 46

1.6.2 Configuration descriptor 48

1.6.3 Interface descriptor 49

1.6.4 Endpoint descriptor 50

1.6.5 String descriptor 51

CHƯƠNG 2 52

2.1 Sơ đồ tổng quát (1) 52

2.2 Endpoint Descriptor 53

2.3 Transfer Descriptor 54

2.3.1 General TD 54

2.3.2 Isochronous TD 56

2.3.3 Completion Codes 58

2.4 Frame 59

2.5 Liệt kê thiết bị 59

61

61

62

63

65

CHƯƠNG 4: CÁC PHƯƠNG PHÁP BẢO VỆ PHẦN MỀM 67

4.1 Khái quát 67

4.2 Các phương pháp thường dùng 67

4.2.1 Dùng chuỗi serial key 67

4.2.2 Giới hạn thời gian sử dụng 68

4.2.3 Hạn chế tính năng, điều kiện sử dụng 69

4.2.4 Dùng tập tin đăng kí 70

4.2.5 Chống sao chép phần mềm từ đĩa CD 70

4.2.6 Bảo vệ bằng khóa cứng 71

72

72

5.1.1 Dongle là gì? 72

5.1.2 Lợi ích của USB Dongle 73

5.2 Chip xử lý chính 73

5.2.1 Chip LPC2103 (4) 73

5.2.2 Chip FT232R (5) 74

: 75

5.4 Hình ảnh 77

5.4.1 Mặt trên 77

5.4.2 Mặt dưới 77

5.5 Số lượng và chi phí thành phẩm 77

5.6 Xây dựng firmware 78

CHƯƠNG 6: KIẾN TRÚC HỆ THỐNG CỦA USB DONGLE 79

6.1 Kiến trúc tổng quan của hệ thống 79

6.2 Khái quát cơ chế truyền nhận 80

6.2.1 Đối với phần mềm trên máy tính 82

6.2.2 Đối với phần xử lý dưới board 83

6.3 Mô hình giao tiếp Dongle 83

6.3.1 Xác định khóa 84

6.3.2 Xác nhận license 85

6.3.3 Xác nhận tồn tại thiết bị 86

6.4 Giao diện lập trình (API) 88

6.4.1 Cho ứng dụng phần mềm 88

6.4.2 Cho phần cấu hình 89

6.5 Chương trình cấu hình 90

6.5.1 Tính năng 90

6.5.2 Giao diện 90

91

7.1 Thuật toán mã hóa AES (6) 91

7.2 Thuật toán băm (7) 94

7.3 Thuật toán phát sinh license 95

7.3.1 Độ dài 95

7.3.2 Loại dữ liệu 95

7.3.3 Các bước thực hiện 95

7.4 Cách thức chứng thực license 96

7.5 Cú pháp thông tin được truyền nhận 97

98

8.1 Các thành phần 98

8.2 Các bước thực hiện 98

8.3 Cách sử dụng phần mềm chứng thực qua Dongle 99

8.4 Kiểm thử USB Dongle qua việc dùng tool hack Error! Bookmark not defined. 8.5 Cơ chế bảo vệ 100

8.6 Đánh giá 101

103

9.1 Kết quả đạt được 103

9.2 Hướng phát triển 105

106

108

: Driver và các khái niệm liên quan 108

1 Driver là gì? 108

2 Khái quát về WDM và WDF 109

3 Kiến trúc WDF 111

4 Mô hình I/O của Windows và Device Stack 112

5 IRP 114

6 KMDF 114

Phụ lục B: Cách tính tỉ lệ vi phạm bản quyền phần mềm 117

Danh sách các hình

Hình 1-1 Quy trình phát triển của chuẩn USB 19

Hình 1-2 Kiến trúc hình sao nhiều tầng của USB 21

Hình 1-3 Cấu trúc dây bên trong cáp USB 1.1 21

Hình 1-4 Hai chuẩn kết nối phổ biến của USB 22

Hình 1-5 Các chuẩn kết nối khác của USB 22

Hình 1-6 Cơ chế mã hóa NRZI và bit stuffing 23

Hình 1-7 Các thành phần cơ bản trong Control Transfer 24

Hình 1-8 Giai đoạn Setup stage trong Control Read transfer 25

Hình 1-9 Giai đoạn Data stage trong Control Read transfer 25

Hình 1-10 Giai đoạn Status stage trong Control Read transfer 26

Hình 1-11 Giai đoạn Setup stage trong Control Write transfer 27

Hình 1-12 Giai đoạn Data stage trong Control Write transfer 27

Hình 1-13 Giai đoạn Status stage trong Control Write transfer 28

Hình 1-14 Các thành phần cơ bản trong Bulk và Interrupt transfer 29

Hình 1-15 Quá trình In transaction trong Bulk và Interrupt transfer 30

Hình 1-16 Quá trình Out transaction trong Bulk và Interrupt transfer 30

Hình 1-17 Các thành phần cơ bản trong Isochronous transfer 32

Hình 1-18 Quá trình In transaction trong Isochronous transfer 33

Hình 1-19 Quá trình Out transaction trong Isochronous transfer 33

Hình 1-20 Sơ đồ tổ chức các descriptor chuẩn 45

Hình 2-1: Sơ đồ trao đổi dữ liệu giữa USB Host và USB Device 52

Hình 2-2 Cấu trúc lưu trữ ED và TD 53

Hình 2-3 Băng thông hoạt động trong frame 59

Hình 2-4 Tiến trình liệt kê thiết bị 60

Hình 3-1: Đánh giá tỉ lệ vi phạm tại các nước Châu Á 63

Hình 3-2: Thống kê 60 quốc gia có tỉ lệ vi phạm bản quyền cao nhất và thấp nhất trên thế giới

năm 2010 64

Hình 4-1: Minh họa nhập chuỗi license khi sử dụng 68

Hình 4-2: Phần mềm chỉ cho dùng tối đa 30 ngày 69

Hình 4-3: Giới hạn của bản phần mềm dùng thử 70

Hình 4-4: Phần mềm đòi hỏi file đăng kí khi cài đặt 70

Hình 4-5: Thiết bị khóa cứng như một chiếc khóa an toàn cho phần mềm 71

Hình 5-1: Khối Micro controller LPC2103 75

Hình 5-2: Khối FT232 76

Hình 5-3: Khối nguồn 76

Hình 5-4: Mặt trên USB Dongle 77

Hình 5-5: Mặt dưới USB Dongle 77

Hình 6-1: Mô hình giao tiếp chứng thực qua thiết bị USB Dongle 79

Hình 6-2: Sơ đồ activity của phần mềm cần chứng thực 82

Hình 6-3: Sơ đồ trạng thái của device 83

Hình 6-4: Sơ đồ thể hiện trao đổi giữa Host và Device 84

Hình 6-5: Sơ đồ thể hiện thiết lập khóa 85

Hình 6-6: Sơ đồ thể hiện xác nhận license 86

Hình 6-7: Thông báo hiển thị khi không tìm thấy USB Dongle 87

Hình 6-8: Sơ đồ thể hiện việc xác nhận sự tồn tại của thiết bị 87

Hình 6-9: Giao diện chương trình cấu hình Dongle 90

Hình 7-1: Bước AddRoundKey 92

Hình 7-2: Bước SubBytes 92

Hình 7-3: Bước ShiftRows 93

Hình 7-4: Bước MixColumns 93

Hình 7-5:Một thao tác MD5 95

Hình 7-6: Cấu trúc gói tin 97

Hình 0-1 – Mô hình giao tiếp Driver và thiết bị 108

Hình 0-2 – Mô hình phát triển Driver của Windows 109

Hình 0-3 – Kiến trúc WDF 111

Hình 0-4 – Mô hình điều phối gói IRP của Device Stack 114

Hình 0-5 – Kiến trúc mô hình KMDF 115

Danh sách các bảng

Bảng 1–1 Phiên bản USB và chuẩn phần cứng tương thích 20

Bảng 1–2 Tốc độ truyền dữ liệu của USB 23

Bảng 1–3 Kích thước dữ liệu có thể gửi nhận tối đa trong các kiểu truyền 34

Bảng 1–4 Cấu trúc PID 34

Bảng 1–5 Các loại packet 34

Bảng 1–6 Cấu trúc ADDR 35

Bảng 1–7 Cấu trúc ENDP 35

Bảng 1–8 Cấu trúc Token packet 35

Bảng 1–9 Cấu trúc Data packet 36

Bảng 1–10 Cấu trúc Handshake packet 36

Bảng 1–11 Cấu trúc SOF packet 36

Bảng 1–12 Cấu trúc Setup Packet 36

Bảng 1–13 Mã các loại request chuẩn 37

Bảng 1–14 Các tham số của Get_Status request 38

Bảng 1–15 Thông tin trả về của Get_Status request 38

Bảng 1–16 Các tham số của Set_Feature request 39

Bảng 1–17 Các loại Feature Selector 39

Bảng 1–18 Các tham số của Clear_Feature request 39

Bảng 1–19 Các tham số của Set_Address request 40

Bảng 1–20 Các tham số của Get_Descriptor request 41

Bảng 1–21 Các tham số của Set_Descriptor request 42

Bảng 1–22 Các tham số của Get_Configuration request 42

Bảng 1–23 Các tham số của Set_Configuration request 43

Bảng 1–24 Các tham số của Get_Interface request 43

Bảng 1–25 Các tham số của Set_Interface request 44

Bảng 1–26 Các tham số của Synch_Frame request 44

Bảng 1–27 Cấu trúc lưu trữ Device descriptor 46

Bảng 1–28 Cấu trúc lưu trữ Configuration descriptor 48

Bảng 1–29 Cấu trúc lưu trữ Interface descriptor 49

Bảng 1–30 Cấu trúc lưu trữ Endpoint descriptor 50

Bảng 1–31 Cấu trúc lưu trữ String descriptor 51

Bảng 1–32 Các loại descriptor 51

Bảng 2–1 Cấu trúc Endpoint Descriptor 53

Bảng 2–2 Cấu trúc lưu trữ General Transfer Descriptor 54

Bảng 2–3 Cấu trúc lưu trữ Isochronous Transfer Descriptor 56

Bảng 2–4 Cấu trúc PacketStatusWord 57

Bảng 2–5 Danh sách lỗi giao tiếp 58

Bảng 5–1: Chi tiết các thành phần của USB Dongle 78

Bảng 8–1: Bảng ghi chú các cơ chế bảo mật của dòng LPC 101

Bảng 8–2: Bảng thể hiện các test case khi thực nghiệm 102

Danh sách chữ viết tắt

USB : Universal Serial Bus

AES : Advanced Encryption Standard

BSA : Business Software Alliance

MD5 : Message-Digest algorithm 5

SDK : Software Development Kit

API : Application Programming Interface

UART : Universal Asynchronous Receiver/Transmitter

GUID : Globally Unique IDentifier

FTDI : Future Technology Devices International

WDK : Windows Driver Kit

WDM : Windows Driver Model

CRD : Code Read Protection

CHƯƠNG 1: USB

 Giới thiệu tổng quan về USB: các chuẩn USB, phương thức truyền và các yêu cầu thiết

lập khi giao tiếp qua USB

1.1 Giới thiệu về các chuẩn USB [1]

USB là một chuẩn kết nối tuần tự trong máy tính, được sử dụng để kết nối các thiết bị ngoại vi với máy tính, chúng thường được thiết kế dưới dạng các đầu cắm cho các thiết bị tuân theo chuẩn plug and play (cắm vào là chạy mà không cần phải khởi động lại hệ thống)

Tháng 01/1996, dòng sản phẩm trang bị USB đầu tiên xuất hiện đánh dấu sự ra đời của chuẩn USB phiên bản 1.0 Nhưng phải chờ cho đến năm 1998, USB mới thực

sự thể hiện được vai trò quan trọng của mình thông qua phiên bản 1.1 Chuẩn USB phiên bản 2.0 được đưa ra vào tháng 04/2000 và được xem như là bản nâng cấp của USB 1.1 Chuẩn USB 2.0 mở rộng băng thông cho ứng dụng đa truyền thông và truyền với tốc độ nhanh hơn gấp 40 lần so với USB 1.1 Chưa dừng lại ở đó, USB 3.0

- bản nâng cấp của USB 2.0 - vừa được công bố vào tháng 11/2008 tại Hội nghị các nhà phát triển USB Công nghệ USB 3.0 hứa hẹn mang lại tốc độ nhanh hơn 10 lần so với chuẩn USB 2.0 hiện nay Không những thế, USB 3.0 còn bổ sung thêm nhiều tính năng ấn tượng khác như: tải nhận dữ liệu song song qua 2 luồng riêng biệt, sạc pin nhanh hơn, tiết kiệm điện năng hơn

Hình 1-1 Quy trình phát triển của chuẩn USB

Các thông số kỹ thuật của USB đã được các công ty lớn cùng tham gia xây dựng, trong đó phải kể đến Compaq, Digital Equipment, IBM, Intel, NEC và Northern

Telecom, Sự hỗ trợ USB thể hiện qua Win32 Driver Model (WMD) và nhờ vậy cho phép lập trình các phần mềm điều khiển thống nhất dùng cho Win 9x, NT, XP Trong các hệ điều hành ra đời từ năm 1998 đã có sự hỗ trợ đầy đủ cho USB (vd: Win98, NT5.0) Trên thực tế, trong các phiên bản nâng cấp của Win95 (từ phiên bản OEM-2.1) đã bắt đầu có tính năng hỗ trợ Từ phiên bản OSR-2.0 của Win95, sự hỗ trợ cho USB đã thể hiện từ chương trình cài đặt

Để giao tiếp với thiết bị USB theo các phiên bản khác nhau cần phải có sự hỗ trợ từ các chuẩn phần cứng tương ứng Hiện nay, đã có 4 chuẩn phần cứng được công

bố rộng rãi, đó là: UHCI, OHCI, EHCI, XHCI

Phiên bản USB Chuẩn phần cứng

USB 1.1 có những đặc trưng cơ bản sau:

 Được thiết kế theo cấu trúc hình sao nhiều tầng, có tối đa năm tầng Một Hub ở tại trung tâm của mỗi tầng, mỗi đoạn dây là một kết nối từ Host tới Hub hay Function, hoặc là một kết nối từ Hub tới Hub hay Function

Hình 1-2 Kiến trúc hình sao nhiều tầng của USB

 Những thiết bị USB 1.1 có đặc tính hot swapping, điều này có nghĩa là các thiết bị

có thể được kết nối (cắm vào) hay ngắt kết nối (rút ra) trong mọi thời điểm người sử dụng cần mà không cần phải khởi động lại hệ thống

 Cáp USB 1.1 gồm hai sợi dây nguồn và hai sợi dây xoắn mang dữ liệu, trên sợi nguồn, máy tính có thể cấp nguồn lên tới 500mA ở điện áp 5V một chiều

Hai sợi nguồn đỏ và đen (1 và 4) mang giá trị +5V và ground

Hai sợi vàng và xanh (2 và 3) mang dữ liệu

1 2 3 4

Hình 1-3 Cấu trúc dây bên trong cáp USB 1.1

 Thiết bị USB 1.1 được đấu nối theo 2 chuẩn khác nhau, đó là: chuẩn A và chuẩn

B Đây là 2 chuẩn phổ biến thường dùng

Hình 1-4 Hai chuẩn kết nối phổ biến của USB

Tín hiệu vào ra ở cổng 1 và 4: tín hiệu nguồn

Tín hiệu vào ra ở cổng 2 và 3: tín hiệu dữ liệu

USB chuẩn A: là kiểu kết nối ta thường gặp trên PCs, digital camera, webcam devices,… Chuẩn này được cắm vào máy tính và kết nối upstream (ngược dòng) hướng về máy tính

USB chuẩn B: là kiểu kết nối ta thường gặp trên các loại máy chụp hình, điện thoại di động, iPod,… Chuẩn này được cắm vào các thiết bị ngoại vi, kết nối downstream (xuôi dòng) tới các thiết bị riêng lẻ

Ngoài ra còn có các USB chuẩn khác như: mini A, mini B, mini AB

Hình 1-5 Các chuẩn kết nối khác của USB

1.3 Phương thức truyền dữ liệu

 Sự truyền dữ liệu trong USB 1.1 theo cơ chế mã hóa NRZI và một bit dồn bit stuffing (chèn một bit 0 vào dòng dữ liệu để đảm bảo những giao thức thích hợp trong dòng dữ liệu)

 USB 1.1 hỗ trợ 2 tốc độ truyền dữ liệu: 1.5Mb/s và 12Mb/s

LowSpeed1.5Mb/s

FullSpeed 12Mb/s

HighSpeed 480Mb/s

SuperSpeed 4.8Gb/s

USB 1.1

USB 2.0

USB 3.0

Bảng 1–2 Tốc độ truyền dữ liệu của USB

1.3.1 Các kiểu truyền dữ liệu

USB 1.1 hỗ trợ 4 kiểu truyền dữ liệu tùy thuộc vào mục đích sử dụng của thiết

1.3.1.1 Control Transfer

Giới thiệu

Tất cả các thiết bị đều phải hỗ trợ Control Transfer thông qua Endpoint 0

có sẵn trên thiết bị Control Transfer được dùng với mục đích: Host cần truy xuất những thông tin cần thiết của thiết bị lúc mới gắn vào cũng như cấu hình thiết bị chuẩn bị cho việc trao đổi dữ liệu sau này theo cách mà thiết bị hỗ trợ Quá trình truyền dữ liệu

Bao gồm 2 loại là: Read và Write tùy thuộc vào mục đích của Host Việc truyền dữ liệu theo mỗi loại trải qua ba giai đoạn là: Setup stage, Data stage (tùy chọn), Status stage Data stage (nếu có) có thể chứa 1 hay nhiều transaction, còn Setup stage và Status stage chỉ chứa duy nhất 1 transaction nên còn gọi là Setup transaction và Status transaction Và điều đặc biệt là Control Transfer có thể truyền theo 2 hướng trong cùng 1 ống lệnh (pipe)

Control transfer

Setup stage

Token packet Data packet Handshakepacket

Data stage Status stage

Setup transaction transaction(s)Data transactionStatus

Hình 1-7 Các thành phần cơ bản trong Control Transfer

 Control Read transfer (để truy xuất thông tin trong thiết bị)

i Setup stage

HANSHAKE PACKET

DEVICE > HOST HOST > DEVICE

DATASETUP

HOST > DEVICE

TOKEN PACKET DATA PACKET

DATA 0

Hình 1-8 Giai đoạn Setup stage trong Control Read transfer

- B1: Host gửi Token packet thuộc loại Setup

- B2: Host gửi Data packet là Data 0 chứa những thông tin về yêu cầu của Host Data packet ở Setup stage luôn luôn là 8 byte

- B3: Nếu nhận đƣợc yêu cầu của Host thành công, Device trả

về Handshake packet thuộc loại ACK

ii Data stage

DATA

HOST > DEVICE DEVICE > HOST HOST > DEVICE

TOKEN PACKET DATA PACKET HANSHAKE PACKET

Hình 1-9 Giai đoạn Data stage trong Control Read transfer

- B1: Host gửi Token packet thuộc loại In

- B2: Device trả về Data packet là Data 1 chứa dữ liệu mà Host mong muốn (dữ liệu nếu còn tiếp theo đƣợc chứa xen kẽ trong

DATA 0/1/0/…

Data 0,1,0…) Ngƣợc lại, Data packet sẽ chứa thông báo: NAK hay STALL

- B3: Nếu Host nhận dữ liệu thành công, Host sẽ gửi Handshake packet thuộc loại ACK thông báo cho Device biết

iii Status stage

DATA

HOST > DEVICE HOST > DEVICE DEVICE > HOST

TOKEN PACKET DATA PACKET HANSHAKE PACKET

Hình 1-10 Giai đoạn Status stage trong Control Read transfer

- B1: Host gửi Token packet thuộc loại Out

- B2: Host gửi Data packet là Data 1 với chiều dài bằng 0

- B3: Device trả về Handshake packet chứa trạng thái của toàn

bộ quá trình: ACK hay NAK hay STALL Quá trình truy xuất dữ liệu theo Control transfer kết thúc

 Control Write transfer (để cấu hình thiết bị)

i Setup stage

DATA 1

ACK

HANSHAKE PACKET

DEVICE > HOST HOST > DEVICE

DATASETUP

- B1: Host gửi Token packet thuộc loại Setup

- B2: Host gửi Data packet là Data 0 chứa những thông tin về yêu cầu của Host Data packet ở Setup stage luôn luôn là 8 byte

- B3: Nếu nhận đƣợc yêu cầu của Host thành công, Device trả

về Handshake packet thuộc loại ACK

ii Data stage

DATA

HOST > DEVICE HOST > DEVICE DEVICE > HOST

TOKEN PACKET DATA PACKET HANSHAKE PACKET

Hình 1-12 Giai đoạn Data stage trong Control Write transfer

- B1: Host gửi Token packet thuộc loại Out

- B2: Host gửi Data packet là Data 1 chứa dữ liệu mà Host muốn thiết lập lên Device (dữ liệu nếu còn tiếp theo đƣợc chứa xen kẽ trong Data 0,1,0…)

DATA 0/1/0/…

- B3: Nếu nhận dữ liệu thành công, Device sẽ trả về Handshake packet thuộc loại ACK thông báo cho Host biết, ngƣợc lại, Device trả về NAK hay STALL

iii Status stage

DATA

HOST > DEVICE DEVICE > HOST HOST > DEVICE

TOKEN PACKET DATA PACKET HANSHAKE PACKET

NAK STALL

IDLE

IDLE IDLE

Data Error

IDLE

Data Error

Hình 1-13 Giai đoạn Status stage trong Control Write transfer

- B1: Host gửi Token packet thuộc loại In

- B2: Device trả về Data packet là Data 1 với chiều dài bằng 0 Nếu việc thiết lập thất bại Data packet sẽ chứa các thông báo: NAK hay STALL

- B3: Host gửi Handshake packet chứa trạng thái của toàn bộ quá trình: ACK hay ngƣợc lại Quá trình cấu hình Device theo Control transfer kết thúc

DATA 1

1.3.1.2 Bulk Transfer

Giới thiệu

Bulk transfer là kiểu truyền nhanh nhất, được dùng trong việc truyền dữ liệu mà không tính đến thời gian thực Ta có thể gởi lượng dữ liệu lớn mà không bị giới hạn băng thông bởi vì Bulk transfer được ưu tiên thực hiện trước so với các loại Transfer khác Bulk transfer thường được sử dụng để gởi

dữ liệu từ host đến máy in hay gởi dữ liệu từ máy quét đến host hay đọc ghi

dữ liệu từ đĩa Chỉ có thiết bị USB hỗ trợ Full Speed mới có thể truyền theo kiểu Bulk transfer

Quá trình truyền dữ liệu

Bulk transfer bao gồm một hay nhiều In hoặc Out transaction Khác với Control transfer, Bulk transfer chỉ truyền theo một hướng trong một ống lệnh (pipe): tất cả transactions đều là In transaction hay Out transaction

Bulk, Interrupt transfer

Token

In

Hình 1-14 Các thành phần cơ bản trong Bulk và Interrupt transfer

 In transaction

Hình 1-15 Quá trình In transaction trong Bulk và Interrupt transfer

- B1: Host gửi Token packet thuộc loại In

- B2: Device trả về Data packet mà Host mong muốn Ngƣợc lại, Data packet sẽ chứa các thông báo: NAK hay STALL

- B3: Host gửi Handshake packet chứa trạng thái của toàn bộ quá trình: ACK hay ngƣợc lại Quá trình In transaction theo Bulk transfer kết thúc

 Out transaction

Hình 1-16 Quá trình Out transaction trong Bulk và Interrupt transfer

- B1: Host gửi Token packet thuộc loại Out

- B2: Host gửi Data packet

- B3: Device trả về Handshake packet chứa trạng thái của toàn bộ quá trình: ACK hay NAK hay STALL Quá trình Out transaction theo Bulk transfer kết thúc

1.3.1.3 Interrupt Transfer

Giới thiệu

Interrupt transfer được dùng trong việc truyền lượng dữ liệu ít trong khoảng thời gian rất ngắn Những thiết bị sử dụng Interrupt transfer là bàn phím, con chuột, gamepad, joystick Người dùng không muốn có sự trì hoãn đáng kể giữa việc nhấn một phím trên keyboard, di chuyển chuột với việc nhìn thấy những kết quả đó trên màn hình Chỉ có thiết bị USB hỗ trợ Low Speed mới có thể truyền theo kiểu Interrupt transfer

Quá trình truyền dữ liệu

Cũng giống như Bulk transfer, Interrupt transfer bao gồm một hay nhiều

In transaction hoặc một hay nhiều Out transaction Interrupt transfer chỉ truyền theo một hướng trong ống lệnh (pipe): tất cả transactions đều là In transaction hay Out transaction Chúng chỉ khác nhau ở độ ưu tiên trong chu

kỳ phục vụ transfer Bulk transfer có độ ưu tiên cao hơn Interrupt transfer

 IN transaction (tham khảo Hình 2-16)

- B1: Host gửi Token packet thuộc loại In

- B2: Device trả về Data packet mà Host mong muốn Ngược lại, Data packet sẽ chứa các thông báo: NAK hay STALL

- B3: Host gửi Handshake packet chứa trạng thái của toàn bộ quá trình: ACK hay ngược lại Quá trình In transaction theo Interrupt transfer kết thúc

 OUT transaction (tham khảo Hình 2-17)

- B1: Host gửi Token packet thuộc loại Out

- B2: Host gửi Data packet

- B3: Device trả về Handshake packet chứa trạng thái của toàn bộ quá trình: ACK hay NAK hay STALL Quá trình Out transaction theo Interrupt transfer kết thúc

1.3.1.4 Isochronous Transfer

Giới thiệu

Isochronous transfer được sử dụng để truyền dữ liệu với lượng lớn theo thời gian thực, dữ liệu được truyền ở 1 tỉ lệ xác định, hoặc có thời gian đã xác định và lỗi xảy ra thì không đáng kể, có thể bỏ qua Nó được ứng dụng trong loa audio, video Tiêu biểu cho việc sử dụng Isochronous transfer là mã hóa

âm thanh và chơi nó theo thời gian thực Chỉ có thiết bị USB hỗ trợ Full Speed mới có thể truyền theo kiểu Isochronous transfer

Quá trình truyền dữ liệu

Khác với các kiểu truyền trước, Isochronous transfer không có Handshake packet trong mỗi transaction nên nếu có lỗi xảy ra thì nó sẽ bỏ qua Cơ chế khắc phục lỗi và truyền lại là không có

Isochronous transfer

Token

In transaction(s)

Out transaction(s)

Hình 1-17 Các thành phần cơ bản trong Isochronous transfer

 In transaction

Hình 1-18 Quá trình In transaction trong Isochronous transfer

- B1: Host gửi Token packet thuộc loại In

- B2: Device trả về Data packet mà Host mong muốn

 Out transaction

Hình 1-19 Quá trình Out transaction trong Isochronous transfer

- B1: Host gửi Token packet thuộc loại Out

- B2: Host gửi tiếp Data packet

Kiểu truyền Kích thước (byte) dữ liệu tối đa được phép

gửi nhận trong một transaction

Low Speed Devices (1.5Mbit/s)

Full Speed Devices (12Mbit/s)

Isochronous Transfer 1,023

Bảng 1–3 Kích thước dữ liệu có thể gửi nhận tối đa trong các kiểu truyền

1.3.2 Cấu trúc lưu trữ các Packet

1.3.2.1 Các thành phần trong Packet

USB packet bao gồm các thành phần sau:

 SYNC: tất cả các packet đều bắt đầu với một field SYNC Field này có 8

bít, được dùng để đồng bộ xung giữa việc nhận và truyền dữ liệu Hai bít cuối đánh dấu kết thúc field cũng như cho biết vị trí field PID bắt đầu

 PID: field này theo sau field SYNC, nó được dùng để nhận biết loại

packet nào đã được gởi Có 4 bit thể hiện PID, tuy nhiên để đảm bảo packet nhận đúng, 4 bit bổ sung được lặp lại, tạo 8 bit PID tất cả Kết quả:

 ADDR: packet sẽ đƣợc gửi đến device có địa chỉ đã đƣợc chỉ định (vì mỗi

device có 1 địa chỉ phân biệt) Field này gồm 7 bit để hỗ trợ 127 device Những device nào chƣa đƣợc chỉ định ADDR thì packet gởi có ADDR = 0

Bảng 1–6 Cấu trúc ADDR

 ENDP: trong mỗi device có nhiều endpoint nên field này chỉ định packet

sẽ đƣợc gửi đến endpoint nào Field này có 4 bit, cho phép phục vụ đến 16 endpoint Riêng device là LowSpeed thì chỉ có 2 bit và phục vụ tối đa 4 endpoint

Bảng 1–7 Cấu trúc ENDP

 Frame Number: field này bao gồm 11 bít chứa giá trị tối đa là 0x7FF

Vào đầu mỗi frame, field này đƣợc tăng 1 đơn vị cùng với việc phát ra SOF token, khi đã đạt giá trị tối đa, nó sẽ tiếp tục với giá trị 0

 Data: field này chứa dữ liệu gửi đi hay nhận về, nó chứa tối đa là 1023

byte dữ liệu

 CRC: chứa các bít thể hiện tình trạng của packet đƣợc trả về có lỗi hay

không Token packet có 5 bit CRC, còn data packet có 16 bit CRC

 EOP: field này đánh dấu kết thúc packet

1.3.2.2 Các nhóm packet

 Token packet: có thể xem packet này là header, có ba loại sau:

In: đƣợc sử dụng khi Host muốn đọc thông tin từ device

Out: đƣợc sử dụng khi Host muốn gởi thông tin đến device

Setup: loại này chỉ đƣợc dùng trong Control transfer, để xác định và

nhận dạng device

Bảng 1–8 Cấu trúc Token packet

 Data packet: là những packet chứa dữ liệu, yêu cầu hay là các thông tin

liên quan đến host và device Có 2 loại data: DATA0, DATA1, mỗi loại có khả năng truyền từ 0 đến 1023 byte dữ liệu

Bảng 1–9 Cấu trúc Data packet

 Handshake packet: hiển thị tình trạng của packet Có ba loại:

ACK: packet đã được gửi thành công

NAK: cho biết device không thể gởi hay nhận dữ liệu tạm, thường

xuất hiện trong tình huống Host không có dữ liệu để gởi

STALL: có lỗi xảy ra trong quá trình gửi

Bảng 1–10 Cấu trúc Handshake packet

 SOF packet: packet này gồm có 11 bit frame được gởi bởi Host mỗi 1mS

500nS

SYNC PID Frame Number CRC5 EOP

Bảng 1–11 Cấu trúc SOF packet

1.4 Các loại Request chuẩn

Mọi thiết bị USB đều phải đáp lại các request từ Host gửi tới theo đường Control transfer Các request và tham số của nó được thiết lập trong Setup packet Mọi Setup packet đều có 8 byte, tuân theo định dạng sau:

bmRequestType: giá trị này cho biết các đặc trƣng của request, tuân

theo định dạng sau (bit 4…2 không dùng):

- 0: Host đến Device (OUT)

- 1: Device đến Host (IN)

bRequest: chứa mã của loại request cần sử dụng (tham khảo bảng 2-13)

wValue: chứa giá trị mô tả cho request

wIndex: chứa vị trí bắt đầu của vùng dữ liệu mong muốn

wLength: tổng số byte mà request mong muốn

bRequest Giá trị bRequest Giá trị

Mục đích: Host gởi request này để nhận về trạng thái của recipient đƣợc

chỉ định nhƣ device, interface, hay endpoint

Interface, Endpoint status

Bảng 1–14 Các tham số của Get_Status request

- wIndex: nếu là device, thì giá trị này bằng 0 Nếu là interface, giá trị

bằng mã số interface Nếu là endpoint, giá trị bằng mã số endpoint

- Data: thông tin trả về là trạng thái của device, interface, hay là endpoint

Wakeup

Self Powered

Bảng 1–15 Thông tin trả về của Get_Status request

 Trong câu lệnh truy vấn Get_Status tới device, có hai bit trạng thái đƣợc định nghĩa Bit 0 là Self-Powered với giá trị: 0 là bus-powered, 1

là self-powered (những giá trị này host không thể thay đổi đƣợc) Bit 1

là Remote Wakeup, giá trị này mặc định là 0 Tất cả các bit còn lại đƣợc

Mục đích: Host gởi request này để hiển thị một tính năng của device,

interface hay endpoint

có

00000010 Endpoint

Bảng 1–16 Các tham số của Set_Feature request

- wValue: tính năng cần hiển thị của recipient

- wIndex: nếu là tính năng của device, thì giá trị này bằng 0 Nếu là tính

năng interface, giá trị bằng mã số interface Nếu là tính năng của endpoint, giá trị bằng mã số endpoint

- Data: không có dữ liệu trả về đối với request này

Ghi chú: USB 1.1 định nghĩa hai tính năng sau:

Feature Selector Recipient Giá trị

Bảng 1–17 Các loại Feature Selector

- ENDPOINT_HALT, với giá trị 0 sẽ đƣợc chọn cho endpoint Endpoint

bulk và interrupt phải hỗ trợ điều kiện dừng Nguyên nhân gây ra điều kiện dừng là vấn đề về giao tiếp nhƣ là device không nhận handshake packet hoặc nhận nhiều dữ liệu hơn là mong đợi, hoặc device nhận câu truy vấn Set_Feature để dừng endpoint

- DEVICE_REMOTE_WAKEUP, với giá trị 1 sẽ đƣợc chọn cho device

Khi host bật tính năng DEVICE_REMOTE_WAKEUP, một device trong tình trạng Suspend (tạm ngƣng) có thể yêu cầu host bắt đầu lại việc giao tiếp

1.4.3 Clear_Feature

Mục đích: Host gởi request này để vô hiệu tính năng của device, interface,

hay endpoint đƣợc chỉ ra

có

Bảng 1–18 Các tham số của Clear_Feature request

- wValue: tính năng cần vô hiệu của recipient

- wIndex: nếu là tính năng của device, thì giá trị này bằng 0 Nếu là tính

năng interface, giá trị bằng mã số interface Nếu là tính năng của endpoint, giá trị bằng mã số endpoint

- Data: không có dữ liệu trả về đối với request này

1.4.4 Set_Address

Mục đích: Host gởi request này để thiết lập một địa chỉ dùng trong việc

giao tiếp với device sau đó

Bảng 1–19 Các tham số của Set_Address request

- wValue: địa chỉ mới của device Giá trị được cho phép từ 1 đến 127

Mỗi device trên hub, bao gồm cả root hub, đều có một địa chỉ duy nhất

- Câu truy vấn này không giống như những câu truy vấn khác bởi vì device không thực hiện câu truy vấn này cho đến khi hoàn thành Status stage của câu truy vấn bằng việc gởi data packet có chiều dài bằng 0 Host gởi token packet của Status stage tới địa chỉ mặc định, vì thế device phải phát hiện và đáp lại packet này trước khi thay đổi địa chỉ Sau khi câu truy vấn này hoàn thành, tất cả việc giao tiếp sẽ dùng địa chỉ mới, địa chỉ này phải lớn hơn 0