Sample - J2ME

Đồ án tốt nghiệp Dịch vụ Mobile-wallet

Sinh viên thực hiện: Lê Sỹ Đức - Khóa K50 - Lớp CNPM 1

Mục lục

Mục lục ........................................................................................................ 1

Danh mục các bảng ..................................................................................... 5

Danh mục các hình ..................................................................................... 6

Chương 1. GIỚI THIỆU .......................................................................... 10

1. Đặt vấn đề ........................................................................................... 10

2. Phát biểu bài toán ................................................................................ 10

3. Mục tiêu đồ án .................................................................................... 11

4. Phạm vi đồ án ..................................................................................... 11

Chương 2. CƠ SỞ LÝ THUYẾT ............................................................. 12

1. Tổng quan về mobile commerce ......................................................... 12

1.1 Định nghĩa Di động (Mobile) và Không dây (Wireless) ................ 12

1.2 Định nghĩa M-commerce ............................................................... 13

1.3 Những đặc trưng của thương mại di động ...................................... 13

1.4 Tổng quan các công nghệ thương mại di động .............................. 14

1.5 Một số giải pháp M-commerce ...................................................... 18

2. Lĩnh vực ứng dụng không dây với công nghệ Java .............................. 21

2.1 Khái quát ....................................................................................... 21

2.2 Các phiên bản Java 2 ..................................................................... 21

2.3 Sự cần thiết của J2ME ................................................................... 22

2.4 MIDP (Mobile Information Device Profile) .................................. 22

2.5 Các kiểu ứng dụng MIDP .............................................................. 23

2.6 Java 2 Enterprise Edition ............................................................... 24

2.7 Kiến trúc Ba-tầng (Three-tier) ....................................................... 25

2.8 Hỗ trợ các thiết bị MIDP thông qua tầng môi giới (Mediation)...... 26

3. Các vấn đề thiết kế ứng dụng doanh nghiệp không dây áp dụng công nghệ Java ........................................................................................................... 28



3.1 Mô hình lập trình cơ bản ............................................................... 28

3.2 Hỗ trợ nhiều loại client .................................................................. 29

3.3 Các vấn đề khi thiết kế và thực hiện .............................................. 29

4. Bảo mật trong thương mại di động ...................................................... 35

4.1 Khái quát ....................................................................................... 35

4.2 Mã hóa đối xứng (Symmetric Encryption) ..................................... 36

4.3 Mã hóa bất đối xứng (Asymmetric Encryption) ............................. 38

4.4 Mô hình Hybrid/Session key System ............................................. 40

4.5 Chữ kí số (Digital Signature) ......................................................... 42

4.6 Chứng nhận số (Digital Certificate) và tổ chức chứng nhận số (Certificate Authority) ................................................................................... 43

4.7 Public key infrastructure (PKI) ...................................................... 44

4.8 One time password (OTP) ............................................................. 45

5. Các chuẩn trong thương mại điện tử .................................................... 46

5.1 Chuẩn đóng gói bản tin giao tiếp ISO 8583 ................................... 46

5.2 Chuẩn bảo mật hệ thống thông tin ISO 27001 ............................... 49

5.3 PKCS ............................................................................................ 52

5.4 FIPS (Federal Information Processing Standards): Tiêu chuẩn xử lý thông tin liên bang. ........................................................................................ 54

Chương 3. PHÂN TÍCH HỆ THỐNG ..................................................... 56

1. Chức năng của hệ thống ...................................................................... 56

1.1 Chức năng đăng nhập .................................................................... 57

1.2 Chức năng chuyển tiền VĐT – VĐT ............................................. 59

1.3 Chức năng truy vấn số dư .............................................................. 63

2. Khó khăn trong việc triển khai dịch vụ ................................................ 65

3. Giải pháp công nghệ ........................................................................... 66

3.1 Giải pháp công nghệ trên điện thoại .............................................. 66

3.2 Giải pháp công nghệ phía server side ............................................ 66

4. Giải pháp bảo mật ............................................................................... 68



4.1 Mô hình mã hóa ............................................................................ 68

4.2 MAC ............................................................................................. 68

4.3 Thư viện Bouncy Castle ................................................................ 69

4.4 Phân phối public key server........................................................... 69

4.5 Mã nguồn có thể dịch ngược ......................................................... 69

4.6 RMS không an toàn ....................................................................... 69

4.7 Client sinh key session .................................................................. 70

4.8 SEQUENCE.................................................................................. 70

4.9 OTP .............................................................................................. 70

Chương 4. THIẾT KẾ .............................................................................. 72

1. Thiết kế CSDL .................................................................................... 72

1.1 Xây dựng các thực thể và các bảng cho cơ sở dữ liệu .................... 72

1.2 Bảng CUSTOMER........................................................................ 73

1.3 Bảng CUST_ACCOUNT .............................................................. 74

1.4 Bảng CUST_MOBILE .................................................................. 74

1.5 Bảng TRANS_APP ....................................................................... 75

1.6 Bảng CUST_CARD ...................................................................... 76

1.7 Bảng MOBILE .............................................................................. 76

2. Đặc tả giao diện kết nối ....................................................................... 77

2.1 Xử lý giao dịch .............................................................................. 77

2.2 Đặc tả bản tin tương tác ................................................................. 77

Chương 5. CÀI ĐẶT ................................................................................. 85

1. Cấu hình phần cứng ............................................................................ 85

2. Cấu hình phần mềm ............................................................................ 85

3. Ngôn ngữ, môi trường ......................................................................... 85

Chương 6. TỔNG KẾT VÀ NHẬN XÉT ................................................. 86

1. Giao diện của ứng dụng MIDlet .......................................................... 86

2. Hiệu suất của ứng dụng ....................................................................... 89

2.1 Các thông số thực thi ..................................................................... 89



2.2 Bộ nhớ .......................................................................................... 89

3. Tổng kết và nhận xét ........................................................................... 90

3.1 Đã làm được .................................................................................. 90

3.2 Hạn chế ......................................................................................... 91

3.3 Hướng phát triển ........................................................................... 91

Phụ lục ....................................................................................................... 92

Tài liệu tham khảo .................................................................................... 94



Danh mục các bảng

Bảng 1. Danh mục các từ viết tắt và thuật ngữ .............................................. 9

Bảng 2. Các thuật toán mã hóa đối xứng hay sử dụng ................................. 38

Bảng 3. MIT ............................................................................................... 47

Bảng 4. Message class ................................................................................ 48

Bảng 5. Message function ........................................................................... 48

Bảng 6. Message origin............................................................................... 48

Bảng 7. Tổng quan về PKCS ...................................................................... 53

Bảng 8. Bảng CUSTOMER ........................................................................ 74

Bảng 9. Bảng CUST_ACCOUNT ............................................................... 74

Bảng 10. Bảng CUST_MOBILE ................................................................. 75

Bảng 11. Bảng TRANS_APP ..................................................................... 76

Bảng 12. Bảng CUST_CARD ..................................................................... 76

Bảng 13. Bảng MOBILE ............................................................................ 77

Bảng 14. Định nghĩa các tham số của bản tin .............................................. 79

Bảng 15. Danh sách các chức năng ............................................................. 81

Bảng 16. Các tham số cho từng chức năng .................................................. 82

Bảng 17. Các thông số thực nghiệm ứng dụng ............................................ 89

Bảng 18. Bảng mã lỗi dịch vụ ..................................................................... 93



Danh mục các hình

Hình 1. Mối liên hệ giữa Di động và Không dây ......................................... 12

Hình 2. Sự phát triển công nghệ truyền thông vô tuyến ............................... 16

Hình 3. Sự phát triển của công nghệ vô tuyến ............................................. 17

Hình 4. Hệ thống WAP ............................................................................... 17

Hình 5. Các mức tổ chức J2ME .................................................................. 23

Hình 6. Triển khai hệ thống J2ME .............................................................. 23

Hình 7. Kiến trúc three-tier ......................................................................... 25

Hình 8. Mô hình mẫu kiến trúc three-tier .................................................... 26

Hình 9. Vị trí của tầng môi giới .................................................................. 27

Hình 10. Môi giới của tầng domain ............................................................. 27

Hình 11. Môi giới của tầng trình diễn ......................................................... 27

Hình 12. Kiến trúc mức cao của một ứng dụng doanh nghiệp Java không dây .............................................................................................................................. 28

Hình 13. Kiến trúc mức cao của một ứng dụng J2EE hỗ trợ client J2ME và client Brower ......................................................................................................... 29

Hình 14. Mã hóa đối xứng .......................................................................... 37

Hình 15. Mã hóa bất đối xứng ..................................................................... 39

Hình 16. Mô hình Hybrid system ................................................................ 40

Hình 17. Mô hình Hybrid System với MAC ............................................... 41

Hình 18. Mô hình session key ..................................................................... 42

Hình 19. Cách tạo chữ kí số ........................................................................ 43

Hình 20. Chứng nhận số ............................................................................. 44

Hình 21. Mô hình phân rã chức năng trên điện thoại ................................... 57

Hình 22 Luồng xử lý chức năng đăng nhập ................................................. 58

Hình 23. Luồng xử lý chức năng chuyển tiền VĐT –VĐT .......................... 60

Hình 24. Luồng xử lý chức năng truy vấn số dư .......................................... 63

Hình 25. Mô hình tổng thể hệ thống Mobile wallet ..................................... 65



Hình 26. Các module mức thấp của mobilegateway .................................... 67

Hình 27. Sơ đồ mối quan hệ giữa các bảng trong CSDL ............................. 73

Hình 28. Màn hình Splash ........................................................................... 87

Hình 29. Màn hình đăng nhập ..................................................................... 87

Hình 30. Màn hình chính ............................................................................ 87

Hình 31. Màn hình nhập PIN ...................................................................... 88

Hình 32. Chức năng tra cứu TK .................................................................. 87

Hình 33. Màn hình chờ ............................................................................... 88

Hình 34. Màn hình kết quả .......................................................................... 88

Hình 35. Màn hình nhập OTP ..................................................................... 88

Hình 36. Đồ thị bộ nhớ khi thực thi ứng dụng ............................................. 90



Thuật ngữ Định nghĩa Ghi chú

Mobile wallet ứng dụng cho phép khách hàng thực

hiện các giao dịch điện tử (chuyển tiền, thanh toán hàng hóa dịch vụ…)

J2ME Java 2 for micro edition ứng dụng mobie wallet viết trên nền tảng J2ME,

nên khi gọi ứng dụng J2ME cũng là ám chỉ ứng

dụng Mobile wallet

Mobile

commerce

Thương mại di động Còn gọi là m-commerce

DES Thuật toán mã hóa khối Data Encryption Standard

AES Thuật toán mã hóa khối Advanced Encryption Standard

RSA Thuật toán mã hóa bất đối xứng

Private key Khóa bí mật trong giải thuật mã hóa bất đối xứng

Public key Khóa công khai trong giải thuật mã hóa bất đối xứng

Session key Khóa bí mật, chỉ có hiệu dụng trong một khoảng thời gian, dùng trong mỗi

phiên làm việc

OTP One – time - password Mật khẩu dùng 1 lần

ISO 8583 Chuẩn định dạng thông điệp trong trao

đổi thông tin tài chính, ngân hàng

Mobile Pre-

Paid

Thuê bao điện thoại trả trước

Mobile Post-

Paid

Thuê bao điện thoại trả sau



ADSL Asymmetric Digital Subscriber Line

HomePhone Thuê bao cố định của viettel

VĐT Ví điện tử Chỉ số điện thoại đã đăng kí dịch vụ mobile wallet

API Application Program Interface

ASCII American Standard Code for

Information Interchange

CLDC Connected Limited Device Configuration

CPU Central Processing Unit

EJB Enterprise Java Beans

GPRS General Packet Radio Service

GSM Global System for Mobile Communications

HTTP Hyper-Text Transfer Protocol

JAD Java Application Descriptor

JAR Java Application Archive

MIDlet MIDP applet

MIDP Mobile Information Device Profile

OTA Over The Air

RMS Record Management System

Bảng 1. Danh mục các từ viết tắt và thuật ngữ



Chương 1. GIỚI THIỆU

1. Đặt vấn đề Tiến bộ trong công nghệ vô tuyến đã làm tăng số lượng người sử dụng thiết

bị di động và dẫn đến sự phát triển nhảy vọt của thương mại điện tử sử dụng các

thiết bị này. Loại giao dịch thương mại điện tử mới, thực hiện giao dịch thông qua

các thiết bị di động sử dụng mạng viễn thông vô tuyến và các công nghệ thương mại

điện tử hữu tuyến khác, được gọi là thương mại di động (mobile commerce) (còn được gọi là mobile E-commerce hay M-commerce).

Thương mại di động cho phép một phương thức trao đổi và mua bán thông tin mới, và nó đưa ra một lĩnh vực chưa được khai phá. Đối với khách hàng, nó

mang đến sự thuận tiện; đối với các nhà kinh doanh nó là một tiềm năng kiếm tiền rất lớn; đối với nhà cung cấp dịch vụ xem nó là một thị trường lớn chưa được khai

thác; đối với chính phủ xem nó là một giải pháp để giảm tải gánh nặng cho nền tài chính tiền tệ. Nói ngắn gọn lại, thương mại di động hứa hẹn nhiều cơ hội kinh

doanh hơn là thương mại điện tử truyền thống. Bởi vì các đặc tính riêng và sự ràng buộc của các thiết bị di động và mạng vô tuyến, thương mại di động hoạt động

trong một môi trường rất khác biệt so với thương mại điện tử trên Internet hữu tuyến.

Với những lợi ích to lớn mà M-commerce đem lại, việc triển khai áp dụng vào thực tế thị trường của Việt Nam một sản phẩm cụ thể là nhu cầu tất yếu, khi mà

ở các nước phát triển thì M-commerce đã phát triển rất mạnh. Đề tài nghiên cứu này đi sâu tìm hiểu, nghiên cứu các công nghệ mới nhất và các giải pháp bảo mật về m-

commerce, từ đó khai thác ưu điểm sẵn có, xây dựng một sản phẩm có tính thực tiễn cao.

Nhưng khó khăn cản trở lớn nhất cho việc phát triển thị trường thương mại di động chính là phương thức thanh toán. Nhằm tiếp cận các công nghệ và giải pháp

cho vấn đề này, ứng dụng Mobile Wallet – Ví điện tử áp dụng công nghệ Java sẽ là kênh thanh toán thuận tiện, đáp ứng nhu cầu thanh toán không dùng tiền mặt trong

thương mại di động cũng như các giao dịch thương mại khác.

2. Phát biểu bài toán Xây dựng dịch vụ Mobile Wallet cho phép khách hàng:



- Thanh toán và tra cứu thông tin thanh toán các dịch vụ viễn thông

(ADSL, HomePhone, Mobile Post-Paid, Mobile Pre-Paid, Mua hàng) thông qua điện thoại di động.

- Nạp tiền vào tài khoản, Chuyển tiền từ tài khoản ngân hàng này sang tài khoản ngân hàng khác, từ số thuê bao điện thoại này sang

số thuê bao điện thoại khác.

3. Mục tiêu đồ án Xây dựng demo dịch vụ M-wallet với mục tiêu cuối cùng là nhằm tạo thuận

tiện cho người sử dụng khi thanh toán một số dịch vụ, giảm tải cho hệ thống tiền tệ,

góp phần phát triển một nền tài chính không phải tiền mặt.

4. Phạm vi đồ án Lĩnh vực lập trình ứng dụng không dây là một lĩnh vực khó tiếp cận với

những ràng buộc chặt chẽ, các nhà sản xuất và nhà phát triển đã cố gắng đưa ra các tiêu chuẩn và công nghệ để có thể hỗ trợ tốt nhất cho lĩnh vực này. Ứng dụng không

dây, ngoài bản thân ứng dụng, còn phải được hỗ trợ rất nhiều từ phía server và nhà cung cấp dịch vụ. Ứng dụng m-wallet trên thiết bị di động áp dụng các công nghệ

mới và tối ưu hóa cho thiết bị di động như J2ME, servlet. Đồng thời, giải pháp bảo mật chính là trọng tâm của hệ thống thanh toán điện tử di động. Trong thời đại công

nghệ thông tin phát triển rất nhanh đến chóng mặt thì cùng với đó là nạn lừa đảo, giả mạo, hack … cũng phát triển và gia tăng là vấn nạn của xã hội và nó đe dọa đến

việc phát triển một hệ thống thanh toán điện tử. Hệ thống M-wallet áp dụng các giải pháp bảo mật như mã hóa đối xứng, bất đối xứng, chữ kí số, hybrid system … để

đảm bảo các giao dịch là tuyệt mật và an toàn.

Trong thời gian thực tập tốt nghiệp và thời gian làm đồ án, em đã cố gắng

tìm hiểu về thương mại di động cụ thể là thanh toán di động và các mô hình, kiến trúc cũng như các công cụ để có thể xây dựng một dịch vụ phục vụ cho thiết bị di

động mà cụ thể trong đồ án này là dịch vụ m-wallet và em xin được trình bày những nội dung sau trong đồ án:

� Các khái niệm cơ bản về hệ thống thương mại di động. � Lĩnh vực ứng dụng không dây với công nghệ Java.

� Bảo mật trong trao đổi thông tin.

� Các chuẩn được áp dụng trong thương mại điện tử.

� Xây dựng dịch vụ M-wallet.



Chương 2. CƠ SỞ LÝ THUYẾT

1. Tổng quan về mobile commerce

1.1 Định nghĩa Di động (Mobile) và Không dây (Wireless)

Định nghĩa di động và không dây khác nhau tùy người và tùy tổ chức. Trong

nhiều trường hợp, thuật ngữ di động và không dây có thể được dùng thay thế cho nhau, mặc dù chúng là hai khái niệm khác nhau. Hãy bắt đầu với thuật ngữ di động.

Di động là khả năng di chuyển. Một thiết bị di động là bất kỳ thứ gì có thể được dùng trong khi di chuyển, từ laptop đến điện thoại di động. Miễn là vị trí không cố

định, thì nó sẽ được xem là di động.

Không dây đề cập đến việc giao tiếp mà truyền đạt thông tin từ nơi này đến

nơi khác mà không sử dụng bất kì các dây dẫn nào. Khoảng cách ở đây có thể ngắn (vài mét như trong điều khiển tivi) hoặc dài (hàng ngàn kilomet trong giao tiếp sóng radio). Nó cho phép nhân viên liên lạc với dữ liệu doanh nghiệp mà không cần phải

kết nối vật lý đến mạng. Các thiết bị không dây bao gồm các thiết bị sử dụng một mạng không dây để gửi hay nhận dữ liệu. Mạng không dây, chính nó lại có thể được

truy xuất từ các nhân viên di động, cũng như ở vị trí cố định. Hình 1 mô tả mối liên hệ giữa di động và không dây. Như ta thấy, trong hầu hết trường hợp, không dây là

một tập con của di động; nhưng trong nhiều trường hợp, một ứng dụng có thể là di

động mà không cần phải không dây.

Hình 1. Mối liên hệ giữa Di động và Không dây

Một ứng dụng được xem là di động hoặc không dây, nó phải được xét tương ứng với các đặc tính của thiết bị mà nó chạy trên đó. Tài nguyên hạn chế, băng

thông thấp, và kết nối không liên tục là các yếu tố phù hợp với các ứng dụng di động.



1.2 Định nghĩa M-commerce

Định nghĩa về m-commerce cũng có nhiều, nhưng ở đây được hiểu đơn giản là loại giao dịch thương mại điện tử, thực hiện giao dịch thông qua các thiết bị di

động sử dụng mạng viễn thông vô tuyến và các công nghệ thương mại điện tử hữu tuyến khác, được gọi là thương mại di động (mobile commerce).

1.3 Những đặc trưng của thương mại di động

Bản chất của thương mại di động là không nằm ngoài ý tưởng tiếp xúc với

khách hàng, nhà cung cấp và nhân viên mà không cần quan tâm đến việc họ đang ở đâu. Thương mại di động là sự cung cấp đúng thông tin đến đúng chỗ và vào đúng

thời điểm. Nó mang đến cho người dùng khả năng truy xuất Internet bất kể ở đâu và bất kỳ lúc nào, mang đến khả năng định vị người dùng sử dụng thiết bị di động cá

nhân, tính năng truy xuất thông tin vào lúc cần thiết, và khả năng cập nhật thông tin/dữ liệu dựa theo yêu cầu. Thương mại di động có các đặc trưng mà thương mại điện tử thông thường không có, ta xét một số đặc trưng sau đây:

Tính rộng khắp (Ubiquity)

Tính rộng khắp là ưu điểm chính của thương mại di động. Người dùng có thể

lấy bất kỳ thông tin nào họ thích, bất kỳ khi nào họ muốn không cần quan tâm đến vị trí của họ, thông qua các thiết bị di động kết nối Internet. Trong các ứng dụng

