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.
Sinh viên thực hiện: Lê Sỹ Đức - Khóa K50 - Lớp CNPM 69
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.
Sinh viên thực hiện: Lê Sỹ Đức - Khóa K50 - Lớp CNPM 70
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
Sinh viên thực hiện: Lê Sỹ Đức - Khóa K50 - Lớp CNPM 71
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.
Sinh viên thực hiện: Lê Sỹ Đức - Khóa K50 - Lớp CNPM 72
Chương 4. THIẾT KẾ