thương mại di động, người dùng vẫn có thể hoạt động bình thường, chẳng hạn như gặp gỡ mọi người hay đi lại, trong khi thực hiện giao dịch hay nhận thông tin. Với

khả năng này, thương mại di động làm cho dịch vụ hay ứng dụng có thể đáp ứng bất kỳ đâu và bất kỳ lúc nào khi nảy sinh nhu cầu.

Khả năng tiếp xúc (Reachability)

Thông qua thiết bị di động, các nhà kinh doanh có thể tiếp xúc với khách

hàng bất kỳ lúc nào. Mặt khác, với một thiết bị di động, người dùng có thể giao tiếp với người khác bất kỳ đâu và bất kỳ lúc nào. Hơn nữa, người dùng có thể giới hạn

khả năng tiếp xúc của họ với một số người cá biệt và tại các thời gian cá biệt.

Sự định vị (Localization)

Khả năng biết được vị trí vật lý của người dùng tại một thời điểm cụ thể cũng làm tăng giá trị của thương mại di động. Với thông tin về định vị, ta có thể cung cấp

các ứng dụng dựa trên vị trí. Ví dụ, khi biết được vị trí của người dùng, dịch vụ di

động sẽ nhanh chóng thông báo cho họ biết khi nào bạn bè hay đồng nghiệp của họ



sẽ ở gần. Nó cũng sẽ giúp người dùng định vị một nhà hàng hay một máy rút tiền tự

động gần nhất.

Tính cá nhân hóa (Personalization)

Một số lượng thông tin, dịch vụ và ứng dụng khổng lồ tồn tại trên Internet, và tính thích đáng (relevant) của thông tin người dùng nhận được là rất quan trọng.

Bởi vì người sử dụng thiết bị di động thường yêu cầu các tập ứng dụng và dịch vụ khác nhau, các ứng dụng thương mại di động có thể được cá nhân hóa để biểu diễn

thông tin hay cung cấp dịch vụ một cách thích đáng đến người dùng chuyên biệt.

Tính phổ biến (Dissemination)

Một số hạ tầng vô tuyến hỗ trợ việc cung cấp dữ liệu đồng thời đến tất cả người dùng di động trong một vùng địa lý xác định. Tính năng này cung cấp một

phương tiện hiệu quả để phổ biến thông tin đến một số lượng lớn người tiêu dùng.

1.4 Tổng quan các công nghệ thương mại di động

Thương mại di động được xây dựng bởi sự kết hợp của các công nghệ như

mạng, các hệ thống nhúng, cơ sở dữ liệu, bảo mật. Phần cứng di động, phần mềm và mạng vô tuyến giúp các hệ thống thương mại di động truyền dữ liệu nhanh

chóng hơn, định vị vị trí của người dùng chính xác hơn và giao dịch kinh doanh bảo mật và tin cậy hơn. Sau đây sẽ giới thiệu các công nghệ chính làm cho thương mại

di động trở thành hiện thực, các công nghệ đang và sẽ nâng cao hiệu quả và tính năng của nó trong tương lai gần.

1.4.1 Công nghệ truyền thông (Communication Technology)

GSM

Global System for Mobile Communications (GSM) còn được gọi là mạng số thế hệ thứ hai (2G-second generation), hoạt động ở băng tần 900 MHz và 1800

MHz. Là một dịch vụ chuyển mạch kênh, người dùng phải quay số để duy trì kết nối khi cần truyền thông dữ liệu, là chuẩn di động thịnh hành ở châu Âu và hầu hết

vùng châu Á Thái Bình Dương.

GPRS và EDGE

GPRS (General Packet Radio Service) và EDGE (Enhanced Data GSM

Environment) còn được gọi là các công nghệ 2,5 G. GPRS sử dụng hạ tầng mạng có sẵn nhưng nó được giới thiệu là cung cấp tốc độ kiểu ISDN. Thay vì gửi một luồng

dữ liệu liên tục trên một kết nối thường xuyên, hệ thống chuyển mạch gói của GPRS chỉ sử dụng mạng khi có dữ liệu được truyền. Người dùng có thể gửi và nhận



dữ liệu lên đến 115 kbit/giây với GPRS. EDGE, là một phiên bản nhanh hơn của

GSM, được thiết kế để cho phép truyền dữ liệu multimedia và các ứng dụng băng rộng khác. Nó sẽ sử dụng kỹ thuật điều biến (modulation) mới để cho phép tốc độ

dữ liệu lên đến 384 kbit/giây trên hạ tầng sẵn có của GSM.

UMTS

Universal Mobile Technology System (UMTS), còn được gọi là công nghệ

thế hệ thứ 3 (3G), nhắm vào truyền thông văn bản, thoại, video, và multimedia dựa trên gói, có băng thông cao để hỗ trợ các ứng dụng cần nhiều dữ liệu. Một khi

UMTS được triển khai đầy đủ, máy tính và người dùng điện thoại có thể kết nối Internet liên tục và truy xuất dịch vụ toàn cầu. Tích hợp chức năng của các thiết bị

đa dạng khác nhau, điện thoại di động thế hệ 3G có thể được dùng như một điện thoại, một máy tính, một TV, một tờ giấy, một trung tâm hội thảo video, một tạp

chí, một sổ ghi nhớ, hay thậm chí là một thẻ tín dụng.

Các công nghệ thế hệ thứ tư

Mặc dù các công nghệ 3G chỉ mới xuất hiện ở nước ta, nhưng trên thế giới, người ta cũng đã bắt đầu nghiên cứu các công nghệ thế hệ thứ tư (4G). Các nghiên cứu này nhằm giải quyết hoàn thiện các giao diện vô tuyến đa dạng và thậm chí là

hạ tầng truy xuất vô tuyến hoàn toàn mới. Các phương thức điều biến tốt hơn và công nghệ ăng-ten thông minh là hai lĩnh vực nghiên cứu chính cho phép hệ thống

vô tuyến thế hệ thứ tư tốt hơn mạng vô tuyến thế hệ thứ ba.



Bluetooth

Bluetooth là một công nghệ vô tuyến năng lượng thấp dùng cho truyền thông

và trao đổi dữ liệu. Sử dụng một chip đơn với mạch truyền vô tuyến gắn sẵn, Bluetooth là một chuẩn vô tuyến sóng ngắn rẻ tiền hỗ trợ cho mạng cục bộ (LAN).

Nó được phát triển để thay thế cáp và kết nối hồng ngoại trong vòng bán kính 10m. Bluetooth có thể được dùng để kết nối các thiết bị điện tử, ví dụ như máy vi tính,

máy in, thiết bị di động và PDA, với mạng dữ liệu vô tuyến.

Như mô tả trong hình 3, công nghệ vô tuyến thế hệ thứ nhất là điện thoại tế

bào tương tự (cellcular phone). Công nghệ vô tuyến thế hệ thứ hai, bao gồm điện thoại tế bào số, băng tần thấp hiện tại được sử dụng rộng rãi. Công nghệ vô tuyến

thế hệ thứ ba cung cấp băng thông cao để hỗ trợ các ứng dụng cần nhiều dữ liệu.

Điện thoại

tương tự

GSM

UMTS

Công nghệ

4G

EDGE GPRS

Công nghệ 1G

Công nghệ 2G

Công nghệ 3G

Công nghệ 2.5G

Hình 2. Sự phát triển công nghệ truyền thông vô tuyến



WAP

Wireless Application Protocol (WAP) là một chuẩn mở toàn cầu cho giải pháp di động, thiết kế riêng biệt cho phân phát thông tin Web đến thiết bị di động.

Là một giao thức ứng dụng end-to-end, nó cung cấp giải pháp cho việc phát triển các ứng dụng di động, chẳng hạn như kết nối các thiết bị di động vào Internet và

làm cho các thiết bị di động trở thành các thiết bị truyền thông có khả năng truyền thông với các thiết bị khác trên mạng vô tuyến. Nó cũng cho phép thiết kế các dịch

vụ di động tương tác và thời gian thực.

J2ME

J2ME (Java 2 Platform Micro Edition) là nền tảng Java, phiên bản thu nhỏ của Sun Microsystems. J2ME được xây dựng nhằm mang đến khả năng phát triển

ứng dụng đa dạng, phong phú cho các thiết bị di động. Với ưu thế của ngôn ngữ Java, dựa trên hạ tầng mạng có sẵn của WAP, J2ME có thể dùng để xây dựng các

ứng dụng từ đơn giản đến phức tạp nếu kết hợp với các công nghệ phía server.

1.4.2 Công nghệ trao đổi thông tin

HTML

HTML (Hyper-Text Markup Language) được thông qua rộng rãi bởi cộng

đồng Internet là một định dạng tài liệu dùng để duyệt (browse). Các công cụ tác chủ

Điện thoại tế bào Điện thoại tế bào số & v.v…

Điện thoại tế bào 3G

Thế hệ thứ nhất Thế hệ thứ hai Thế hệ thứ ba

Mobile

Client WAP

Gateway Web Server

Mobile Portal

Request Request

Response

Response Response

Mạng vô tuyến

Mạng hữu tuyến

Hình 3. Sự phát triển của công nghệ vô tuyến

Hình 4. Hệ thống WAP



và trình duyệt sẵn có làm cho người dùng tạo các tài liệu HTML kết hợp các đối

tượng multimedia một cách dễ dàng.

XML

eXtensible Markup Language (XML) là một siêu ngôn ngữ (meta-language),

được thiết kế để truyền thông ngữ nghĩa của dữ liệu thông qua một cơ chế mô tả. Nó dùng thẻ dữ liệu và đặt nội dung vào trong ngữ cảnh (context), do đó cho phép

nhà cung cấp mã hóa ngữ nghĩa vào tài liệu của họ. Đối với các hệ thống thông tin hỗ trợ XML, dữ liệu có thể được trao đổi thậm chí giữa các tổ chức với các hệ thống

hoạt động và mô hình dữ liệu khác nhau, miễn là các tổ chức này đồng ý về ngữ nghĩa của dữ liệu mà họ trao đổi.

WML

Wireless Markup Language (WML), xuất phát từ XML, được phát triển đặc

biệt cho WAP. Nó cho phép thông tin được trình bày như các thẻ bài (card) thích hợp để hiển thị trên các thiết bị di động. Như vậy WML chủ yếu cho WAP cũng

giống như HTML cho Internet.

SMS

Short Message Service (SMS) cho phép gửi và nhận các thông điệp văn bản

đến và đi từ điện thoại di động. Có thể trao đổi lên đến 160 ký tự chữ cái và số trong mỗi thông điệp SMS. Nó cũng cung cấp các dịch vụ thông tin di động, chẳng hạn

như tin tức, thị trường chứng khoán, thể thao và thời tiết. Gần đây SMS chat và tải nhạc chuông cũng đã được cung cấp.

MIDP

Mobile Information Device Profile (MIDP) là một bộ phận cụ thể của J2ME. Ngày càng được các nhà cung cấp hàng đầu hỗ trợ xây dựng, MIDP tập hợp các thư

viện và API dùng để phát triển ứng dụng J2ME độc lập với phần cứng.

1.5 Một số giải pháp M-commerce

1.5.1 Mua bán số (Digital purchase)

Mua bán số thích hợp nhất cho người dùng di động là cho các sản phẩm có

thể được tải về và sử dụng ngay lập tức. Hai thị trường lớn nhất cho các ứng dụng số là nhạc chuông (ringtone) và trò chơi (game). Nhiều hãng truyền thông cho phép

người dùng tải nhạc chuông mới về thiết bị của họ với cước phí rẻ. Điều này cho phép người dùng cá nhân hóa thiết bị của họ. Một lĩnh vực chắc chắn thành công



nữa đó là trò chơi di động. Các tiến bộ trong lĩnh vực sản xuất thiết bị di động làm

cho chúng trở thành các thiết bị tuyệt vời để chơi trò chơi.

1.5.2 Ngân hàng di động (Mobile banking).

Thiết bị không dây có hai ưu điểm cho ngân hàng di động. Ưu điểm đầu tiên là cung cấp khả năng truy xuất tài khoản ngân hàng cá nhân để xem nhật ký tài

khoản và thực hiện giao tác. Đây là một mở rộng cho ngân hàng Internet (Internet banking) vốn đã rất thành công. Ưu điểm thứ hai là sử dụng thiết bị di động cho

việc thanh toán, giống như một tiền mặt số (digital cash). Lĩnh vực này rất được quan tâm, và đã triển khai thành công ở nhiều nước phát triển.

1.5.3 Các dịch vụ thông tin (Information Service).

Mặc dù di động có nhiều lợi ích, nhưng người dùng di động vẫn thường cảm

thấy nó chưa được liên kết với những thói quen hàng ngày. Các dịch vụ thông tin giúp giải quyết vần đề này bằng cách cung cấp thông tin thông dụng cho người dùng, chẳng hạn như thông tin chứng khoán, thông tin thời tiết, và tỉ số thể thao.

Với sự phát triển rộng rãi của thông điệp di động, nhiều dạng thông tin có thể được

đưa đến người dùng hơn.

1.5.4 Các dịch vụ dựa trên vị trí (Location-based service).

Nếu các nhà kinh doanh có khả năng nắm bắt và phản ứng với vị trí và yêu

cầu hiện tại của người dùng thì đây sẽ là một công cụ mạnh để tiêu thụ sản phẩm. Các dịch vụ dựa trên vị trí cho phép khách hàng tìm thông tin chính xác mà họ cần

vào đúng thời điểm mà họ muốn dùng nó. Đây sẽ là một công cụ quan trọng cho giải pháp m-commerce, mặc dù các vấn đề liên quan đến sự riêng tư sẽ phải được

giải quyết trước khi các dịch vụ định vị được sử dụng rộng rãi.

1.5.5 Mua sắm di động.

Không phải hầu hết các dạng mua sắm đều sẽ phổ biến trên thiết bị di động ngay được. Sẽ là không thực tế khi tìm hàng hóa sử dụng các thiết bị bị hạn chế,

trong khi các phương thức mua sắm khác thì hữu ích và thú vị hơn. Có một số dạng mua bán có thể thích ứng tốt với m-commerce. Ví dụ, việc mua vé xem phim là

hoàn toàn có khả năng. Các thiết bị di động cũng có thể được dùng cho việc so sánh trước khi mua sắm (comparison-shopping). Trước khi quyết định mua sắm, người

tiêu dùng có thể muốn tham khảo trước giá của một sản phẩm đó từ nhà cung cấp Internet để bảo đảm rằng họ đã mua đúng giá.



1.5.6 Quảng cáo di động (Mobile advertising).

Khi người dùng di động bắt đầu thấy được lợi ích từ giải pháp m-commerce, thì tiếp theo đó sẽ xuất hiện quảng cáo di động. Các nhà cung cấp dịch vụ có khả

năng lấy được các thông tin hấp dẫn đối với các nhà quảng cáo, chẳng hạn như nơi người dùng đang đứng, và họ sử dụng điện thoại di động của họ cho việc gì. Với

các thông tin dạng này, các nhà quảng cáo có thể gửi các thông điệp đã được cá nhân hóa. Trở ngại lớn nhất cho việc quảng cáo di động là phản ứng ngược của

khách hàng. Nếu người dùng nhận được những thông điệp và quảng cáo không tự nguyện, họ sẽ có thể thay đổi nhà cung cấp dịch vụ, hay thậm chí tệ hơn là ngừng sử

dụng thiết bị của họ. Vì lý do này, trong tương lai gần, chúng ta hầu như chỉ sẽ nhận được các thông tin quảng cáo theo yêu cầu, ví dụ như từ trạm xăng hay nhà hàng

gần nhất.

1.5.7 Thanh toán di động (Mobile payment)

Là một phương thức thanh toán mới đang phát triển nhanh và mạnh. Thay vì

phải dùng tiền mặt, séc, credit card thì khách hàng có thể sử dụng điện thoại di động

để trả cho các hàng hóa số, dịch vụ… Có 3 kiểu thanh toán di động cơ bản:

- Thanh toán dựa trên SMS

- Thanh toán trực tiếp qua Mobile Billing

- Thanh toán qua mobile web (WAP)



2. Lĩnh vực ứng dụng không dây với công nghệ Java

2.1 Khái quát

Các ứng dụng Java cho các thiết bị không dây nhỏ (“MIDlet”) sẽ đóng một

vai trò – có thể là nhỏ, cũng có thể là lớn – trong các hệ thống phần mềm phân tán. Khi đó, nó sẽ sinh ra một dạng phần mềm client mới. Chúng rất thích hợp với khái

niệm thin-client, nhưng do chúng quá nhỏ, yêu cầu phải có thêm sự phối hợp làm việc hiệu quả với các thông tin được cung cấp bởi các servlet và JSP, và có thể là

EJB ở đằng sau.

Ta sẽ xem xét các công nghệ Java chủ chốt để phát triển ứng dụng không dây

trong hệ thống doanh nghiệp. Ta cũng sẽ xét đến các kiến trúc hỗ trợ client không dây trong các hệ thống doanh nghiệp.

Trong lúc này, dịch vụ Web (Web service), có thể sẽ trở thành một phương tiện vượt trội để hỗ trợ cho phần mềm client không dây trong một vài năm tới.

2.2 Các phiên bản Java 2

Nền tảng Java 2 được chia thành ba phiên bản, mỗi phiên bản hỗ trợ một dạng phần mềm trên các hệ thống khác nhau.

Phiên bản chuẩn, hay J2SE (Java 2 platform, Standard Edition), là phiên bản cũ nhất và thông dụng nhất. Nó hỗ trợ các ứng dụng Java, applet, lập trình desktop

và các hệ thống lớn hơn – chủ yếu là cho PC - có thể có nối mạng hoặc không nối mạng. Người ta thông thường sử dụng J2SE cho các ứng dụng GUI đơn và console,

các thành phần middleware và các dịch vụ RMI.

Phiên bản doanh nghiệp, hay J2EE (Java 2 platform, Enterprise Edition), mở

rộng phiên bản chuẩn với các API có các “tính năng doanh nghiệp” (enterprise features). J2EE hỗ trợ Web service thông qua các servlet và JSP, dữ liệu bằng

JDBC, và các hệ thống giao tác lớn thông qua EJB – đây là một vài công nghệ chính của J2EE. Các thành phần J2EE gắn chặt với phía server của các hệ thống

lớn: khả năng xử lý mạnh, bộ nhớ và không gian lưu trữ lớn và có khả năng mở rộng.

Phiên bản mới nhất trong ba phiên bản là phiên bản thu nhỏ, hay J2ME (Java 2 platform, Micro Edition). Nó hỗ trợ các thiết bị “micro” đa dạng, mà J2ME gọi là

các “hiện trạng” (profile) nhưng tất cả chúng đều kém khả năng hơn so với máy tính cá nhân. Trong J2ME, sức mạnh CPU, bộ nhớ, lưu trữ và khả năng kết nối đều bị

hạn chế, có thể là rất nghiêm ngặt.



2.3 Sự cần thiết của J2ME

Thế giới của các thiết bị di động và các thiết bị “sub-PC” không có các đặc tính giống như trong lĩnh vực PC và server.

Ngoài ra, không phải mọi thiết bị trong lĩnh vực này đều cùng làm một việc. Sự khác nhau về thiết kế và mục đích giữa PDA, điện thoại, và máy nhắn tin là rất

đáng kể.

Bất kể nó mang lại sự đổi mới gì cho thị trường, thì tính đa dạng của các

thiết bị này là một ác mộng đối với các lập trình viên. Nếu muốn xây dựng một ứng dụng cho điện thoại di động, thì có phải viết mã lại, xây dựng lại, và kiểm tra lại

cho mọi thiết bị hay không? Nếu muốn xây dựng một client có kết nối mạng, thì phải xét đến các công nghệ kết nối nào? v.v...

J2ME ra đời nhằm mục đích chính là thiết lập một chuẩn đơn mà thông qua đó các nhà phát triển có thể tạo nên các phần mềm có tính khả chuyển (portable) cho các thiết bị micro. Ngôn ngữ Java là sự lựa chọn đương nhiên cho lĩnh vực này,

bởi vì về cơ bản nó đã hướng nhiều về tính khả chuyển. Bằng cách này, Sun đã đảm nhận bài toán lớn về tính đa dạng của thiết bị ở một mức tổng quát, do đó các nhà

phát triển không phải quan tâm đến vấn đề này nữa. Nếu mọi nhà cung cấp PDA, điện thoại và máy nhắn tin đều thực hiện J2ME cho thiết bị của họ, thì chúng ta có

khả năng viết chương trình “viết một lần, chạy mọi nơi” (write once, run anywhere) trong lĩnh vực micro, cũng giống như ta đã quen với khái niệm này ở các hệ thống

máy lớn. Tuy nhiên, trên thực tế để đạt đến như khẩu ngữ trên thì còn rất nhiều việc phải làm với lập trình viên.

2.4 MIDP (Mobile Information Device Profile)

Mặc dù không phải chỉ có một hướng kiến trúc J2ME, nhưng các thiết bị di

động không dây dường như dần dần càng quan tâm đến J2ME. Bao gồm:

• Điện thoại di động

• Trợ tá cá nhân số (Personal Digital Assistant-PDA)

• Máy nhắn tin

• Thiết bị đọc sách điện tử

• Các thiết bị point-of-sale

J2ME được tổ chức thành các mức, mỗi mức xác định một định nghĩa tăng dần của các thiết bị đích. Có nhiều lựa chọn kiến trúc tồn tại ở mỗi mức, và ràng

buộc tùy chọn ở các mức cao hơn. Lập trình viên chỉ cần quan tâm đến hiện trạng



(profile), định nghĩa các API; các nhà thực hiện J2ME cho thiết bị cần tập trung đến

mức VM (Virtual Machine).

Các đặc tả cho các thiết bị không dây là Connected Limited Device

Configuration hay CLDC, và Mobile Information Device Profile hay MIDP. MIDP định nghĩa các đặc tính tối thiểu của thiết bị như sau:

• Bộ nhớ không bay hơi có dung lượng 128K (nghĩa là, bộ nhớ có trạng thái được giữ lại khi thiết bị đã tắt) dành cho các thành phần MIDP, bao gồm KVM,

Core API và chương trình MIDP.

• 8K bộ nhớ không bay hơi dành cho dữ liệu bền vững của ứng dụng.

• 32K bộ nhớ bay hơi cho bộ nhớ của chương trình.

• Màn hình hiển thị ít nhất là 96x54 pixel, có thể chỉ là một bit màu hay hỗ trợ nhiều màu hoặc màu mức xám.

• Cơ chế nhập liệu hỗ trợ ít nhất một bộ phím số, hoặc một màn hình cảm ứng

có khả năng cấu hình hỗ trợ nhập liệu số.

• Khả năng kết nối mạng không dây hai chiều, với băng thông hạn chế và thông thường là không liên tục.

Như vậy các thiết bị hỗ trợ MIDP cung cấp một nền tảng chuẩn cho các phần mềm Java:

2.5 Các kiểu ứng dụng MIDP

Các ứng dụng MIDP được gọi là các MIDlet. Hầu hết các MIDlet đều ở một trong hai dạng sau:

Hiện trạng

Cấu hình

Máy ảo

Phần cứng/HĐH

MIDP

CLDC

“K” Virtual Machine

Cell Phone, PDA,...

Phần cứng thiết bị di

động

Hệ điều hành

KVM CLDC MIDP

MIDlet

Hình 5. Các mức tổ chức J2ME

Hình 6. Triển khai hệ thống J2ME



1. Ứng dụng đơn (standalone application) được nạp hoàn toàn vào thiết bị và

có thể chạy bất kỳ lúc nào thiết bị được mở, không yêu cầu tài nguyên bên ngoài. Loại này bao gồm:

• Các ứng dụng PDA và ứng dụng organizer như sổ địa chỉ, danh sách công việc và lịch hẹn.

• Các công cụ đơn giản như máy làm tính (calculator)

• Trò chơi 2. Ứng dụng nối mạng (networked application) được chia thành ít nhất hai

thành phần, một thành phần là client được triển khai trên thiết bị di động.

Thành phần này sẽ ít được dùng nếu không có kết nối đến ít nhất một server trên hệ thống. Server thường là được đặt trong môi trường J2EE, và

phục vụ bằng Web hoặc các giao thức Internet khác. Ở đây, ta hãy xét kỹ thuật ngữ client. Ta không gọi một MIDlet là một client

chỉ đơn giản là vì nó sử dụng kết nối mạng MIDP và liên lạc đến các thành phần khác. Câu hỏi là phần luận lý lõi của ứng dụng đặt ở đâu? MIDlet có đảm nhận hầu

hết việc “suy nghĩ” và chỉ quan tâm đến mạng hay không? Đó không phải là client, thật vậy – ít nhất là không theo đúng nghĩa trong ngữ cảnh của hệ thống enterprise.

Một client là một MIDlet dựa vào một server để suy nghĩ, lưu trữ, tải, xử lý, hay nói cách khác là làm việc thay cho nó.

2.6 Java 2 Enterprise Edition

Các MIDlet client không yêu cầu phải kết nối đến các server chạy Java. Một

MIDlet có thể được viết để tạo HTTP request đến một trang web đã có từ trước, và nó không cần quan tâm là trang web đó được hỗ trợ bởi ASP trên IIS, hay servlet

trên Apache/Tomcat,... Tuy nhiên, trên thực tế, khi toàn bộ hệ thống phân tán được phát triển mới, thì Java nên được dùng ở mọi mức.

Phiên bản Java doanh nghiệp, Java 2 Enterprise Edition, hay J2EE – là một tập các chuẩn để áp dụng công nghệ Java cho các hoạt động “loại doanh nghiệp

(enterprise-class)”, ví dụ như:

• Dịch vụ HTTP, bao gồm ứng dụng Web và dịch vụ Web

• Lưu trữ và lấy dữ liệu từ cơ sở dữ liệu quan hệ

• Xử lý giao tác trực tuyến

• Thực hiện đối tượng phân tán (bằng CORBA)

• Truyền thông điệp tin cậy giữa server và các tiến trình

• Xử lý tài liệu XML



Ta xét thuật ngữ Enterprise software (phần mềm doanh nghiệp). Đây là một

thuật ngữ được định nghĩa không chặt. Nói chung, ta định nghĩa các hệ thống mức doanh nghiệp bằng các yêu cầu và nhu cầu khi thực thi.

• Trong bất kỳ lĩnh vực và mức nào, các hệ thống doanh nghiệp thường phải chịu áp lực rất cao: xử lý hay lưu trữ nhiều dữ liệu, xử lý nhiều yêu cầu, thường là thường xuyên, nhiều công việc phải làm cho client. Hệ thống phải

có khả năng nâng cấp, và phải hoạt động có hiệu quả dưới áp lực cao.

• Hệ thống phải có tính sẵn sàng (available).

• Quản lý dữ liệu ứng dụng phải thỏa mãn tất cả tính chất của giao tác ACID: atomicity (tính nguyên tử), consistency (tính toàn vẹn), isolation (tính tách biệt), và durability (tính bền vững). Nói chung, điều này có nghĩa là

server phải hỗ trợ một chuẩn tin cậy rất cao trong việc xử lý dữ liệu.

• Các chức năng dữ liệu và ứng dụng phải an toàn (secure): điều này

bao gồm cần phải có xác thực, và chính sách cấp quyền. Truyền thông điệp giữa các thành phần phải đáng tin cậy (reliable) – điều

này cũng giống như tính ACID của giao tác, nhưng ở đây ta áp dụng cho các thông điệp của ứng dụng.

2.7 Kiến trúc Ba-tầng (Three-tier)

Một ứng dụng J2EE nên thực hiện theo kiến trúc ba tầng (three-tier

architecture), bởi vì nó sẽ phân chia rõ ràng trách nhiệm cho từng tầng khác nhau trong mô hình ứng dụng.

• Tầng trình diễn (presentation tier) chỉ đảm nhận phần biểu diễn thông tin đến server và thu thập dữ liệu nhập của người dùng. Nó không biết hoặc không quan tâm đến cách mà thông tin được phát sinh, mặc dù nó biết một số điều về “hình

dạng (shape)” của thông tin.

• Tầng luận lý nghiệp vụ (business logic tier) (hay đôi khi còn gọi là

“domain”, hay đơn giản là “tầng giữa (middle tier)” đảm nhận chức năng lõi của ứng dụng: các tính năng và các hàm để biên dịch hay thay đổi dữ liệu, các luật

Presentation Business Persistent

Data

Hình 7. Kiến trúc three-tier



phải được áp dụng cho dữ liệu khi nó thay đổi. Tầng này cung cấp cho tầng trình

diễn trước nó, và cũng là phương tiện cho việc lưu trữ và nhận dữ liệu của tầng sau nó.

• Tầng persistent quản lý lưu trữ bền vững và lấy dữ liệu ứng dụng. Tầng này có thể bao gồm mã chương trình cộng với hệ quản trị cơ sở dữ liệu quan hệ.

Mô hình mẫu có thể biểu diễn như hình dưới:

• JavaServer page và servlet, quản lý bởi một Web server J2EE, xác định tầng trình diễn – đây là giao diện do server quản lý.

• Một lớp xác định của Enterprise JavaBean được gọi là session bean thực hiện logic nghiệp vụ.

• JDBC là một loại khác của EJB, entity bean, quản lý dữ liệu trên các RDBMS.

Tuy nhiên client không dây (wireless client) là một dạng client đặc biệt. Nó

cần phải được server phục vụ đặc biệt: dữ liệu phải được xử lý đặc biệt cho loại client này.

2.8 Hỗ trợ các thiết bị MIDP thông qua tầng môi giới (Mediation)

Việc chuẩn bị đặc biệt dữ liệu từ tầng giữa để cho một dạng trình diễn đặc

biệt được gọi là sự môi giới (mediation). Tầng môi giới (mediator tier) là một tính năng thông thường của các hệ thống N-tầng, thường được triển khai để hỗ trợ việc

dùng nhiều khung (framework) trình diễn khác nhau cho cùng một tầng domain.

Web browser

Web server

JSPs, servlets

EJB Container

Session Beans

Entity Beans

RDB

Hình 8. Mô hình mẫu kiến trúc three-tier



Đối với các MIDP client, sự môi giới thường là ở dạng một gateway, biên dịch nội dung mức PC sang nội dung mức micro, và có thể xử lý chuyển đổi giao

thức, ví dụ như:

• Nội dung HTML có thể được biên dịch thành Wireless Markup Language, hay WML

• Giao thức cơ bản có thể chuyển từ HTTP sang Wireless Application Protocol hay WAP

• Các datagram sẽ không được cung cấp bằng User Datagram Protocol (UDP)

mà bằng Wireless Datagram Protocol hay WDP. Kiến trúc cuối cùng sẽ là một trong hai biến thể của kiến trúc N-tầng của

kiến trúc J2EE mà ta đã thấy ở trên.

• Mediation của domain:

• Mediation/Translation của tầng trình diễn:

MIDP client sẽ dựa nhiều vào phần mềm J2EE và các gateway hay tầng môi

giới để đơn giản hóa hay định dạng nội dung cho việc trình diễn và xử lý ở người dùng di động.

MIDlet Gateway JSPs Business Data

JSPs

Visual Basic application

Mediator Business Data

MIDlet Gateway

JSPs

Business Data

Hình 9. Vị trí của tầng môi giới

Hình 10. Môi giới của tầng domain

Hình 11. Môi giới của tầng trình diễn



3. Các vấn đề thiết kế ứng dụng doanh nghiệp không dây áp dụng công nghệ Java

3.1 Mô hình lập trình cơ bản

Hình 12 biểu diễn cấu trúc tổng quát của một ứng dụng doanh nghiệp không dây điển hình, bao gồm một thiết bị J2ME và một server J2EE.

Kiến trúc của một ứng dụng doanh nghiệp phục vụ các client không dây

cũng tương tự như của một ứng dụng J2EE chuẩn:

• Một client ứng dụng sử dụng MIDP hay được gọi là MIDlet client, cung cấp giao diện người dùng trên thiết bị di động. MIDlet giao tiếp với một Java servlet,

thường là thông qua HTTP, và trên một kênh truyền bảo mật khi cần thiết.

• Servlet dịch yêu cầu từ MIDlet, và tới lượt nó, gửi yêu cầu đến các thành

phần EJB. Khi các yêu cầu được thỏa mãn, servlet phát sinh một hồi đáp cho MIDlet.

• Các thành phần EJB, hay các enterprise beans, bao bọc logic nghiệp vụ của ứng dụng. Một trình chứa EJB cung cấp các dịch vụ chuẩn như giao tác, bảo mật, và quản lý tài nguyên để các nhà phát triển có thể tập trung vào việc thực hiện

logic nghiệp vụ. Các thành phần servlet và EJB có thể sử dụng các API bổ sung để truy xuất

dữ liệu và dịch vụ. Ví dụ, chúng có thể sử dụng JDBC API để truy xuất cơ sở dữ liệu quan hệ, hay JavaMail API để gửi e-mail cho người dùng.

Java/J2ME Client

LCDUI (User

Interface)

GCF (Networking)

MIDlet

RMS (Local Storage)

Java/J2EE Application Server

JDBC EJB Container

Java Connectors

Java Web Services

JMS

Java Mail

CORBA

JNDI

Servlet

EJB

EJB

EJB

EJB

EJB

(Secure) HTTP

Hình 12. Kiến trúc mức cao của một ứng dụng doanh nghiệp Java không dây



3.2 Hỗ trợ nhiều loại client

Nền tảng J2EE nhấn mạnh vào các thành phần có thể tái sử dụng. Ứng dụng có thể dùng các thành phần này để hỗ trợ nhiều loại client mà không (hay ít) ảnh

hưởng đến logic nghiệp vụ chính của ứng dụng. Hình 13 biểu diễn kiến trúc của một ứng dụng với client J2ME và client trình duyệt.

3.3 Các vấn đề khi thiết kế và thực hiện

Ta xem xét một số vấn đề khi thiết kế và thực hiện các ứng dụng doanh nghiệp không dây.

Xây dựng ứng dụng không dây có những ràng buộc đặc thù. Và khi thiết kế các ứng dụng không dây, ta sẽ gặp phải ba vấn đề sau: ràng buộc thiết kế (design

constraint), thông điệp (messaging), và trình diễn (presentation).

3.3.1 Ràng buộc thiết kế (Design Constraint)

Hạn chế của các thiết bị di động dẫn đến nhiều ràng buộc khi thiết kế các ứng dụng không dây. Các ứng dụng này phải cung cấp các giao diện có ích và tiện

lợi trong khi phải đối mặt với kích thước màn hình, khả năng nhập liệu, sức mạnh xử lý, bộ nhớ, lưu trữ, và thời gian sử dụng nguồn pin bị hạn chế.

Nhất là các ứng dụng doanh nghiệp không dây càng bị ràng buộc, bởi vì chúng dựa vào mạng. Các hạn chế do mạng di động ảnh hưởng đến ứng dụng di

động nhiều hơn so với trình duyệt Web thông thường. Nói chung, các thiết bị di

động sẽ gặp phải các vấn đề sau:

• Độ trễ cao

Java/J2ME Client

LCDUI (User

Interface)

GCF (Networking)

MIDlet

RMS (Local Storage)

Non-Java Client

Browser

Java/J2EE Application Server

Web Container

JDBC EJB Container

Java Connectors

Java Web Services

JMS

Java Mail

CORBA

JNDI

Servlet

EJB

EJB

EJB

EJB

EJB

(Secure) HTTP

Servlet

JSP (Secure) HTTP

Hình 13. Kiến trúc mức cao của một ứng dụng J2EE hỗ trợ client J2ME và client Brower



• Băng thông hạn chế

• Kết nối không liên tục

Để giải quyết các ràng buộc này, client MIDP có thể sử dụng các cách sau:

• Chỉ kết nối vào mạng khi cần thiết.

• Chỉ sử dụng dữ liệu đúng mức cần thiết.

Phải có khả năng sử dụng khi đã ngắt kết nối.

3.3.2 Truyền thông điệp

Mặc dù MIDP không có các cơ chế truyền thông client/server phức tạp, như Java Remote Method Invocation (RMI) hay Java API for XML-based Remote

Procedure Calls (JAX-RPC), các nhà phát triển vẫn có thể thiết kế một giao thức truyền thông điệp sử dụng định dạng và cách trao đổi theo ý mình.

Đối với hầu hết các ứng dụng, HTTP xứng đáng là một giao thức truyền thông điệp cơ bản, và nó được ưa chuộng hơn so với các phương thức truyền thông

khác (ví dụ như dựa trên socket hay datagram) vì các lý do sau đây:

• Tất cả các thiết bị MIDP phải hỗ trợ lập trình mạng MIDP. Do đó, các ứng dụng chỉ dựa vào HTTP sẽ có tính khả chuyển trên các thiết bị khác nhau. Mặt

khác, không phải tất cả các thiết bị MIDP đều hỗ trợ truyền thông dựa trên packet hay datagram, do đó các ứng dụng sử dụng các phương thức này không

bảo đảm tính khả chuyển.

• HTTP có khả năng bảo mật tường lửa (firewall). Hầu hết server được tách

biệt khỏi client di động bằng firewall, và HTTP là một trong số ít các giao thức mà hầu hết các firewall đều cho phép đi qua.

• Các API lập trình mạng của Java làm cho lập trình HTTP dễ dàng hơn. MIDP hỗ trợ HTTP 1.1 và các API để phát sinh các GET, POST và HEAD request, các thao tác header cơ bản, và cơ chế luồng cho thông điệp. Trong khi

đó, API cho Java servlet, cung cấp khả năng xử lý HTTP request và sinh các HTTP response khá mạnh.

Khi một MIDP client liên lạc với một Java servlet thì các sự việc sau xảy ra:

• Client mã hóa application request và đóng gói nó vào một HTTP request. Các Content-Type và Content-Length header phải được thiết lập để bảo đảm các

gateway trung gian xử lý request đúng đắn.

• Servlet nhận HTTP request và giải mã application request. Server hay một

thành phần khác (ví dụ như enterprise bean) thực hiện công việc xác định bởi application request.



• Servlet mã hóa application response và đóng gói nó vào một HTTP response. Content-Type và Content-Length header cũng phải được thiết lập đúng để bảo

đảm các gateway trung gian xử lý response đúng đắn. Client nhận HTTP response và giải mã application response chứa trong đó.

Client có thể thiết lập một hoặc nhiều đối tượng và thực hiện một số công việc trên các đối tượng cục bộ này.

Thiết kế định dạng thông điệp (Message Format)

Cách định dạng application request và response là tùy thuộc vào lập trình

viên. Các lựa chọn rơi vào hai cách sau:

Một cách là dùng định dạng nhị phân. Các thông điệp nhị phân có thể được

đọc và ghi sử dụng các lớp DataInputStream và DataOutputStream trong gói java.io.

Trên thực tế, sử dụng các thông điệp này đạt được hiệu quả trao đổi bởi vì tải được rút gọn. Chú ý rằng để tiết kiệm không gian, các thông điệp phải thỏa mãn

tính tự miêu tả (self-descriptive). Do đó, định dạng của thông điệp phải được biết cả ở client và server, và do đó chúng gắn chặt với nhau.

Cách khác là sử dụng Extensible Markup Language (XML). Trong khi nền

tảng J2EE cung cấp rất nhiều hỗ trợ cho XML (đặc biệt là trong Web service), thì

đặc tả MIDP không yêu cầu hỗ trợ XML, mặc dù các nhà phát triển có thể thêm hỗ

trợ XML vào ứng dụng MIDP bằng cách kết hợp các thư viện bổ sung.

Để phân tích và xử lý tài liệu XML, các nhà phát triển có thể lựa chọn nhiều

cách thực hiện, bao gồm hai mô hình xử lý phổ biến, Document Object Model (DOM) và Simple API for XML (SAX). (SAX và các bộ phân tích dựa trên sự kiện

khác thích hợp hơn DOM khi áp dụng cho các thiết bị di động với bộ nhớ và tốc độ xử lý bị hạn chế). Các thư viện RPC dựa trên XML cũng được cung cấp, bao gồm

các bộ phân tích dựa trên đặc tả Simple Access Object Protocol (SOAP).

Tuy nhiên khi sử dụng định dạng XML, ngoài việc chi phí cho kích thước và

băng thông, còn có chi phí không nhỏ về bộ nhớ, xử lý và lưu trữ.

Liên quan đến truyền thông điệp, ta có các vấn đề sau:

Liên lạc an toàn (Communicating Securely)

Các client MIDP có thể dựa vào một số cơ chế giống các cơ chế dùng để hỗ

trợ liên lạc an toàn giữa các ứng dụng J2EE và các client trình duyệt Web.



Server ứng dụng J2EE và nhiều thiết bị MIDP hỗ trợ HTTP trên Secure

Sockets Layer (SSL). Các thiết bị MIDP sử dụng secure HTTP để xác thực với server và tiến hành trao đổi an toàn với server đó. Khung kết nối tổng quát (Generic

Connection Framework) trong MIDP cho phép người lập trình mở kết nối secure HTTP chỉ đơn giản bằng cách gọi phương thức Connector.open() với URL bắt đầu

bằng https.

Để xác thực ở phía client, các MIDP client dựa vào việc xác nhận do ứng

dụng quản lý, có thể dựa vào cơ chế tự đăng ký. Nói cách khác, MIDP client gửi thông tin ủy nhiệm (ví dụ như tên đăng nhập và mật khẩu) đến ứng dụng J2EE, và

ứng dụng sẽ xác nhận các thông tin này, có thể bằng cách sử dụng cơ sở dữ liệu.

Quản lý lỗi

Khi server J2EE không thể thực hiện request cho MIDP client, nó cần phải

thông báo điều này cho client. Mặc dù chương trình của server có thể sử dụng cơ chế quản lý ngoại lệ của Java để xử lý lỗi cục bộ, nó không thể sử dụng cơ chế này

để thông báo lỗi cho MIDP client khi liên lạc trên mạng. Nói cách khác, lập trình viên không thể cài đặt một khối try-catch trong mã client để bắt trực tiếp ngoại lệ

được ném ra từ server. Thay vào đó, họ phải tổ chức một cơ chế thông báo lỗi vào giao thức truyền thông điệp của họ.

Một cách là dành một phần cố định trong mỗi response của ứng dụng cho một mã trạng thái thể hiện là request của ứng dụng có thành công hay không. Ví dụ,

khi sử dụng truyền thông điệp nhị phân, hai byte đầu tiên có thể dành cho mã trạng thái số nguyên. Khi sử dụng HTTP, các nhà phát triển ứng dụng có thể dùng mã

trạng thái của HTTP response để thể hiện thành công hay thất bại ở mức truyền thông. Ví dụ, mã trạng thái của 200 (“OK”) có thể dùng để chỉ thành công, trong

khi mã trạng thái 500 (“Internal Server Error”) có thể dùng để chỉ thất bại.

3.3.3 Các chiến lược về trình diễn (presentation)

Người dùng tương tác với ứng dụng càng tập trung và trực tiếp, thì người dùng càng có thể dễ dàng sử dụng. Điều này có ý nghĩa đặc biệt quyết định cho các

ứng dụng không dây do màn hình hiển thị và khả năng nhập liệu của các thiết bị di động bị hạn chế.

Các nhà phát triển có thể sử dụng một vài chiến lược để làm cho các ứng dụng không dây có kết nối mạng tăng tính hữu dụng hơn: thực hiện kiểm tra ở phía

client, cung cấp biểu thị diễn tiến, cho phép ngắt các hoạt động, và cá nhân hóa ứng dụng. Ta sẽ nghiên cứu các chiến lược này.



Thực hiện kiểm tra ở phía client

Việc kiểm tra nhập liệu ở phía client là một phương thức tốt để giảm việc gọi

đến server. Xét một form đặt hàng, có các trường thông tin thẻ tín dụng. Một

MIDlet có thể không thể kiểm tra thông tin này một mình nó được, nhưng chắc chắn

nó có thể áp đặt một số phương cách kiểm tra đơn giản để xác định thông tin đó có hợp lệ hay không. Ví dụ, nó có thể kiểm tra tên chủ thẻ không thể là null, hoặc chỉ

số thẻ phải có đủ các con số. Nếu dữ liệu nhập được qua các bước này, client sẽ chuyển chúng đến server. Server có thể xử lý các công việc phức tạp hơn, ví dụ như

kiểm tra số thẻ tín dụng đó có thật sự thuộc về chủ thẻ hay không hoặc chủ thẻ đó còn đủ tiền hay không.

Bằng cách thực hiện việc kiểm tra nhập liệu ở phía client, các MIDlet có thể tránh việc liên lạc không cần thiết đến server. Các MIDlet có thể chủ động hơn để

tránh việc nhập liệu không hợp lệ. Ví dụ có thể giới hạn việc nhập số điện thoại bằng cách sử dụng trường nhập ràng buộc số, do đó các số điện thoại không phải là

số sẽ không thể được gửi đến server.

Cung cấp biểu thị diễn tiến (process indicator)

Bởi vì các hoạt động kết nối mạng tốn nhiều thời gian, ứng dụng nên cung

cấp cho người dùng một thông tin phản hồi về diễn tiến của hoạt động đó. Ví dụ có thể đưa ra một hoạt hình hoặc gauge để biểu thị diễn tiến. Biểu thị diễn tiến này

dùng cho các hoạt động kéo dài, ví dụ như khi download danh sách các trường trên mạng.

Cho phép ngắt hoạt động

Cho phép người dùng có khả năng ngắt các hoạt động kéo dài giúp họ giữ

việc điều khiển ứng dụng. Các biểu thị diễn tiến có thể có thêm một nút nhấn ngừng. Biểu thị này sẽ lắng nghe sự kiện của nút nhấn ngừng, và khi nhấn nút

ngừng màn hình hiển thị sẽ ngay lập tức chuyển sang màn hình trước đây.

Cần chú ý rằng, không phải tất cả các hoạt động đều có thể dừng. Ví dụ,

không nên dừng việc tạo một tài khoản người dùng trên server và lưu lại trên client. Hai công việc này nên thực hiện như là một hoạt động chung hoặc là không thực

hiện cả hai. Nếu hoạt động bị ngắt, sẽ có thể dẫn đến sự không thống nhất giữa dữ liệu của client và server.

Cá nhân hóa ứng dụng

Khái niệm cá nhân hóa (personalization) chỉ khả năng một dịch vụ thích ứng với thông tin mà nó biết về người dùng. Thông thường, nhiều thông tin của người



dùng, chẳng hạn như địa chỉ, mã ZIP, hay màu sắc ưa thích, sẽ không thay đổi từ

phiên làm việc này sang phiên làm việc khác. Bởi vì các dữ liệu này là ổn định, ứng dụng có thể dùng nó để cá nhân hóa việc sử dụng của người dùng.

Việc cá nhân hóa một dịch vụ là có lợi vì hai lý do sau:

• Nó giảm việc yêu cầu nhập liệu. Người dùng sẽ chán nếu phải nhập đi nhập lại các thông tin này mỗi lần sử dụng dịch vụ.

• Nó sẽ rút ngắn dòng chảy công việc (workflow). Người dùng có thể nhập thông tin tài khoản vào lần đầu, và client sẽ giữ lại thông tin đăng nhập của họ.

Trong các lần sử dụng sau đó, người dùng có thể lựa chọn tự động đăng nhập mà không phải qua màn hình đăng nhập.

Trong khi trạng thái phiên làm việc có thể xem là thông tin tạm thời, thì dữ liệu cá nhân hóa sẽ có tính bền vừng. Lưu dữ liệu bền vững này ở đâu là tùy vào

người phát triển ứng dụng.

Khi quyết định lưu trữ dữ liệu cá nhân hóa, các nhà phát triển phải xem xét

các câu hỏi sau:

• Dữ liệu cá nhân hóa có thường xuyên ảnh hưởng đến client request không? Ví dụ, ứng dụng đặt vé sẽ liệt kê các rạp dựa vào mã vùng của người dùng.

Server lưu trữ mã vùng này, do đó client không cần phải gửi lại mã vùng mỗi lần nó gửi yêu cầu. Tuy nhiên cũng nên cho phép người dùng có thể bỏ qua mã vùng

này, ví dụ khi họ sang thăm một vùng khác.

• Thông tin cá nhân hóa có khả năng sử dụng giữa nhiều loại client hay không? Ví dụ, người dùng sử dụng ứng dụng đặt vé trên điện thoại di động có thể

muốn truy xuất cùng ứng dụng đó qua Web. Khi đó, họ có thể muốn dữ liệu cá nhân sẽ có sẵn để tránh việc nhập lại nó qua Web.

Quyết định nơi để lưu dữ liệu cá nhân hóa không phải luôn luôn là một quyết định lựa chọn một trong hai. Dữ liệu cá nhân hóa có thể được lưu chồng ở cả client

và server. Khi dữ liệu cá nhân hóa được lưu chồng trên cả client và server, ứng dụng có thể cần phải có thêm một số tính năng để đồng bộ hóa dữ liệu này. Các nhà

phát triển được khuyên là nên cân nhắc đến chi phí của việc thực hiện các tính năng này.



4. Bảo mật trong thương mại di động

4.1 Khái quát

Bảo mật thông tin luôn là vấn đề quan trọng hàng đầu trong các lĩnh vực tình

báo, quân sự, ngoại giao, và đây cũng là một vấn đề đã được nghiên cứu hàng nghìn năm nay. Nếu như các vấn đề liên quan đến các hoạt động tình báo và quân sự là

khá xa lạ với các doanh nghiệp thì việc bảo mật thông tin thương mại luôn là một vấn đề được đặt ra, đặc biệt trong thời đại hiện nay, khi mà thông tin giữ vai trò

quan trọng hàng đầu và các phương tiện truyền thông hiện đại cho phép chúng ta chuyển tin rất dễ dàng và cũng rất dễ dàng để mất thông tin. Vậy ta có thể làm

những gì để sử dụng được các tiện ích của công nghệ thông tin và viễn thông đã mang lại cho thế giới và đồng thời không để đối thủ cạnh tranh cũng như các loại

tội phạm tin học sử dụng chính những công nghệ này để gây hại. Tổng thể vấn đề bảo mật là một topic lớn, và với phạm vi của một đồ án thì không thể tìm hiểu hết được. Chính vì vậy, các khái niệm tìm hiểu sẽ liên quan chủ yếu đến các vấn đề bảo

mật chung của ứng dụng web-based bao gồm:

- Các khái niệm cơ bản về mã hóa.

- Tổng quan về bảo mật phần mềm (SSL, disgest, signature…).

- Khái niệm về Authorization, authentication.

Khi tạo một ứng dụng web-based, tất cả các thông tin trao đổi từ client có thể bị chặn lại. Các ứng dụng web-based sử dụng HTTP trên nền mạng TCP để truyền

thông tin và hầu hết các thông tin chỉ là dạng text đơn thuần. Điều này dẫn đến một số dạng tấn công chung:

1. Các thông tin nhạy cảm có thể bị chặn lại khi truyền từ client đến server ( bị

ăn trộm thông tin).

2. Thông tin trao đổi có thể bị chặn lại và bị thay đổi làm cho các thông tin sai lệch bị truyền từ client đến server (bị lừa gạt thông tin).

3. Tính xác thực nhận dạng của client và server có thể bị ăn cắp hoặc giả mạo cho phép ai đó có thể giả mạo client (bị mạo danh).

Để giải quyết các vấn đề trên thì cũng có các giải pháp tương ứng:

- Để tránh bị ăn trộm thông tin: Sử dụng mã hóa (Encryption).

- Để tránh bị lừa gạt và mạo danh: sử dụng việc xác thực (Authentication).



Một nhu cầu thiết yếu trong truyền tải dữ liệu đó là tính toàn vẹn dữ liệu

(data integrity), trong đó có 2 việc cần quan tâm là: che giấu dữ liệu (bảo vệ khỏi bị ăn trộm) và bảo vệ dữ liệu khỏi bị giả mạo.

Để che giấu dữ liệu:

- Encoding

- Encryption

- Symmetric Encryption

- Asymmetric Encryption

Để bảo vệ dữ liệu:

- Hashes/ Message disgest

- Digital Signature

- Digital Certificate

- Certificate Authorities

4.2 Mã hóa đối xứng (Symmetric Encryption)

Mã hóa là phương thức dùng để ám chỉ việc bảo vệ dữ liệu bằng cách thay đổi nó về dạng không thể hiểu được. Mã hóa đối xứng cũng được gọi là mã hóa

private key hay mã hóa secret key. Nó sử dụng một chìa khoá duy nhất để mã hoá và giải mã dữ liệu (được thể hiện dưới hình dưới). Khi một mã hóa đối xứng được

sử dụng cho files trên một ổ cứng, user thực hiện mã hoá với một secret key. Khi một giao tiếp được sử dụng mã hoá đối xứng, hai giao tiếp sẽ chia sẻ nhau cùng một

mật mã để mã hoá và giải mã gói tin.



Hình 14. Mã hóa đối xứng

Phương thức mã hóa đối xứng được thực hiện nhanh hơn rất nhiều so với quá

trình sử dụng mã hóa bất đối xứng. Với tốc độ nhanh nên thuật toán này được thiết kế chỉ một key trong quá trình mã hoá và giải mã dữ liệu.

Mã hóa đối xứng cung cấp một giải pháp mã hoá mạnh mẽ bảo vệ dữ liệu bằng một key lớn được sử dụng. Tuy nhiên, để bảo vệ các keys này ta luôn luôn

phải lưu giữ chúng và được gọi là private key. Nếu key này bị mất hay bị lộ, khi đó sẽ không đảm bảo tính bảo mật của dữ liệu nữa. (Tương tự như một ngôi nhà có một chiếc chìa khoá để khoá cửa, khoá của ngôi nhà có thể rất phức tạp và không

cưa nổi, nhưng điều gì sẽ xảy ra nếu kẻ trộm làm ra được một chiếc chìa khoá tương tự như vậy).

Và một tình huống khác đó là trong quá trình truyền thông tin của Key giữa

các máy tính … đó cũng là một vấn đề. Để sử dụng mật mã đối xứng để mã hoá các

giao tiếp giữa người A và người B trên internet, người A phải chắc một điều rằng việc bảo mật quá trình truyền keys trên mạng cần phải được đảm bảo. Nếu A chắc

chắn rằng việc truyền dữ liệu về key được đảm bảo, vậy A sử dụng phương thức mã hoá nào cho việc truyền key đó trên mạng. Giải pháp là key được truyền tới người B

không qua con đường internet, có thể chứa trong đĩa CD và chuyển theo đường bưu điện, hay viết tay gửi thư… Rồi người B và A sử dụng key đó để mã hoá dữ liệu và

giải mã trong quá trình truyền thông tin.

Tuy nhiên A có thể sử dụng một giải pháp thông minh hơn đó là Public Key

Infrastructure (PKI) giải pháp được sử dụng kết hợp với mã hóa đối xứng trong quá trình truyền thông tin keys. Việc truyền thông tin key bằng việc sử dụng một mã

hoá để truyền với sử dụng một phiên truyền thông tin duy nhất. Hiểu, sử dụng và



triển khai sử dụng PKI không đơn giản và có nhiều giải pháp của nhiều nhà sản xuất

khác nhau.

Mật mã đối xứng được chia làm hai dạng:

a. Block cipher

Block cipher là một giải pháp hoạt dộng chống lại sự hạn chế của dữ liệu

tĩnh. Dữ liệu được chia ra thành các blocks với size cụ thể và mỗi blocks được mã hoá một cách khác nhau.

b. Stream cipher

Stream cipher là giải pháp hoạt động chống lại dữ liệu luôn luôn sử dụng một

phương thức để truyền. Một vùng đệm, ít nhất bằng một block, đợi cho toàn bộ thông tin của block đó được chứa trong vùng đệm sau đó block đó sẽ được mã hoá

rồi truyền cho người nhận. Một sự khác nhau cơ bản giữa dữ liệu được truyền và dữ liệu nguyên bản. Không như giải pháp sử dụng mật mã đối xứng là mỗi block được sử dụng một key khác nhau trong quá trình truyền thông tin.

Dưới đây là các giải pháp mật mã đối xứng hay sử dụng nhất:

Bảng 2. Các thuật toán mã hóa đối xứng hay sử dụng

4.3 Mã hóa bất đối xứng (Asymmetric Encryption)

Mật mã bất đối xứng hay còn gọi là mã hoá sử dụng public key. Nó sử dụng

một cặp key đó là public key và private key thể hiển hình dưới đây. Trong mỗi quá trình truyền thông tin sử dụng mật mã bất đối xứng chúng cần một cặp key duy

nhất. Nó tạo ra khả năng có thể sử dụng linh hoạt và phát triển trong tương lai hơn là giải pháp mật mã đối xứng. Private key cần phải giữ riêng và đảm bảo tính bảo

mật và nó không truyền trên mạng. Public key được cung cấp miễn phí và được public cho mọi người.



Ví dụ, khi Alice muốn gửi thông tin cho Bob, Alice sử dụng public key của

Bob để mã hóa thông tin rồi gửi cho Bob. Khi Bob nhận thông tin đã được mã hóa của Alice sẽ giải mã thông tin bằng Pivate key của mình.

Mật mã bất đối xứng hoạt động chậm hơn phương thức mật mã đối xứng, không phải nó mã hoá một khối lượng dữ liệu lớn. Nó thường được sử dụng để bảo

mật quá trình truyền key của mật mã đối xứng. Nó cung cấp bảo mật cho quá trình truyền thông tin bằng các dịch vụ: Authentication, Integrity, Protection, và

Nonrepudiation.

Hình 15. Mã hóa bất đối xứng

Phương thức mật mã bất đối xứng sử dụng:

- Rivest Shamir Adleman (RSA)

- Diffie-Hellman

- Error Correcting Code (ECC)

- El Gamal

- Message Message



4.4 Mô hình Hybrid/Session key System

Hình 16. Mô hình Hybrid system

Để tận dụng được tốc độ của mã hóa đối xứng và sức mạnh của mã hóa bất đối xứng, ta sử dụng mô hình Hybrid system. Trong đó gồm 2 bước:

- Trao đổi khóa bí mật: Sử dụng mã hóa bất đối xứng để trao đổi khóa bí mật. Khóa do bên A sinh ra, được mã hóa bằng public key của B và gửi cho B, B

sử dụng private key của mình để giải mã và nhận khóa bí mật

- Trao đổi thông tin: Từ bước sau, khóa bí mật sẽ được dùng để trao đổi thông

tin, sử dụng mã hóa đối xứng.

Như vậy, mã hóa bất đối xứng sẽ chỉ phải sử dụng một lần, giúp làm tăng tốc

độ của hệ thống, tiết kiệm tài nguyên mà vẫn đảm bảo tính bảo mật của mã hóa bất đối xứng.

Sử dụng mô hình Hybrid system có thể chống lại được việc đánh cắp thông tin cũng như là che dấu thông tin, nhưng lại chưa chắc chắn được tính toán toàn vẹn

của thông tin. Một kẻ tấn công man-in-the-midle M có thể bắt được các gói tin mà A gửi cho B đồng thời dùng khóa công khai của B để giả mạo 1 gói tin khác và gửi

cho B. Để khắc phục điều này, hệ thống sử dụng MAC để đảm bảo tính toàn vẹn dữ liệu. MAC là một message digest được sinh ra khi dùng hàm băm 1 chiều băm bản

tin cùng với session key. MAC sẽ được gửi kèm theo gói tin và khi B nhận được cũng băm bản tin và session key để verify tính toàn vẹn dữ liệu.



Hình 17. Mô hình Hybrid System với MAC

Nên nhớ rằng Hybrid system không phải là thuốc chữa bách bệnh. Mô hình

Session key được coi là bảo mật hơn Hybrid system, trong đó client cũng có 1 cặp key công khai riêng, và khóa session được sinh từ 2 phía. Tức là khóa bí mật sẽ được sinh từ 2 thành phần, mỗi thành phần sẽ được một bên sinh ra. Điều này làm

tăng thêm tính bảo mật của khóa bí mật.



Public Key của B

Alice Bob

message messageMessage encrypted

Private Key của B

Public Key của B Private Key của B

Private Key của A Public Key của A

Session key Session key Session key

Session keySession key Session key

Public Key của APrivate Key của A

Session key Session key

AliceBob

Hình 18. Mô hình session key

- Bước 1 : quá trình trao đổi khóa (Key agreement)

A sinh key thứ nhất, dùng public key của B để mã hóa key rồi gửi cho B, B

dùng private key của mình để giải mã, lấy được key thứ nhất đồng thời sinh key thứ 2 rồi gửi cho A bằng cách dùng public key của A. A dùng private

key của mình, giải mã để lấy được key thứ 2. Như vậy, khóa session là kết hợp của 2 key thứ nhất và thứ 2.

- Bước 2 : quá trình trao đổi thông tin. Các thông tin sẽ được mã hóa bằng khóa bí mật.

4.5 Chữ kí số (Digital Signature)

Chữ ký số (chữ kí điện tử) là mô hình đảm bảo an toàn dữ liệu khi truyền trên mạng và được sử dụng để tạo chứng nhận điện tử trong các giao dịch điện tử

qua mạng Internet.



Chữ ký điện tử (digital signature) là đoạn dữ liệu ngắn đính kèm với văn bản

gốc để chứng thực tác giả của văn bản và giúp người nhận kiểm tra tính toàn vẹn của nội dung văn bản gốc.

Chữ ký điện tử được tạo ra bằng cách áp dụng thuật toán băm một chiều trên văn bản gốc để tạo ra bản phân tích văn bản (message digest) hay còn gọi là

fingerprint, sau đó mã hóa bằng private key tạo ra chữ ký số đính kèm với văn bản gốc để gửi đi. Khi nhận, văn bản được tách làm 2 phần, phần văn bản gốc được tính

lại fingerprint để so sánh với fingerprint cũ cũng được phục hồi từ việc giải mã chữ ký số (xem hình dưới).

Hình 19. Cách tạo chữ kí số

Các bước kiểm tra:

1. Dùng public key của người gửi (khóa này được thông báo đến mọi người) để giải mã chữ ký số của message.

2. Dùng giải thuật (MD5 hoặc SHA) băm message đính kèm.

3. So sánh kết quả thu được ở bước 1 và 2. Nếu trùng nhau, ta kết luận

message này không bị thay đổi trong quá trình truyền và message này là của người gửi.

4.6 Chứng nhận số (Digital Certificate) và tổ chức chứng nhận số

(Certificate Authority)

Hãy xem ví dụ A muốn gửi thông điệp cho B và mã hóa theo phương pháp khóa công khai. Lúc này A cần phải mã hóa thông điệp bằng public key của B.

Trường hợp public key bị giả mạo thì sao? Hacker có thể tự sinh ra một cặp khóa public key/private key, sau đó đưa cho A khóa public key này và nói đây là khóa



public key của B. Nếu A dùng public key giả này mà tưởng là của B thì dẫn đến hệ

quả mọi thông tin A truyền đi đều bị hacker đọc được.

Vấn đề này được giải quyết nếu có một bên thứ ba được tin cậy, gọi là C,

đứng ra chứng nhận public key. Những public key đã được C chứng nhận gọi là chứng nhận điện tử (public key certificate hay digital certificate).

Hình 20. Chứng nhận số

Một chứng nhận điện tử có thể được xem như là một “hộ chiếu” hay “chứng minh thư”. Nó được một tổ chức tin cậy (như VeriSign, Entrust, CyberTrust, v.v...)

tạo ra. Tổ chức này được gọi là tổ chức chứng nhận khóa công khai Certificate Authority (CA). Một khi public key đã được CA chứng nhận thì có thể dùng khóa

đó để trao đổi dữ liệu trên mạng với mức độ bảo mật cao.

Cấu trúc của một chứng nhận điện tử gồm các thành phần chính như sau:

Issuer: tên của CA tạo ra chứng nhận.

Period of validity: ngày hết hạn của chứng nhận.

Subject: bao gồm những thông tin về thực thể được chứng nhận.

Public key: khóa công khai được chứng nhận.

Signature: do private key của CA tạo ra và đảm bảo giá trị của chứng nhận.

4.7 Public key infrastructure (PKI)

Trong mật mã học, hạ tầng khóa công khai (tiếng Anh: Public key infrastructure, viết tắt PKI) là một cơ chế để cho một bên thứ 3 (thường là nhà cung

cấp chứng thực số) cung cấp và xác thực định danh các bên tham gia vào quá trình trao đổi thông tin. Cơ chế này cũng cho phép gán cho mỗi người sử dụng trong hệ



thống một cặp khóa công khai/khóa bí mật. Các quá trình này thường được thực

hiện bởi một phần mềm đặt tại trung tâm và các phần mềm phối hợp khác tại các địa điểm của người dùng. Khóa công khai thường được phân phối trong chứng thực

khóa công khai.

Khái niệm hạ tầng khóa công khai (PKI) thường được dùng để chỉ toàn bộ hệ

thống bao gồm nhà cung cấp chứng thực số (CA) cùng các cơ chế liên quan đồng thời với toàn bộ việc sử dụng các thuật toán mật mã hóa khóa công khai trong trao

đổi thông tin. Tuy nhiên phần sau được bao gồm không hoàn toàn chính xác bởi vì các cơ chế trong PKI không nhất thiết sử dụng các thuật toán mã hóa khóa công

khai.

PKI cho phép những người tham gia xác thực lẫn nhau và sử dụng thông tin

từ các chứng thực khóa công khai để mật mã hóa và giải mã thông tin trong quá trình trao đổi. Thông thường, PKI bao gồm phần mềm máy khách (client), phần mềm máy chủ (server), phần cứng (như thẻ thông minh) và các quy trình hoạt động

liên quan. Người sử dụng cũng có thể ký các văn bản điện tử với khóa bí mật của

mình và mọi người đều có thể kiểm tra với khóa công khai của người đó. PKI cho

phép các giao dịch điện tử được diễn ra đảm bảo tính bí mật, toàn vẹn và xác thực lẫn nhau mà không cần phải trao đổi các thông tin mật từ trước.

Hầu hết các hệ thống PKI quy mô doanh nghiệp đều dựa trên các chuỗi chứng thực để xác thực các thực thể. Chứng thực của người dùng sẽ được một nhà

cung cấp chứng thực số cấp, đến lượt nhà cung cấp này lại có chứng thực được một nhà cung cấp khác ở cấp cao hơn tạo ra... Hệ thống sẽ bao gồm nhiều máy tính

thuộc nhiều tổ chức khác nhau với các gói phần mềm tương thích từ nhiều nguồn khác nhau. Vì vậy, các tiêu chuẩn là yếu tố rất quan trọng đối với hoạt động của các

PKI. Hầu hết các tiêu chuẩn về PKI hiện tại được soạn thảo bởi nhóm làm việc PKIX của IETF.

Các hệ thống PKI doanh nghiệp thường được tổ chức theo mô hình danh bạ trong đó khóa công khai của mỗi người dùng được lưu trữ (bên trong các chứng

thực số) kèm với các thông tin cá nhân (số điện thoại, email, địa chỉ, nơi làm việc...). Hiện nay, công nghệ danh bạ tiên tiến nhất là LDAP và định dạng chứng

thực phổ biến nhất (X.509) cũng được phát triển từ mô hình tiền nhiệm của LDAP (X.500).

4.8 One time password (OTP)

Xuất hiện từ đầu thế kỉ 20 và còn có tên gọi khác là Vernam Cipher, OTP

được mệnh danh là cái chén thánh của ngành mã hóa dữ liệu. OTP là thuật toán duy



nhất chứng minh được về lý thuyết là không thể phá được ngay cả với tài nguyên vô

tận (tức là có thể chống lại kiểu tấn công brute-force). Để có thể đạt được mức độ bảo mật của OTP, tất cả những điều kiện sau phải được thỏa mãn:

- Độ dài của chìa khóa phải đúng bằng độ dài văn bản cần mã hóa.

- Chìa khóa chỉ được dùng một lần.

- Chìa khóa phải là một số ngẫu nhiên thực.

Mới nghe qua có vẻ đơn giản nhưng trong thực tế những điều kiện này khó

có thể thỏa mãn được. Giả sử Alice muốn mã hóa chỉ 10MB dữ liệu bằng OTP, cô ta phải cần một chìa khóa có độ dài 10MB. Để tạo ra một số ngẫu nhiên lớn như vậy

Alice cần một bộ tạo số ngẫu nhiên thực (TRNG - True Random Number Generator). Các thiết bị này sử dụng nguồn ngẫu nhiên vật lý như sự phân rã hạt

nhân hay bức xạ nền vũ trụ. Hơn nữa việc lưu trữ, chuyển giao và bảo vệ một chìa khóa như vậy cũng hết sức khó khăn.

OTP ngày nay được sử dụng rộng rãi và khá quen thuộc trong các giao dịch

điện tử. Ví dụ một giao dịch chuyển tiền qua điện thoại thì trước khi giao dịch được

thực hiện, người dùng sẽ được nhận một tin nhắn có chứa mã OTP, sau đó người

dùng phải điền OTP vào form có sẵn và gửi lên server để xác thực.

5. Các chuẩn trong thương mại điện tử Khi thiết kế, xây dựng một hệ thống thì việc xây dựng đảm bảo sao cho nó

phù hợp với các chuẩn của quốc tế là một điều quan trọng. Các chuẩn cũng chính là

một trong những thước đo hệ thống…

5.1 Chuẩn đóng gói bản tin giao tiếp ISO 8583

ISO 8583 là chuẩn quốc tế quy định đặc tả của bản tin trao đổi giữa các hệ thống ngân hàng, tài chính trong giao dịch điện tử. Việc sử dụng chung một chuẩn

đóng gói bản tin sẽ dễ dàng trong việc giao tiếp, trao đổi thông tin, dữ liệu giữa các ngân hàng và tổ chức tài chính.

Để xây dựng và đóng gói bản tin ISO 8583 trong JAVA, thư viện JPOS hỗ trợ khá đầy đủ và dễ dàng triển khai.

ISO 8583 định nghĩa định dạng bản tin và luồng giao tiếp giúp các hệ thống khác nhau có thể trao đổi thông tin. Mặc dù ISO 8583 định nghĩa một chuẩn chung,

nhưng nó không đặc trưng cho một mạng hay một hệ thống nào cả. Thay vào đó, mỗi một mạng hay hệ thống sẽ sử dụng chuẩn này để xây dựng tùy biến các trường,

các cách sử dụng. Một bản tin ISO 8583 được chia làm 3 phần:



- Message Type Indicator (MTI) : chỉ định dạng thông điệp

- Một hoặc nhiều BITMAP, dùng để chỉ định phần tử dữ liệu nào thể hiện

- Các phần tử dữ liệu, chính là các trường của bản tin

a. Message Type Indicator (MTI)

Đây là một trường gồm 4 số dùng để phân chia các chức năng mức cao của

thông điệp. Một MTI chỉ ra phiên bản ISO 8583, lớp thông tin (Message class), chức năng của thông tin (Message Function), và nguồn gốc thông tin (Message

Origin). Ví dụ một MTI 0210 sẽ cho ta biết các thông tin sau:

0xxx -> phiên bản ISO 8583 (1987 version)

X2xx -> lớp thông tin (bản tin tài chính )

xx1x -> chức năng của thông tin (Request Response)

xxx0 -> khởi nguồn của thông tin (Acquirer)

ISO 8583 version

Vị trí thứ nhất trong MTI, chỉ ra phiên bản ISO 8583 sử dụng:

Vị trí Ý nghĩa

0xxx ISO 8583-1:1987 version



9xxx Sử dụng cá nhân

Bảng 3. MIT

Message class

Vị trí thứ 2 trong MTI, chỉ ra mục đích của bản tin:

Vị trí Ý nghĩa

x1xx Authorization Message

x2xx Financial Message

x3xx File Actions Message

x4xx Reversal Message

x5xx Reconciliation Message

x6xx Administrative Message

x7xx Fee Collection Message



x8xx Network Management Message

x9xx Reserved by ISO

Bảng 4. Message class

Message function

Vị trí thứ 3 trong MIT, chỉ ra chức năng của thông tin, là cái mà định nghĩa

luồng thông tin sẽ được xử lý như thế nào trong hệ thống.

Vị trí Ý nghĩa

xx0x Request

xx1x Request Response

xx2x Advice

xx3x Advice Response

xx4x Notification

xx8x Response acknowledgment

xx9x Negative acknowledgment

Bảng 5. Message function

Message origin

Vị trí thứ 4 trong MTI, chỉ ra nơi khởi nguồn của thông tin:

Vị trí Ý nghĩa

xxx0 Acquirer

xxx1 Acquirer Repeat

xxx2 Issuer

xxx3 Issuer Repeat

xxx4 Other

xxx5 Other Repeat

Bảng 6. Message origin

b. BITMAP

Trong ISO 8583, một BITMAP là một trường hay một trường con trong bản tin, có chức năng chỉ ra các yếu tố, các thành phần dữ liệu được chỉ ra trong bản tin.



Một bản tin ISO sẽ có ít nhất 1 BITMAP, được gọi là PRIMARY BITMAP, được

dùng để chỉ ra các trường từ 1 đến 64. Bitmap có thể được truyền đi dưới dạng 8bytes dữ liệu nhị phân, hoặc 16 kí tự hexa.

Một trường chỉ được thể hiện khi nó được chỉ định trong 1 bit của BITMAP là true. Ví dụ, byte “82x có dạng binary là ‘1000 0010’ sẽ chỉ ra rằng trường 1 và 7

sẽ được thể hiện trong bản tin, còn các trường 2,3,4,5,6,8 sẽ không được thể hiện”.

c. Data Elements

Data elements là các trường trong bản tin ISO, chỉ ra các thông tin về giao dịch. Mỗi data element có một ý nghĩa và một định dạng khác nhau.

5.2 Chuẩn bảo mật hệ thống thông tin ISO 27001

Tổ chức Tiêu chuẩn hoá quốc tế (ISO) đã ban hành ISO 27001 vào tháng 10

năm 2005. Về cơ bản, ISO 27001 - Hệ thống quản lý an ninh thông tin - phần bổ sung của tiêu chuẩn ISO/IEC 17799 “mã thực hành”; ISO/IEC 17799 lần đầu tiên được ban hành dưới tiêu chuẩn BS 7799-1. Hai tiêu chuẩn này hòa hợp và liên quan

mật thiết với nhau.

Tiêu chuẩn ISO 27001 đưa ra các yêu cầu cho việc xây dựng, áp dụng, điều

hành, kiểm tra, giám sát và phát triển hệ thống an ninh thông tin một cách tòan diện và khoa học.

ISO/IEC 17799 nêu cụ thể số lượng kiểm soát an ninh đơn lẻ, được lựa chọn và áp dụng như một phần của hệ thống an ninh thông tin.

ISO 27001 qui định những yêu cầu đối với hệ thống an ninh thông tin, khác biệt với ISO/IEC 17799 là được điều chỉnh một số điều cần thiết phù hợp với nhu

cầu của doanh nghiệp, là cơ sở để xem xét đánh giá cấp chứng chỉ của tổ chức bên thứ ba.

ISO 17021: 2006, đánh giá sự phù hợp – các yêu cầu đối với cơ quan cung cấp đánh giá và chứng nhận hệ thống quản lý, không những đưa ra các chuẩn mực

tương ứng đối với các cơ quan chứng nhận hệ thống quản lý chất lượng và môi trường, mà còn liên quan đến tiêu chuẩn về an tòan thực phẩm (ISO 22000), an toàn

chuỗi cung ứng (ISO/PAS 28000: 2005) cũng như liên quan đến bất cứ tiêu chuẩn nào sẽ được xây dựng trong tương lai.

ISO 27001 được xây dựng hòa hợp , tương thích với các hệ thống quản lý

khác như : ISO 9001: 2000 và ISO 14001: 2004 và đã có ảnh hưởng trên phạm vi

toàn cầu.



5.2.1 Khái niệm về ISO 27001:2005

ISO 27001 là tiêu chuẩn về hệ thống quản lý an ninh thông tin (ISMS–Information Security Management System) do Tổ chức tiêu chuẩn hoá quốc tế

(ISO) phát triển và ban hành . Tiêu chuẩn cung cấp một mô hình để thiết lập, áp dụng, vận hành, giám sát, xem xét, duy trì, cải tiến Hệ thống ISMS và có thể áp

dụng cho hầu hết mọi loại hình tổ chức như : các tổ chức kinh doanh – thương mại, Chính phủ, tổ chức phi lợi nhuận.

5.2.2 Lợi ích của việc áp dụng ISO 27001:2005

- Chứng tỏ cam kết đảm bảo về an ninh thông tin ở mọi cấp độ trong tổ chức

- Đảm bảo tính sẵn sàn tin cậy của phần cứng và các cơ sở dữ liệu

- Bảo mật thông tin, tạo niềm tin cho đối tác và khách hàng

- Giảm thiếu rủi ro gặp phải

- Nhanh chóng khắc phục các sự cố xẩy ra

- Giảm giá thành và các chi phí bảo hiểm

- Nâng cao nhận thức và trách nhiệm của tất cả các nhân viên về an ninh

thông tin.

5.2.3 Cấu trúc của bộ tiêu chuẩn ISO 27000

- Bộ tiêu chuẩn ISO 27001 : 2005 bao gồm :

- ISO 27000 – Các nguyên tắc và từ vựng

- ISO 27001 – Các yêu cầu của hệ thống quản lý an ninh thông tin

- ISO 27002 – (ISO/IEC 17799 – Mã thực hành)

- ISO 27003 - Hướng dẫn áp dụng Hệ thống quản lý an ninh thông tin

- ISO 27004 – Đo lường Hệ thống quản lý an ninh thông tin

- ISO 27005 - Quản lý rủi ro Hệ thống quản lý an ninh thông tin

- ISO 27006 – 27010 sẽ lần lượt xây dựng, ban hành

- ISO 17021 – Đánh giá sự phù hợp

5.2.4 Các yêu cầu của tiêu chuẩn quốc tế ISO 27001:2005

- Hệ thống quản lý an ninh thông tin

- Trách nhiệm lãnh đạo



- Đánh giá nội bộ Hệ thống ISMS

- Xem xét của lãnh đao về Hệ thống ISMS

- Cải tiến Hệ thống ISMS

Kèm theo phụ lục quan trọng về kiểm soát các mục tiêu gồm 11 nhóm yếu tố sau :

- Chính sách an ninh

- Tổ chức an ninh

- Quản lý tài sản

- An ninh nguồn nhân lực

- An ninh môi trường và vật lý

- Quản lý hoạt động và truyền thông

- Kiểm soát truy cập

- Thu nạp, phát triển và duy trì Hệ thống ISMS

- Quản lý sự cố an ninh thông tin

- Quản lý tính liên tục trong kinh doanh

- Sự tuân thủ

5.2.5 Các bước chủ yếu xây dựng và áp dụng ISO 27001:2005

- Cam kết thực hiện dự án của lãnh đạo

- Thành lập Ban chỉ đạo ANTT

- Khảo sát đánh giá thực trạng Hệ thống hiện hành

- Đào tạo nhận thức về ISO 27001

- Đào tạo viết tài liệu

- Đưa ra chính sách mục tiêu và phạm vi an ninh thông tin

- Phân tích, đánh giá rủi ro trong phạm vi của Hệ thống ISMS

- Lựa chọn mục tiêu, biện pháp kiểm soát phù hợp để thực thi

- Áp dụng thử

- Đào tạo chuyên gia đánh giá nội bộ

- Tiến hành đánh giá nội bộ



- Hoàn chỉnh hệ thống tài liệu

- Tiến hành đánh giá thử

- Khắc phục, phòng ngừa sự không phù hợp

- Đánh giá chứng nhận

- Duy trì, cải tiến Hệ thống sau chứng nhận

5.3 PKCS

PKCS (tiếng Anh: Public Key Cryptography Standards) là một chuẩn do

phòng thí nghiệm RSA Data Security Inc phát triển. Nó dựa vào các cấu trúc ASN.1 và thiết kế cho phù hợp với chứng chỉ X.09, các tiêu chuẩn này do ANSI thiết kế,

theo đó dữ liệu được chia thành từng khối nhỏ nhất là 8 bit (octet). PKCS hiện tại bao gồm các chuẩn PKCS#1, PKCS#3, PKCS#5,PKCS#7, PKCS#8, PKCS#9,

PKCS#11, PKCS#12, PKCS#13, PKCS#15. Hiện tại phiên bản của các bản đang là 2.1. Trong đó có thể tìm được các chuẩn để mã hóa dữ liệu, chuẩn này được thiết kế dựa vào cách mà các thám mã dùng để tấn công vào đoạn mã. Có thể mô tả sơ qua

thế này, trong PKCS#1 có các chuẩn mã hóa - giải mã RSAES - OAEP scheme, chuẩn tạo chữ ký điện tử - kiểm tra RSASSA - PSS scheme ver2.1, hay trong

PKCS#7 là các chuẩn mã hóa cho password. PKCS#11 là phức tạp nhất, nó là chuẩn cho việc truyền thông tin trên mạng dưới dạng các gói tin đã mã.

Các chuẩn PKCS

Version Tên Giải thích

PKCS

#1

2.1 RSA Cryptography

Standard

Xem thêm trong RFC 3447. Định nghĩa các thộc

tính toán học cà định dạng của các khóa RSA

public, private, và các giải thuật cơ bản, các sơ

đồ encoding/padding để thực thi mã hóa, giải mã, chữ kí RSA.

PKCS #2

- (đã được rút lại) Không còn được phát triển nữa. Nó bao phủ về việc mã hóa RSA của message disgest, nhưng đã

được nhập vào PKCS #1.

PKCS #3

1.4 Diffie-Hellman Key Agreement

Standard

Là một phương thức mã hóa cho phép 2 bên có thể giao tiếp với nhau chia sẻ khóa bí mật mà

không cần biết về nhau thông qua kênh giao tiếp

không an toàn.

PKCS

#4

- (đã được rút lại) Không còn được phát triển nữa. Nó đã được

nhập vào PKCS #1.PKCS #1.



PKCS

#5

2.0 Password-based

Encryption

Standard

xem thêm trong RFC 2898 và PBKDF2.

PKCS

#6

1.5 Extended-

Certificate Syntax

Standard

Định nghĩa các mở rộng trong đặc tả cũ của

chứng nhận X.509.

PKCS

#7

1.5 Cryptographic

Message Syntax

Standard

xem thêm trong RFC 2315. Cách sử dụng kí

(sign) hoặc mã hóa thông tin thông qua PKI. Đã

được cập nhật trong Cryptographic Message Syntax Standard (CMS).

PKCS #8

1.2 Private-Key Information Syntax

Standard.

xem thêm trong RFC 5208. Dùng để trao đổi, di chuyển private certificate keypairs (đã được mã

hóa hoặc không).

PKCS #9

2.0 Selected Attribute Types

Định nghĩa các loại thuộc tính đã được lựa chọn trong các chứng nhận mở rộng PKCS #6, các

bản tin được kí số PKCS #7, các thông tin về

private key PKCS #8, và các yêu cầu certificate-

signing PKCS #10.

PKCS

#10

1.7 Certification

Request Standard

Xem thêm trong RFC 2986. Định dang bản tin

gửi đến một tổ chức chứng thực để yêu cầu chứng nhận số.

PKCS

#11

2.20 Cryptographic

Token Interface (Cryptoki)

Một tập API định nghĩa một interface chung cho

các token mã hóa (có thể là các Hardware Security Module).

PKCS

#12

1.0 Personal

Information Exchange Syntax

Standard

Định nghĩa định dang chung của 1 file dùng để

lưu trữ private keys cùng với các chứng nhận số, được bảo vệ bởi khóa bí mật.

PKCS #13

– Elliptic Curve Cryptography

Standard

(đang trong quá trình phát triển)

PKCS

#14

– Pseudo-random

Number Generation

(đang trong quá trình phát triển)

PKCS #15

1.1 Cryptographic Token Information

Format Standard

Định nghĩa một chuẩn cho phép người dung các yếu tố mã hóa token để nhận dạng các ứng dụng

của họ, độc lập với phần thực thi Cryptoki của

ứng dụng (PKCS #11) hay các API khác.

Bảng 7. Tổng quan về PKCS



5.4 FIPS (Federal Information Processing Standards): Tiêu chuẩn xử lý

thông tin liên bang.

5.4.1 FIPS 140-1: Security Requirements for Cryptographic Modules

• Tên tiêu chuẩn: Các yêu cầu an toàn đối với module mật mã

• Số hiệu tiêu chuẩn: FIPS 140-1

• Ngày ban hành:01/1994.

• Phạm vi sử dụng: Dùng để đánh giá các module mật mã sử dụng bởi các thiết

bị xử lý thông tin. Tiêu chuẩn này đánh giá một module mật mã đạt một trong bốn lớp đảm bảo an toàn từ thấp đến cao: Level 1, Level 2, Level 3 và Level 4.

Hiện tiêu chuẩn này đã được thay thế bởi FIPS 140-2 và trong tương lai sẽ là FIPS 140-3.

• Tham khảo chi tiết: FIPS 140-1.

o Tại http://csrc.nist.gov/publications/fips/fips140-1/fips1401.pdf

• Ghi chú: Những ai phát triển sản phẩm IS có sử dụng đến module mật mã đều cần quan tâm đến tiêu chuẩn này.




• Ngày ban hành:05/2001.

• Phạm vi sử dụng: Dùng để đánh giá các module mật mã sử dụng bởi các thiết bị xử lý thông tin. Tiêu chuẩn này đánh giá một module mật mã đạt một trong

bốn lớp đảm bảo an toàn từ thấp đến cao: Level 1, Level 2, Level 3 và Level 4. FIPS 140-2 là bản tiêu chuẩn chính thức hiện đang sử dụng và trong tương lai sẽ

được thay thế bởi FIPS 140-3.

• Tham khảo chi tiết: - FIPS 140-2.

o Tại: http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

• Ghi chú: Những ai phát triển sản phẩm IS có sử dụng đến module mật mã

đều cần quan tâm đến tiêu chuẩn này.






• Ngày ban hành:13/07/2007.

• Phạm vi sử dụng: Dùng để đánh giá các module mật mã sử dụng bởi các thiết bị xử lý thông tin. Đây đang là bản Draft nên chưa nghiên cứu kỹ về nội dung.

• Tham khảo chi tiết: - FIPS 140-3.

o Tại: http://csrc.nist.gov/publications/PubsDrafts.html#FIPS-140--3

• Ghi chú: Những ai phát triển sản phẩm IS có sử dụng đến module mật mã đều cần quan tâm đến tiêu chuẩn này.



Chương 3. PHÂN TÍCH HỆ THỐNG

Xây dựng demo dịch vụ mobile wallet nhằm chứng minh tính thực tiễn của đề tài, hướng tới mục tiêu xây dựng và cung cấp dịch vụ sau này, tạo sự thuận tiện

cho người dùng khi thanh toán một số dịch vụ, giảm tải cho hệ thống tiền tệ, góp phần phát triển nền tài chính không phải tiền mặt. Trong đó, bao gồm các dịch vụ

cơ bản và thiết yếu sau:

- Nạp tiền vào tài khoản, chuyển tiền từ tài khoản ngân hàng này sang

tài khoản ngân hàng khác, từ số thuê bao điện thoại này sang số thuê bao điện thoại khác.

- Thanh toán và tra cứu thông tin thanh toán các dịch vụ viễn thông (ADSL, HomePhone, Mobile Post-Paid, Mobile Pre-Paid, Mua hàng) thông qua điện thoại di động

Hệ thống được xây dựng qua tham khảo các chức năng, nghiệp vụ của các nhà cung cấp dịch vụ mobile wallet đã có trên thị trường như mobivi, payplus…

hay các dịch vụ mobile banking của các ngân hàng MB, Vietcombank…

1. Chức năng của hệ thống Mô hình phân rã chức năng trên điện thoại:



Login

MobileWallet

Chuyen tien

Nap tienTra cuu

TKThanh toan

Cuoc vien thong

GDichTien mat

Cai dat Ho tro

VDT –VDT

VDT – TK NH

VDT –CMND

The caoNap tien

mat

Rut tien mat

Tra truoc

Tra sau

HomePhone

ADSL

Y/C thanh toan

Tra cu so du

Tra cuu GD

Kich hoat VDT

Doi PIN

Doi MK

Khoa the

HDSD

Danh muc NH

Phi dich vu

Khac Mo the

Ngon ngu

Dich vu

Hình 21. Mô hình phân rã chức năng trên điện thoại

1.1 Chức năng đăng nhập

1.1.1 Thông tin chung chức năng

Tên chức năng Đăng nhập trên ứng dụng – Login

Mô tả

Trước khi sử dụng các chức năng trên ứng dụng, KH phải đăng nhập bằng MK trên ứng dụng, mặc định ban đầu khi KH đăng ký là 123456, sau đó KH có thể đổi MK (sẽ được lưu lại trên

ứng dụng) và KH phải nhớ MK. Những lần đăng nhập sau KH phải đăng nhập bằng MK KH đã đổi

Tác nhân Khách hàng

Điều kiện trước KH vào ứng dụng M-Wallet trên điện thoại, chức năng này được kích hoạt lên trên điện thoại

Điều kiện sau ứng dụng sẽ hiển thị đầy đủ menu chức năng cho KH sử dụng

Ngoại lệ N/A

Các yêu cầu đặc biệt N/A

1.1.2 Biểu đồ luồng xử lý chức năng



Đăng nhập

Điện thoại

Bắt đầu

Nhập mật khẩu ứng dụng

Xác nhận

Kiểm tra MK

Hiển thị menu chức năng trên

điện thoại

Kết thúc

Y

YN

N

Hình 22 Luồng xử lý chức năng đăng nhập

1.1.3 Mô tả dòng sự kiện chính (Basic flow)

� Bước 1: KH vào ứng dụng trên điện thoại, ứng dụng sẽ yêu cầu KH nhập mật khẩu. Nếu là lần đầu tiên thì KH sử dụng mật khẩu mặc đinh

được cung cấp khi tải ứng dụng là 123456

� Bước 2: KH nhập MK, chọn OK(Đồng ý) để xác nhận và sang bước tiếp

theo hoặc chọn Cancel (Hủy) để kết thúc.

� Bước 3: Ứng dụng sẽ so sánh MK KH nhập và MK được lưu trên điện

thoại:



o Nếu sai sẽ thông báo lỗi trên màn hình Mobile theo ngôn ngữ

được thiết lập mặc định trên ứng dụng

o Nếu trùng khớp thì lấy thông tin ngôn ngữ mặc định lưu trong

RMS ra

� Bước 4: Hiển thị tất cả các chức năng theo ngôn ngữ, kết thúc nghiệp vụ

1.1.4 Mô tả dòng sự kiện phụ (Alternative Flow)

� KH chọn “Cancel” để hủy tiếp tục: thoát ra khỏi ứng dụng “M-Wallet”

� Tại bất kỳ màn hình nhập liệu nào đều có nút “Back”, khi KH không nhập liệu mà bấm nút “Back” thì ứng dụng sẽ trở về màn hình trước đó

� Ứng dụng kiểm tra MK không hợp lệ: ứng dụng hiển thị thông báo lỗi tương ứng và nút “OK”. KH bấm OK thì STK quay lại màn hình “Nhập

mật khẩu”. Thông báo lỗi tương ứng: “Sai mat khau truy cap”.

1.2 Chức năng chuyển tiền VĐT – VĐT


Tên chức năng Chuyển tiền VĐT – VĐT

Mô tả Cho phép KH chuyển tiền từ TK VĐT của KH đến TK VĐT

của KH thụ hưởng


Điều kiện trước

KH chuyển tiền đã đăng ký dịch vụ VĐT và kênh thanh toán trên Mobile của KH chuyển tiền ở trạng thái hoạt động

KH nhận tiền đã đăng ký dịch vụ VĐT và VĐT đang ở trạng

thái hoạt động

Điều kiện sau Số dư TK VĐT KH chuyển tiền giảm đi số tiền

Số dư TK VĐT KH thụ hưởng tăng lên số tiền chuyển

Ngoại lệ N/A

Các yêu cầu đặc biệt N/A




Hình 23. Luồng xử lý chức năng chuyển tiền VĐT –VĐT



1.2.3 Mô tả dòng sự kiện chính (Basic Flow)

� Bước 1: KH vào chức năng chuyển tiền từ VĐT – VĐT trên ứng dụng, ứng dụng hiển thị lần lượt các thông tin yêu cầu KH nhập để chuyển tiền:

o Số Mobile KH thụ hưởng (có đăng ký sử dụng dịch vụ VĐT trên Mobile)

o Số tiền

o PIN

� Bước 2: Ứng dụng hiển thị thông tin xác nhận cho KH: "Xac nhan chuyen <AMOUNT> VND cho thue bao <RECV_MSISDN>"

� Bước 3: KH xác nhận thực hiện giao dịch:

o Đồng ý: Sau KH xác nhận, ứng dụng chuyển thông tin sang Mobile gateway để xác minh số Mobile gửi và Mobile nhận.

o Không đồng ý: Ứng dụng trở về menu chính (sau khi đăng nhập ứng dụng thành công), kết thúc nghiệp vụ.

� Bước 4: Mobile gateway chỉ xác minh hợp lệ khi cả 2 số Mobile gửi và nhận đều đã đăng ký dịch vụ VĐT và dịch vụ Mobile của cả 2 đều ở trạng thái hoạt động.

o Không hợp lệ: Mobile gateway trả KQ lỗi về màn hình Mobile KH, KH xác nhận thông tin thì ứng dụng trở về menu chính (sau khi đăng nhập ứng thành công), kết thúc nghiệp vụ.

o Hợp lệ: Mobile gateway thực hiện sinh số OTP (6 số) rồi gửi OTP về client qua kênh SMS.

� Bước 5: Ứng dụng client nhận OTP rồi hiển thị lên màn hình cho người dùng nhập vào. Sau khi người dùng nhập OTP hiển thị, ứng dụng gửi OTP lên cho Mobile gateway để xác thực qua kênh HTTP.

� Bước 6: Mobile gateway nhận OTP và xác thực với OTP đã sinh.

o Không hợp lệ: Mobile gateway trả KQ lỗi về màn hình Mobile KH, KH xác nhận thông tin thì ứng dụng trở về menu chính (sau khi đăng nhập ứng thành công), kết thúc nghiệp vụ.

o Hợp lệ: Mobile gateway thực hiện việc đóng gói bản tin theo chuẩn ISO 8583 rồi gửi lên core server.



� Bước 7: Core server xử lý yêu cầu rồi gửi trả về kết quả cho Mobile gateway.

� Bước 8: Mobile gateway nhận kết quả trả về, xử lý thông tin, đóng gói và gửi về cho client.

� Bước 9: Ứng dụng client hiển thị kết quả nếu thành công là:KH chuyển

tiền: "Quy khach da thuc hien chuyen thanh cong <Amount> VND cho thuê bao <RECV_MSISDN>, So du cua qui khach la <Amount>. Kết

thúc nghiệp vụ.


� KH chọn “Cancel” để hủy tiếp tục: Ứng dụng thoát ra khỏi ứng dụng “MobileWalletClient”.

� Tại bất kỳ màn hình nhập liệu nào đều có nút “Back”, khi KH không nhập liệu mà bấm nút “Back” thì ứng dụng sẽ trở về màn hình trước đó

� Đối với các trường nhập liệu và có độ dài trong khoảng min – max xác định. Khách hàng không thể nhập quá max và nếu nhập nhỏ hơn min thì sẽ có thông báo ví dụ: “so dien thoai ban nhap khong dung, do dai so dien thoai lon hon 9 so”.

� Gửi Y/C và chờ nhận KQ: Lưu Y/C xong, gửi Y/C thì hiển thị “dang xu ly”

� Các thông báo lỗi tương ứng:

o Bước 4:

� “So thue bao khong hop le”

� “So thue bao khach hang thu huong khong hop le”

o Bước 9:

� “Sai ma PIN”

� “So du khong du de thuc hien giao dich”

� Hiển thị thông tin lỗi tương ứng khác

KQ nhận được nếu có lỗi thì sẽ được hiển thị lên màn hình. KH bấm OK, ứng dụng trở về menu chính (sau khi đăng nhập ứng dụng thành công), kết thúc nghiệp vụ.



1.3 Chức năng truy vấn số dư


Tên chức năng Tra cứu số dư Mô tả Cho phép KH tra cứu số dư TK VĐT KH


Điều kiện trước KH đã đăng ký dịch vụ VĐT và kênh thanh toán trên Mobile của KH ở trạng thái hoạt động

Điều kiện sau N/A

Ngoại lệ N/A Các yêu cầu đặc biệt

N/A


Hình 24. Luồng xử lý chức năng truy vấn số dư



1.3.3 Mô tả dòng sự kiện chính (Basic Flow)

� Bước 1: KH vào chức năng tra cứu số dư trên ứng dụng, ứng dụng yêu cầu KH nhập để PIN để xác thực.

� Bước 2: Sau KH nhập PIN và xác nhận, DSTK chuyển thông tin sang Mobile gateway để xác thực số Mobile gửi. Mobile gateway chỉ xác thực hợp lệ khi số Mobile gửi đã đăng ký dịch vụ VĐT và dịch vụ thanh toán trên Mobile ở trạng thái hoạt động:

o Không hợp lệ: Trả KQ về ứng dụng hiển thị lỗi lên màn hình Mobile KH, kết thúc nghiệp vụ.

o Hợp lệ: Mobile gateway gửi yêu cầu tra cứu số dư sang Core server

� Bước 3: Mobile gateway nhận KQ trả về từ Core server, cập nhật KQ vào Y/C, đồng thời kiểm tra KQ:

o Không thành công: Mobile gateway trả KQ về ứng dụng hiển thị thông tin lỗi lên màn hình KH. Kết thúc nghiệp vụ.

o Thành công: Mobile gateway trả thông báo số dư về ứng dụng hiển thị lên màn hình KH: “So du tai khoan VDT cua quy khach la <Amount> VND” Kết thúc nghiệp vụ.


� KH chọn “Cancel” để hủy tiếp tục: ứng dụng thoát ra khỏi ứng dụng “MobileWalletClient”.

� Tại bất kỳ màn hình nhập liệu nào đều có nút “Back”, khi KH không nhập liệu mà bấm nút “Back” thì DSTK sẽ trở về màn hình trước đó

� Đối với các trường nhập liệu và có độ dài trong khoảng min – max xác định. Khách hàng không thể nhập quá max và nếu nhập nhỏ hơn min thì sẽ có thông báo ví dụ: “so dien thoai ban nhap khong dung, do dai so dien thoai lon hon 9 so”.

� Gửi Y/C và chờ nhận KQ: Lưu Y/C xong, gửi Y/C thì hiển thị “dang xu ly”

� Các thông báo lỗi tương ứng:

o Bước 2: “So thue bao khong hop le”

o Bước 3: Hiển thị thông tin lỗi tương ứng khác



KQ nhận được nếu có lỗi thì sẽ được hiển thị lên màn hình. KH bấm OK, ứng dụng trở về menu chính (sau khi đăng nhập ứng dụng thành công), kết thúc nghiệp vụ.

2. Khó khăn trong việc triển khai dịch vụ

Wifi

Hình 25. Mô hình tổng thể hệ thống Mobile wallet

Qua sơ đồ trên, ta có thể nhận thấy rõ điểm yếu nhất của hệ thống chính là ở

chiếc điện thoại di động. Đặc điểm chung của chiếc điện thoai di động đó là khả

năng xử lý yếu, hạn chế bộ nhớ, năng lượng... đã làm hạn chế sự mở rộng của dịch

vụ thanh toán. Ngoài ra, việc server phải giao tiếp với rất nhiều dòng điện thoại khác nhau của nhiều nhà sản xuất khác nhau cũng là một thách thức lớn.

Khi mobile commerce đang tỏ ra thông dụng và nhiều tính ứng dụng thực tiễn cao, thì việc bảo mật trong truyền tải dữ liệu lại trở thành 1 vấn đề quan trọng

và cấp thiết cho người dùng mobile và các nhà phát triển ứng dụng không dây. Tổng thể vấn đề bảo mật của 1 mạng chỉ mạnh mẽ bằng điểm yếu nhất của chính nó và

trong một mạng mobile-commerce thì điểm yếu nhất là thiết bị client-side. Khả năng bị chặn tín hiệu, bộ nhớ bị giới hạn, sức mạnh tính toán yếu của hầu hết các

thiết bị cầm tay chính là điểm yếu nguy hiểm của các hệ thống không dây, dữ liệu dễ bị lợi dụng, bị ăn cắp. Người sử dụng sẽ chỉ chấp nhận sử dụng ví điện tử khi

dịch vụ chứng minh được nó trước tiên là bảo đảm an toàn hơn ví thật, và thứ 2 mới đến tính tiện dụng.

Ví điện tử không thể thanh toán được nếu không có đối tác (merchant) chấp nhận nó. Merchant là bên cung cấp hàng hóa, rõ ràng việc mở rộng dịch vụ đồng

nghĩa với việc mở rộng được thật nhiều các merchant chấp nhận thanh toán qua ví điện tử. Người sử dụng sẽ chẳng sử dụng ví điện tử nếu nó không thể có khả năng



thanh toán hoặc thanh toán được rất ít các dịch vụ, tối thiểu phải là các dịch vụ thiết

yếu như thanh toán tiền điện, nước, thuê bao điện thoại,…

3. Giải pháp công nghệ

3.1 Giải pháp công nghệ trên điện thoại

Các nhà sản xuất khác nhau thì đưa ra các dòng điện thoại khác nhau, sử

dụng các hệ điều hành khác nhau như (Symbian, android, window mobile…) Việc giao tiếp với các hệ điều hành này không có một chuẩn chung mà phải xử lý riêng lẻ

làm hao tốn tài nguyên hệ thống cũng như khó khăn trong việc chuẩn hóa giao tiếp.

Tại sao sử dụng công nghệ Java?

Các thiết bị di động cũ thì các phần mềm của nó là những bộ mã cứng, do nhà sản xuất cài đặt vào, nhưng ngày nay, các phần mềm có thể linh động tải về từ

mạng (loading software over the air).

Java là công nghệ được nhiều nhà sản xuất di động lớn tích hợp trong thiết bị của mình:America Online, Ericsson, Matsushita, Motorola, NTT DoCoMo, Palm,

Samsung, Siemens, Sun Microsystems*, Bull, Fujitsu, Mitsubishi, Nokia, Oracle, RIM, Sharp, Sony, Symbian...

Java là nền tảng công nghệ có thể chạy trên được hầu hết các thiết bị di động mà không phụ thuộc nhiều vào phần cứng của thiết bị.

Một điểm nữa đó là J2ME hỗ trợ lắng nghe tin nhắn SMS từ 1 cổng định trước, giúp ứng dụng bắt được các tin nhắn gửi đến mà không để tin nhắn vào Inbox

của điện thoại. Điều này khá hữu ích trong việc phát triển thêm yếu tố bảo mật ứng dụng qua kênh tin nhắn một cách tự động và trong suốt với người dùng.

3.2 Giải pháp công nghệ phía server side

Mobile gateway là một proxy servlet có nhiệm vụ là đứng giữa để hỗ trợ giao

tiếp giữa client và core server. Định dạng bản tin giao tiếp giữa client và mobile gateway là dạng binary chứ không phải XML để giảm dung lượng đường truyền

cũng như tốc độ xử lý. Mobile gateway sẽ hoàn toàn chỉ là tầng môi giới giữa client và core server, nhiệm vụ chính của nó đơn giản là chỉ forward các yêu cầu của

client đi và nhận kết quả, trả về cho client. Điều này giúp giảm tải cho cả client và server và linh động trong việc mở rộng hệ thống cũng như bảo trì sau này.



Hình 26. Các module mức thấp của mobilegateway

Luồng xử lý:

a. Mobile gateway tiếp nhận yêu cầu từ client application qua Channel (sử dụng http connection hoặc tcp).

b. Luồng dữ liệu nhận được sẽ qua Validator để validate (theo TLV) và kiểm tra tính toàn vẹn chiều dài của luồng dữ liệu nhận được

c. Sau khi được kiểm tra, Parser sẽ thực hiện phân tích luồng dữ liệu và chuyển thành object

d. Bussiness Processing sẽ căn cứ theo loại giao dịch, sử dụng wrapper để đóng gói dữ liệu và gửi đến Core Server.

e. Kết quả nhận được từ Core Server sẽ được đóng theo cơ chế TLV và

gửi về Channel

Phần core server là thành phần chính của hệ thống đảm nhiệm các xử lý nghiệp vụ, tương tác với CSDL … Với mỗi một giao dịch cần được xử lý, mobile

gateway lại mở một kết nối socket đến core server để giao tiếp. Việc đóng mở kết nối thường xuyên sẽ làm tiêu tốn nhiều tài nguyên cũng như thời gian của cả hệ

thống. Chính vì vậy, để tối ưu kết nối đến core server, ta cần quản lý được kết nối đến nó; điều này dễ dàng làm được với Apache pooling. Apache pooling sẽ quản lý

việc mở bao nhiêu kết nối đến core server, và mỗi khi mở kết nối thì các kết nối này sẽ không bị đóng lại mà sẽ để ở dạng chờ (Idle) để phục vụ cho những lần sau.

Apache pooling còn được sử dụng trong việc kết nối đến database của hệ thống.

Phần core server do thời gian hạn hẹp cũng như thiếu thốn về kiến thức,

nghiệp vụ nên em chưa thể xây dựng hoàn chỉnh với công nghệ EJB. Hiện tại thì



core server chỉ có thể xử lý một số yêu cầu đơn giản, và kết nối trực tiếp với

database để thực hiện lệnh.

4. Giải pháp bảo mật

4.1 Mô hình mã hóa

Do client là các ứng dụng chạy trên điện thoại, với sức mạnh tính toán và bộ

nhớ yếu hơn nhiều so với PC, và mục tiêu của dịch vụ là hướng cả đến những khách hàng không có điều kiện sử dụng những chiếc smartphone đắt tiền. Họ có thể chỉ sử

dụng những chiếc điện thoại hỗ trợ JAVA MIDP 1.0 nhưng vẫn có nhu cầu sử dụng ví điện tử. Việc hướng đến cả những khách hàng bình dân giúp dịch vụ có thể được

triển khai rộng khắp.

Hiện tại, việc áp dụng mô hình mã hóa trao đổi thông tin Session key vào hệ

thống là không hợp lí. Bởi vì với sức mạnh tính toán của một chiếc điện thoại bé nhỏ thì việc mã hóa và giải mã bằng mã hóa bất đối xứng mất rất nhiều thời gian. Qua việc kiểm tra mô hình session key trên máy điện thoại Nokia N70 thì phải mất

tới 20s để giải mã gói tin bằng RSA. Thêm vào đó, phát sinh thêm vấn đề là lưu trữ private key và phân phối public key của khách hàng. Nếu là lưu trữ private key trên

điện thoại thì sẽ không đảm bảo tính an toàn vì chiếc điện thoại rất dễ lọt vào tay người khác. Nếu là lưu trữ private key trên server chứng thực thì hệ thống sẽ phức

tạp lên và cũng gặp phải không ít khó khăn để server chứng thực làm việc, giao tiếp với điện thoại.

Về nguyên tắc trong mua bán điện tử, thì hệ thống M-wallet chấp nhận thanh toán với bất kì khách hàng nào có nhu cầu. Vì vậy, việc yêu cầu khách hàng phải có

cặp public/private key riêng sẽ làm cho hệ thống giảm đi một lượng lớn khách hàng.

Mà thực chất, khách hàng chỉ cần chắc chắn là họ đang giao dịch với Server đã

được xác thực. Chính vì vậy, mô hình Hybrid thể hiện mình là lựa chọn thích hợp. Với mô hình này, public key của server sẽ được hardcode trong ứng dụng, ứng dụng

sẽ được phân phối trên kênh đã được chứng thực. Client sẽ sinh khóa session rồi gửi lên cho server để trao đổi thông tin. Và để đảm bảo tính toàn vẹn của thông tin, ta

sử dụng thêm MAC trong mỗi bản tin.

4.2 MAC

MAC được sinh bằng cách băm bản tin và session key. Hacker nếu muốn giả dạng, hay thay đổi bản tin cũng không được vì session key là bí mật, được trao đổi

bằng mã hóa bất đối xứng. Trong mỗi bản tin gửi lên luôn phải kèm theo MAC để xác thực tính toàn vẹn của bản tin.



4.3 Thư viện Bouncy Castle

Bản thân các API của J2ME không hỗ trợ các giải thuật mã hóa trên, mà chỉ với MIDlet 2.0 có hỗ trợ HTTPs, vì vậy, ta phải sử dụng thư viện của một nhà cung

cấp khác. Trong số các thư viện mã hóa cho J2ME hiện nay thì BouncyCastle nối lên là một thư viện mã hóa nhanh, chạy được trên nhiều nền tảng, hỗ trợ rất nhiều

các giải thuật và hỗ trợ các chuẩn về bảo mật như PKCS, SSL,X.509… Hơn thế nữa, BouncyCastle là thư viện mã nguồn mở và miễn phí.

4.4 Phân phối public key server

Có một vấn đề trong mô hình Hybrid system, đó là vấn đề phân phối public

key của server. Việc này có thể được thực thi bằng cách hardcode trong ứng dụng, và bắt người dùng download ứng dụng từ trang web chính thức của nhà cung cấp.

Sau một khoảng thời gian, khi cần update public key thì server sẽ bắt buộc người dùng phải update phiên bản ứng dụng mới nhất. Với công nghệ 3G hiện nay đang phát triển rất mạnh thì việc download vài trăm kilobyte không còn là khó khăn và

đắt đỏ.

4.5 Mã nguồn có thể dịch ngược

Hiện nay, tồn tại rất nhiều chương trình có thể dịch ngược mã nguồn bytecode .class của java, điều này rất nguy hiểm vì hacker có thể có được toàn bộ

mã nguồn của chương trình từ đó biết đươc luồng làm việc và tìm ra những lỗ hổng có thể lợi dụng. Giải pháp là sử dụng công cụ obfucator để obfucate mã nguồn, đưa

mã nguồn về dạng mà con người khó có thể hiểu được nhưng máy thì hoàn toàn hiểu được.

4.6 RMS không an toàn

J2ME cung cấp 1 vùng nhớ riêng để lưu trữ các dữ liệu triên điện thoại, đó là

RMS (Record Management System). Các RMS của 1 MIDlet không thể đọc được bởi các MIDlet khác nếu không được cho phép. RMS hứa hẹn là nơi lưu trữ những

thông tin nhạy cảm của người dùng một cách bí mật tuyệt đối. Nhưng chỉ cần sử dụng 1 ứng dụng quản lý file đơn giản như FExplorer, hacker có thể tìm đến file

rms.db của ứng dụng MIDlet đó, nơi chứa các thông tin mà ứng dụng đó lưu trên máy, rồi truyền ra ngoài bằng bluetooth, cable,…Rồi bằng những công cụ crack,

đọc file theo ANSI thì mọi thông tin trong RMS có thể dễ dàng lấy ra. Do vậy, lưu trữ trong RMS không phải là an toàn tuyệt đối, ta chỉ lưu những thông tin thật sự là

cần thiết trên RMS, còn lại lưu trên server, và với những thông tin nhạy cảm, cần phải mã hóa trước khi lưu.



4.7 Client sinh key session

Trong mô hình Hybrid, khóa bí mật được sinh hoàn toàn từ phía client. Nhưng điện thoại là một thiết bị nhỏ, yếu, hạn chế về nhiều mặt, không thể là một

thiết bị sinh key an toàn được. Hiện tại, APIs để can thiệp vào phần cứng của J2ME là rất ít, do vậy nguồn random (entropy) là không cao, việc sinh key ngẫu nhiên gần

như dựa vào thời gian, một số thông tin cá nhân của máy điện thoại, là giải thuật PRNG. Việc sinh key mà không gian khóa không đủ lớn thì hacker có thể lợi dụng

bẻ khóa 1 cách dễ dàng, dù kể cả độ dài khóa có là 24bytes. Đây có lẽ là hạn chế lớn nhất của client chạy trên điện thoại. Để khắc phục, ta phải nhờ đến một công

nghệ khác, đó là OTP (One – Time - Password).

4.8 SEQUENCE

Relay attach là phương thức tấn công khá phổ biến, đối tượng hacker gửi liên tiếp một bản tin cùng một nội dung lên server, lợi dụng delay của hệ thống để chuộc lợi. Để ngăn chặn relay attach, ta sử dụng thêm biến sequence. Mỗi một giao dịch

khi xử lý luôn đảm bảo là phải hoàn thành trước khi xử lý tiếp một giao dịch khác.

Khi một giao dịch hoàn thành, biến sequence lại được tăng lên 1 đơn vị. Ngoài ra,

các client khi gửi thông tin lên đều phải được đặt thuộc tính user-agent để kiểm tra.

4.9 OTP

OTP là từ có lẽ được nhắc khá nhiều trong bảo mật ngân hàng, chứng khoán… OTP được coi là giải pháp tối ưu nhất trong bảo mật. OTP là password chỉ

được sử dụng một lần duy nhất, và nó có hiệu lực trong một khoảng thời gian nhất định. Ví dụ trong giao dịch thanh toán, khi người dùng chuyển tiền từ 1 tài khoản

đến 1 tài khoản, để xác nhận việc chuyển tiền này là từ đúng thuê bao của người dùng, server sẽ gửi OTP qua tin nhắn đến thuê bao đó, và người dùng sẽ nhập OTP

nhận được vào form và gửi lên cho server, tại đây, server sẽ xác thực OTP. Vì OTP chỉ có hiệu lực trong 1 khoảng thời gian ngắn, nên hacker không có đủ thời gian để

bẻ khóa, và cũng không thể giả danh người dùng được vì OTP được gửi qua kênh SMS, một kênh được cho là rất bảo mật, rất khó và rất đắt đỏ khi giả mạo. Vậy việc

áp dụng OTP vào trong hệ thống M-wallet như thế nào?

Trong các ứng dụng thực đã triển khai OTP, OTP sẽ được truyền qua kênh

tin nhắn, độc lập với kênh giao tiếp của ứng dụng với server. Người dùng sẽ phải

thoát ứng dụng ra, vào inbox, ghi nhớ OTP, rồi lại vào ứng dụng để ghi OTP. Điều

này rất bất tiện cho người sử dụng. Thật may mắn là J2ME có hỗ trợ API về Wireless messaging (WMA), cho phép lập trình viên có thể viết ứng dụng gửi và

nhận tin nhắn một cách tự động. Khi server gửi tin nhắn về, ta cần yêu cầu SMSC



gửi tin nhắn theo 1 cổng mà ứng dụng đang lắng nghe. Khi có tin nhắn về, ứng dụng

bắt được tin nhắn, đọc nội dung, rồi hiển thị lên ứng dụng cho người dùng. Ở mức độ demo, ta có thể sử dụng một modem GSM thay vì phải sử dụng một SMSC thực

thụ để nhắn tin SMS. Chi tiết hướng dẫn sử dụng NOWSMS, tham khảo trên trang web chính thức www.nowsms.com

Rõ ràng, với việc áp dụng thêm OTP, hệ thống M-wallet sẽ đảm bảo được tính bảo mật cao, tính xác thực của hệ thống. Số ngẫu nhiên sẽ được sinh từ server

với sức mạnh gấp nhiều lần client sẽ đảm bảo được tính bảo mật, không gian khóa lớn.



Chương 4. THIẾT KẾ

1. Thiết kế CSDL Để phục vụ cho dịch vụ, ta cần một cơ sở dữ liệu ngân hàng. Cơ sở dữ liệu

được xây dựng ở mức đơn giản, trước mắt đây là phiên bản đầu để phục vụ cho việc demo chương trình.

1.1 Xây dựng các thực thể và các bảng cho cơ sở dữ liệu

Cơ sở dữ liệu phải được xây dựng bao gồm các thực thể sau đây:

1. Khách hàng

2. Tài khoản

3. Tài khoản điện thoại (kênh thanh toán trên điện thoại)

4. Tài khoản card (kênh thanh toán trên thẻ)

5. Giao dịch

6. Thuê bao điện thoại

Chi tiết các thực thể được xây dựng thành các bảng như dưới đây:

STT Tên bảng Mô tả

01 CUSTOMER Thông tin khách hàng

02 CUST_ACCOUNT Thông tin tài khoản Ví điện tử

03 CUST_MOBILE Thông tin kênh thanh toán trên Mobile

04 TRANS_APP Thông tin bản tin giao dịch

05 CUST_CARD Thông tin kênh thanh toán trên Thẻ

06 MOBILE Thông tin về các thuê bao đang sử dụng



Hình 27. Sơ đồ mối quan hệ giữa các bảng trong CSDL

1.2 Bảng CUSTOMER

STT Tên trường Kiểu dữ liệu và độ

dài Nulla

ble Unique

P/F Key

Mặc định

Mô tả

1 CUST_CODE INT N P Mã khách hàng

3 CUST_NAME VARCHAR2(100) N Tên khách hàng

4 ID_NO VARCHAR2(20) N Số thẻ căn cước

5 ID_TYPE VARCHAR2(3) N Loại thẻ căn cước



6 ID_ISSUE_DATE DATE(7) N Ngày cấp thẻ căn cước

7 ID_ISSUE_PLACE VARCHAR2(25) N Nơi cấp thẻ căn cước

8 GENDER VARCHAR2(6) N Giới tính (MALE/FEMALE)

9 BIRTHDAY DATE(7) N Ngày sinh

10 CONTACT_MOBILE_NO

VARCHAR2(20) Y Số điện thoại liên lạc

11 FAX VARCHAR2(20) Y Fax

12 EMAIL VARCHAR2(34) Y Email

13 ADDRESS VARCHAR2(200) Y Địa chỉ liên lạc

14 CREATED_DATE DATE(7) N SYS

DATE Ngày tạo

15 MODIFIED_DATE DATE(7) Y Ngày cập nhật

Bảng 8. Bảng CUSTOMER

1.3 Bảng CUST_ACCOUNT


dài Nulla

ble Unique

P/F Key

Mặc định

Mô tả

1 ACC_ID INT N Y P Số TK Ví điện tử

2 ACC_LEVEL VARCHAR2(3) N Hạng tài khoản (Đặt hạn mức)

3 ACC_STATUS VARCHAR2(3) N Tình trạng tài khoản

4 BALANCE VARCHAR(22) N Số dư tài khoản VĐT ban đầu khi đăng ký

6 CUST_CODE INT N F Mã khách hàng

8 CREATED_DATE DATE N SYS DATE

Ngày tạo

9 ACTIVE_DATE DATE Y Ngày kích hoạt

10 MODIFIED_DATE

DATE Y Ngày cập nhật

11 EXPIRED_DATE DATE Y Ngày hết hiệu lực

Bảng 9. Bảng CUST_ACCOUNT

1.4 Bảng CUST_MOBILE


dài Nulla

ble Unique

P/F Key

Mặc định

Mô tả

1 MOBILE_ID INT N P Số tự tăng xác định tính duy

nhất

2 ACC_ID INT N F Số TK Ví điện tử

3 MSISDN VARCHAR2(20) N Số MSISDN

4 MOBILE_LEVEL VARCHAR2(3) N Hạng giao dịch trên kênh

Mobile



5 MOBILE_STATUS VARCHAR2(3) N Tình trạng kênh Mobile

7 CREATED_DATE DATE(7) N Ngày tạo


9 EXPIRED_DATE DATE(7) Y Ngày hết hiệu lực

10 MSISDN_TYPE NUMBER(22) Y Xác định loại thuê bao: 0 - trả

trưuớc, 1 - trả sau

Bảng 10. Bảng CUST_MOBILE

1.5 Bảng TRANS_APP


dài Nulla

ble Unique

P/F Key

Mặc định

Mô tả

1 REQUEST_ID NUMBER(22) N Y P ID bản tin

2 PROCESS_CODE CHAR(6) N Mã xử lý

3 REQUEST_MTI CHAR(4) N Loại bản tin (Gửi/nhận ...)

4 REQUEST_DATE DATE(7) N Ngày gửi bản tin

5 APP_ID NUMBER(22) N Nguồn xuất phát giao dịch

6 REF_NO CHAR(12) N Số tham chiếu

7 AUDIT_NO NUMBER(22) N Số audit

8 MSISDN VARCHAR2(20) Y Số MSISDN

9 ACC_ID NUMBER(22) Y Số TK Ví điện tử

10 ACC_STATUS VARCHAR2(3) Y Tình trạng tài khoản Ví điện tử

11 BALANCE VARCHAR(22) Y Số dư tài khoản Ví điện tử

12 CURR_CODE VARCHAR2(3) Y Mã nguyên tệ

13 TRANS_AMOUNT NUMBER(22) Y Số tiền giao dịch

14 TRANS_FEE NUMBER(22) Y Phí giao dịch

15 SENT_CUST_NAME

VARCHAR2(35) Y

Tên KH nạp tiền, chuyển tiền

16 SENT_CUST_ADDR

VARCHAR2(200) Y

địa chỉ KH nạp tiền, chuyển tiền

17 SENT_ID_NO VARCHAR2(20) Y

Số thẻ căn cước KH nạp tiền, chuyển tiền

18 SENT_ID_TYPE VARCHAR2(3) Y

Loại thẻ căn cước KH nạp tiền, chuyển tiền

19 RECV_CUST_NAME

VARCHAR2(35) Y

Tên KH nhận tiền

20 RECV_CUST_ADDR

VARCHAR2(200) Y

địa chỉ KH nhận tiền

21 RECV_ID_NO VARCHAR2(20) Y Số thẻ căn cước KH nhận tiền

22 RECV_ID_TYPE VARCHAR2(3) Y Loại thẻ căn cước nhận tiền

23 RECV_ACC_ID NUMBER(22) Y

Số TK Ví điện tử KH nhận tiền

24 RECV_BANK_ACC VARCHAR2(20) Y Số TK NH của người nhận



_NO

25 RECV_MSISDN VARCHAR2(20) Y Số MSISDN của KH nhận tiền

26 RECV_BANK_CODE

VARCHAR2(15) Y

Mã ngân hàng của TK KH nhận tiền

27 RESPONSE_CODE VARCHAR2(3) Y Mã lỗi trả về

28 RECV_MSISDN_TYPE

VARCHAR2(1) Y

Xác định loại thuê bao: 0 - trả trưuớc, 1 - trả sau

Bảng 11. Bảng TRANS_APP

1.6 Bảng CUST_CARD


dài Nulla

ble Unique

P/F Key

Mặc định

Mô tả

1 CARD_ID INT N P

Số tự tăng xác định tính duy nhất của thẻ

2 ACC_ID INT N F Số TK Ví điện tử

3 CARD_NO VARCHAR2(19) N F Số thẻ ATM

4 CARD_TYPE VARCHAR2(3) N

Loại thẻ (bình thường, đặc biệt)

5 CARD_LEVEL VARCHAR2(3) N Hạng thẻ

6 CARD_STATUS VARCHAR2(3) N Tình trạng thẻ

7 CVV CHAR(4) N

8 ISSUE_METHOD VARCHAR2(3) N

Phương thức phát hành (theo lô, ký quỹ ...)

9 ISSUE_DATE DATE(7) N Ngày phát hành (in thẻ)

10 CREATED_DATE DATE(7) N

SYSDATE Ngày tạo


12 EXPIRED_DATE DATE(7) Y Ngày hết hiệu lực

Bảng 12. Bảng CUST_CARD

1.7 Bảng MOBILE


dài Nulla

ble Unique

P/F Key

Mặc định

Mô tả

1 MOBILE_ID INT N P

Số tự tăng xác định tính duy nhất

2 MSISDN VARCHAR2(20) N Số MSISDN

3 MSISDN_TYPE INT N Loại thuê bao

4 BALANCE VARCHAR2(22) N

Số dư trong tài khoản trả trước – số nợ trong trả sau

5 CUST_NAME VARCHAR2(35) Y Tên thuê bao

6 ID_NO VARCHAR2(20) Y Số thẻ căn cước

7 ID_TYPE VARCHAR2(3) Y Loại thẻ căn cước



8 ID_ISSUE_PLACE VARCHAR2(200) Y Nơi cấp thẻ căn cước

9 ID_ISSUE_DATE DATE(7) Y Ngày cấp thẻ căn cước

10 CREATED_DATE DATE(7) Y

SYSDATE Ngày tạo

11 GENDER VARCHAR(6) Y

12 EMAIL VARCHAR2(34) Y

13 BIRTHDAY DATE(7)

Bảng 13. Bảng MOBILE

2. Đặc tả giao diện kết nối

2.1 Xử lý giao dịch

Bước 1. Khách hàng sử dụng chức năng trên ứng dụng j2me. Ứng dụng sẽ

thực hiện việc đóng gói và gửi bản tin về phía mobile gateway

Bước 2. Mobile gateway tiếp nhận request từ j2me gửi đến qua kênh kết nối. Bản tin nhận được sẽ được phân tích, xác thực và đóng gói chuyển đến core system.

Bước 3. Mobile gateway nhận được bản tin từ core system, xác thực bản tin sau đó đóng gói và trả về phía client.

Bước 4. ứng dụng j2me thực hiện việc giải gói, xác thực bản tin và hiển thị kết quả giao dịch.

2.2 Đặc tả bản tin tương tác

2.2.1 Định nghĩa các tham số

Để hạn chế dữ liệu truyền (do hạn chế về tốc độ, tính ổn định của kênh truyền), các tham số được thu gọn và viết tắt như sau:

TT Tham

số

Kiểu

dữ

liệu

chiều dài tối đa Từ viết tắt Mô tả

1 o[x]

n 12 Owner Số tài khoản của người sử dụng

2 p[x] an 8 Pin Số Pin sử dụng trong các giao dịch

3 m n 12 Msisdn Số điện thoại thụ hưởng trong các

giao dịch (topup, gạch nợ cước trả sau, homephone, chuyển tiền)



4 np an 8 New pin Mật khẩu mới, sử dụng trong giao

dịch đổi mật khẩu

5 s[x] n 9 Sequence Số thứ tự của giao dịch (đồng bộ giữa client và server)

6 a n 10 amount Số tiền trong các giao dịch (chuyển tiền, topup, gạch nợ)

7 f[a] n 2 Function Chức năng cần thực hiện (xem bảng

danh sách các chức năng)

8 ma[a] an Message

authentication

code

Mã xác thực bản tin

9 d[a] n Data Chứa dữ liệu giao dịch chuyển từ

ứng dụng về mobile gateway (dữ liệu giao dịch được encode theo

dạng hexa)

10 v an 10 Version Phiên bản hiện tại của ứng dụng

13 kv an 10 Key version Phiên bản public key lưu phía client

14 r[y] n 2 Result Mã lỗi giao dịch

15 sc an 30 Service code Mã dịch vụ thanh toán

16 tid[y] an 15 Transaction Id Mã giao dịch, phục vụ truy vấn giao dịch

17 ms an 100 Message Thông điệp thể hiện kết quả giao dịch

18 bc an 10 Bank code Mã ngân hàng

19 pid an 12 Personal id Chứng minh thư nhân dân

20 sid n 2 System id định danh hệ thống xử lý

21 sk an 16 Session Key Chuỗi Hexa của session key.

22 otp an 9 Otp String Chuỗi gồm 9 ký tự.

Hai Ký tự đầu là Sequence (01-99)

tạo ngẫu nhiên.

Ký tự thứ 3 chỉ loại device, 0 :

iphone, 1 : J2me.



Sáu ký tự cuối là chuỗi ngẫu nhiên

sinh từ thông tin của máy.

23 l[x] an 1 Language 1 : Tiếng việt không dấu

2 : Tiếng việt có dấu

3 : English

24 cn an 19 Card No Mã số in trên thẻ

25 cvv an 3 CVV 3 ký tự cuối ghi sau thẻ

26 cne an 30 Customer

Name

Họ và tên khách hàng

27 id an 10 User Identification

No

Số Chứng minh thư

28 uidd an 10 User Identity

card date

issued.

Ngày cấp Chứng minh thư

05-05-2010

29 ds an Digital sign Chữ kí của mobile gateway

30 pk an Public key Public key mới

31 mgs an message sign mẩu tin dùng để kí

Bảng 14. Định nghĩa các tham số của bản tin

Các tham số có ký tự:

[x] tham số bắt buộc có trong request

[y] tham số bắt buộc có trong response

[a] tham số bắt buộc có trong cả request & response

Kiểu dữ liệu:

an: kiểu dữ liệu chỉ chứa các chữ số và chữ cái

n: kiểu dữ liệu chỉ chứa các chữ số

2.2.2 Cách thức tạo dữ liệu bản tin

a. Request URL

Định dạng request từ client

http(s)://[host]:[port]/[application]/[contextPath]?d=[value]



ví dụ:

http://192.168.168.74/MobileGateway/TxGateway?d=0230313539663d3033266f3d38343136353735303132373726703d31323334353626723d34636163643730

30623639366137333464313738313537666161636238336633646238366335393935653463316632626635373535363937386365393930336564633962363330663064

363363646233383164323237663762393730393537646166316565633763363736396261333465626465646437633437663630393934

Kết quả được trả về là luồng bytes dữ liệu, sử dụng định dạng http request

Ví dụ:

36539393033656463396236333066306436336364623338316432323766376

2393730393537646166316565633763363736396261333465626465646437633437663630393934

b. Danh sách chức năng

Giá trị Mô tả

03 Truy vấn số dư

04 Truy vấn giao dịch External

05 chuyển tiền ví điện tử - ví điện tử

06 Chuyển tiền ví điện tử - ngân hàng

07 Chuyển tiền sử dụng CMTND

08 Nạp tiền

09 Rút tiền

11 Nạp tiền thuê bao trả trước

12 Gạch nợ cước thuê bao trả sau

13 Gạch nợ cước home phone trả sau

14 Gạch nợ cước ADSL

15 Gạch nợ cước các dịch vụ khác

16 Thanh toán dịch vụ

17 Yêu cầu thanh toán dịch vụ (Request to pay)

18 Kích hoạt ví điện tử



19 Thay đổi PIN

21 Khóa ví điện tử

22 Truy vấn giao dịch internal

23 Lấy tên phiên bản mới nhất trên server

24 Truy vấn kết quả giao dịch cuối

25 Bản tin trao đổi session key

26 Bản tin kích hoạt Client

27 Bản tin kích hoạt Thẻ

28 Bản tin cập nhật thông tin cá nhân

Bảng 15. Danh sách các chức năng

Ví dụ bản tin chuyển tiền

Request:

/TxGateway?f=05&s=1&o=841657501277&p=47780a282&m=0947000759&a=10000&ma=0723d6059c9e71c1386fcef43dbd26fc03536979ebfdb0b47780a282

293245199a5f02cadb24c0b8fc55457b652718acdfa4fb4a27c6f4573f6681935f45b9

Response:

f=05&r=05&ms=giao%20dich%20thanh%20cong

c. Định nghĩa tham số cho các chức năng

C.năng/T.số m np a v kv bc pid tid s sc Mô tả chức năng

03 Truy vấn số dư

04 Truy vấn giao dịch

External (các giao dịch

lấy thông tin trên hệ

thống Smartlink, MB)

05 x x x x chuyển tiền ví điện tử - ví

điện tử

06 x x x x x Chuyển tiền ví điện tử -

ngân hàng

07 x x x x x Chuyển tiền sử dụng



CMTND

08 x Nạp tiền

09 x Rút tiền

11 x x x x Nạp tiền thuê bao trả trước

12 x x x x Gạch nợ cước thuê bao

trả sau

13 x x x x Gạch nợ cước home

phone trả sau

14 x x x x Gạch nợ cước ADSL

15 x x x Gạch nợ cước các dịch vụ

khác

16 x Thanh toán dịch vụ

17 x Yêu cầu thanh toán dịch

vụ (Request to pay)

18 Kích hoạt ví điện tử

19 x x x Thay đổi PIN

21 x Khóa ví điện tử

22 x Truy vấn giao dịch

internal

23 x Lấy tên phiên bản mới

nhất trên server

24 Truy vấn kết quả giao

dịch cuối

25 x x Bản tin trao đổi session key

26 x x Bản tin kích hoạt client

27 x x Bản tin kích hoạt thẻ

28 x x Bản tin cập nhật thông tin cá nhân

Bảng 16. Các tham số cho từng chức năng

d. Cách thức tạo dữ liệu trường



Định dạng request từ client

http(s)://[host]:[port]/[application]/[contextPath]?d=[value]

[value]: giá trị được encode theo dạng hexa, theo cơ chế TLV (Tag – Length

- Value)

Tag (2 ký tự): ứng dụng nguồn

Tag = 01: j2me

Length (8 ký tự): chiều dài dữ liệu biểu diễn theo số BCD

Value: dữ liệu

Ví dụ:

http://192.168.168.74/MobileGateway/TxGateway?d=010630313539663d3033266f3d38343136353735303132373726703d31323334353626723d346361636437

30306236393661373334643137383135376661616362383366336462383663353939356534633166326266353735353639373863653939303365646339623633306630

64363363646233383164323237663762393730393537646166316565633763363736396261333465626465646437633437663630393934&o=xxxx&ma=yyyy

xxxx : số msisdn tài khoản

yyyy : mac của dữ liệu truyền đi

dữ liệu:

010630313539663d3033266f3d38343136353735303132373726703d31323334353626723d3463616364373030623639366137333464313738313537666161636

23833663364623836633539393565346331663262663537353536393738636539393033656463396236333066306436336364623338316432323766376239373039353

7646166316565633763363736396261333465626465646437633437663630393934

d=010630313539663 … � ứng dụng yêu cầu: j2me, hệ thống xử lý: Core system, chiều dài bản tin: 0159 (bytes)

Định dạng response từ mobile gateway biểu diễn dưới dạng hexa. Chuỗi hexa sau khi được chuyển về mảng bytes có định dạng như sau:

[byte1][byte2 � byte5][byte6 � end]



byte1: byte giá trị thể hiện kết quả trả về từ mobile gateway

byte2 � byte5: 4 bytes biểu diễn chiều dài dữ liệu theo dạng BCD

byte6 � end: mảng bytes dữ liệu

byte6 � end: 3des(f=x&….&ma=yyy)

e. Bảng mã lỗi

(Xem thêm ở phụ lục)



Chương 5. CÀI ĐẶT

1. Cấu hình phần cứng Phía Client là điện thoại di động có hỗ trợ ứng dụng Java MIDP 1.0 trở lên

và hỗ trợ mạng. Trong quá trình xây dựng ứng dụng, client có thể là trình giả lập do

nhà sản xuất cung cấp.

Server là máy chủ có cầu hình đủ mạnh để chạy các ứng dụng Java, database

ví dụ: Intel Pentium dual CPU E2200 @2.20 MHz, 1G RAM. Và có kết nối internet.

Một modem GSM để có thể nhận tin nhắn và nhắn tin OTP đến máy client. Modem GSM có thể là một modem đích thực hoặc có thể là một điện thoại hỗ trợ

chức năng modem ví dụ N70, Sony erricson P1i…

2. Cấu hình phần mềm Máy chủ dịch vụ có thể cài bất kỳ hệ điều hành gì do Java hỗ trợ đa nền. Cụ

thể hệ thống này được xây dựng trên máy tính cài hệ điều hành Windows Vista 64bit Home Edition. Tuy nhiên vẫn có thể triển khai trên máy chủ hệ điều hành

Linux hay Macintosh... Máy chủ dịch vụ cài đặt các phần mềm sau:

o Java 2 SDK 1.6 trở lên

o Netbean 6.8

o My SQL Server 5.1 Driver for JDBC

o NowSMS để chạy dịch vụ nhắn tin

Để xây dựng ứng dụng cần phải có một số phần mềm sau:

o J2ME Wireless Toolkit 2.0

o Các thư viện mã nguồn mở BouncyCastle, JPOS

3. Ngôn ngữ, môi trường Ngôn ngữ chính để xây dựng ứng dụng là ngôn ngữ Java, trên môi trường

Windows.

Mobile gateway được triển khai trên server Apache Tomcat 6.0.



Chương 6. TỔNG KẾT VÀ NHẬN XÉT

1. Giao diện của ứng dụng MIDlet Ứng dụng chạy trên trình giả lập Wireless Tool Kit 2.5.2 của SUN Microsoft

System, đây là bộ công cụ rất hữu ích cho lập trình viên J2ME. Giao diện của ứng dụng được thiết kế đơn giản sao cho thuận tiện cho người sử dụng nhất, không màu mè phức tạp vì là giao dịch tài chính, không phải là giải trí. Các màn hình nhập liệu được thiết kế 1 đến 2 dòng nhập trên một màn hình để phù hợp với những thiết bị có màn hình nhỏ. Sau đây là một số giao diện khi chạy trên trình giả lập:



Hình 28. Màn hình Splash

Hình 29. Màn hình đăng nhập

Hình 30. Màn hình chính

Hình 32. Chức năng tra cứu TK



Hình 31. Màn hình nhập PIN

Hình 33. Màn hình chờ

Hình 34. Màn hình kết quả

Hình 35. Màn hình nhập OTP



2. Hiệu suất của ứng dụng

2.1 Các thông số thực thi

Các thông số sau đây được tính tổng hợp khi sử dụng tất cả các chức năng của ứng dụng (12 lần lấy mẫu) với trình giả lập Wireless toolkit trên cấu hình máy cục bộ CPU core 2 duo T5800 2x2.0 Ghz, 4Gb RAM

Kích thước trung bình Request từ client 112 bytes

Kích thước trung bình Response client nhận được 178 bytes

Kích thước của ứng dụng 93 Kb

Thời gian thực thi trung bình trong môi trường giả lập (thời gian tính từ khi gửi yêu cầu và nhận hồi đáp)

1093 ms

Thời gian thực thi thực tế trong mạng 3G 1026 ms

Thời gian thực thi thực tế trong mạng Wifi 1134 ms

Thời gian thực thi thực tế trong mạng GPRS 2132 ms

Bảng 17. Các thông số thực nghiệm ứng dụng

Nhận xét:

- Thời gian thực thi là có thể chấp nhận được đối với thiết bị di động (đã có cả thời gian mã hóa và giải mã bản tin).

- Kích thước ứng dụng bé (chỉ có 93Kb, nhỏ hơn 100Kb).

2.2 Bộ nhớ

J2ME Wireless Toolkit có công cụ Memory Monitor cho phép giám sát bộ nhớ sử dụng của ứng dụng trong quá trình thực thi.



Hình 36. Đồ thị bộ nhớ khi thực thi ứng dụng

Như ta thấy bộ nhớ của ứng dụng chỉ tăng cao khi khởi động chương trình do phải khởi tạo nhiều Object và nhất là phải tải file ngôn ngữ, sau khi khởi động, ứng dụng sẽ giải phóng bộ nhớ, dung lượng bộ nhớ giảm đáng kể, sau đó dần đi vào ổn định ở mức trung bình thấp chỉ khoảng tầm 170 Kb. Điều này là chấp nhận được vì các dòng máy điện thoại hiện nay đã đáp ứng được rất nhiều về bộ nhớ.

3. Tổng kết và nhận xét

3.1 Đã làm được

• Xây dựng được dịch vụ ví điện tử với 2 chức năng chính là chuyển tiền và truy vấn số dư cho người dùng di động.

• Tìm hiểu các giải pháp, khái niệm bảo mật và đưa ra giải pháp cho dịch vụ mobile wallet, nhất là giải pháp OTP.

• Tìm hiểu chuẩn ISO 8583 và áp dụng thành công vào hệ thống mibile wallet.

• Vận dụng các công nghệ mới để xây dựng hệ thống như: MIDP 2.0, proxy servlet, apache mina framework 2.0, apache pooling, Jpos.

• Hệ thống hỗ trợ 2 ngôn ngữ chính là Việt Nam (có dấu và không dấu) và tiếng Anh.



• Hệ thống được phân tích, thiết kế khá hoàn chỉnh, hoàn toàn có thể đưa vào thực tiễn.

3.2 Hạn chế

• Các chức năng chưa được xây dựng hoàn thiện.

• Về bảo mật, hệ thống cần thêm các yếu tố như CA, PKI bao gồm cơ chế xác thực bên thứ 3, cơ chế lưu trữ private key, cơ chế sinh khóa OTP (bằng các thiết bị phần cứng chuyên dụng như HSM…)

• Do điều kiện khách quan, hệ thống chưa được thử nghiệm thực tế, vẫn dừng ở mức giả lập.

• Database được thiết kế đơn giản, chưa chặt chẽ và đầy đủ.

• Một số thuật ngữ và khái niệm còn khá mới nên việc chuyển dịch sang tiếng Việt còn chưa rõ ràng và thống nhất.

3.3 Hướng phát triển

• Hoàn chỉnh các chức năng của hệ thống.

• Nâng cấp phần bảo mật của hệ thống.

• Hoàn chỉnh phần core của hệ thống, áp dụng các công nghệ mới nhất để hệ thống hoạt động hiệu quả tối ưu.

Một lần nữa, em xin chân thành cảm ơn cô giáo thạc sĩ Bùi Thị Hòa đã hướng dẫn và chỉ dạy tận tình cho em trong quá trình thực hiện đồ án.



Phụ lục

TT Mã lỗi Mô tả

1 000 Giao dịch thành công

2 901 Số điện thoại không hợp lệ hoặc không đúng định dạng

3 902 Số tiền không hợp lệ hoặc không đúng định dạng

4 903 PIN sai

5 904 Hệ thống bảo dưỡng

6 905 Dịch vụ yêu cầu chưa có hoặc đang ngừng hoạt động

7 101 Ví điện tử chưa được kích hoạt

8 103 Merchant không hợp lệ

9 105 Ví điện tử bị khóa

10 109 Giao dịch đang trong quá trình xử lý

11 113 Số lượng tiền giao dịch không hợp lệ

12 114 Ví điện tử không tồn tại

13 122 Hệ thống đang tạm dừng

14 125 Bản tin yêu cầu không hợp lệ

15 136 Tài khoản ví điện tử không có quyền thực hiện giao dịch

16 140 Hệ thống chưa hỗ trợ bản tin yêu cầu

17 141 Ví điện tử đang bị khóa do khai báo mất thẻ

18 151 Ví điện tử không đủ số dư để thực hiện giao dịch

19 154 Ví điện tử bị khóa vĩnh viễn

20 161 Số lượng tiền giao dịch vượt quá hạn mức cho phép

21 175 Vượt quá số lần nhập sai PIN cho phép. Hệ thống sẽ tạm thời khóa ví điện tử

22 177 Dữ liệu không đúng định dạng

23 178 Ngày giao dịch không hợp lệ

24 185 Hệ thống từ chối xử lý giao dịch

25 200 Giao dịch time-out

26 210 Mã dịch vụ yêu cầu không tồn tại

27 216 Mã số thẻ cào không tồn tại

28 217 Thẻ cào đã sử dụng



29 218 Thẻ cào đã hết hạn

30 219 Thẻ cào chưa kích hoạt

31 220 Thẻ cào đã bị khóa

32 230 Hệ thống đã ghi nhận và đang xử lý

33 908 Giao dịch time-out Bảng 18. Bảng mã lỗi dịch vụ



Tài liệu tham khảo

[1] Ray Rischpater, Beginning Java™ME Platform, APRESS 2008 [2] John W. Muchow, Core J2ME™ Technology & MIDP, Prentice Hall PTR [3] Jonathan Knudsen, Pat Niemeyer, Learning Java™, 2nd Edition, O'Reilly [4] Mourad debbabi, Mohamed Saleh, Chamseddine Talhi and Sami Zhioua, Java

for Mobile Devices: A Security Study. [5] Shivani Agarwal, Mitesh Khapra, Bernard Menezes and Nirav Uchat, Security

Issues in Mobile Payment Systems. [6] David Hook, Beginning Cryptography with Java, Wrox Press © 2005 [7] http://www.java-security-training-guide.com/session-key-systems.html : Các

khái niệm cơ bản về bảo mật [8] http://www.bouncycastle.org/java.html : Thư viện dùng để mã hóa [9] http://java.sun.com : Trang chủ Sun Java [10] http://discussions.nokia-asia.com/: Nơi thảo luận của Nokia [11] http://jcp.org : Trang chủ tổ chức Java Community Process

Sample - J2ME

Documents