Quy trình do chúng tôi đề xu t là mở rộng cho trường hợp Relying Party yêu cầu các thuộc tính định danh quan trọng. Vì vậy, nếu Relying Party yêu cầu thuộc tính định danh thông thường thì hệ thống quản lý định danh cải tiến có thể hoạt động giống hoàn toàn với hệ thống OpenID thông thường. Do đó, hệ thống cải tiến vẫn đảm bảo
được đầy đủ các tính ch t mà hệ thống OpenID có. Ngoài ra, hệ thống cải tiến còn có một số ưu điểm sau. Những tính ch t sau chúng tôi phân tích dựa trên những tính ch t cần phải có của hệ thống quản lý định danh đã được trình bày trong phần 2.3.
Vấn đề khi lưu trữ thuộc tính định danh quan trọng trên MobileIdP
Hiện nay, ngày càng nhiều người dùng sử d ng điện thoại di động. Hơn nữa, điện thoại di động thường được quản lý trực tiếp bởi người dùng. Kẻ t n công khó có thể tiếp cận trực tiếp với thiết bị này. Với những lý do trên, việc lưu trữ và quản lý thuộc tính định danh trên thiết bị di động tương đối an to n. Hơn nữa, Identity Provider trên thiết bị di động còn được bảo vệ bởi password của người dùng; điều này làm nâng cao khả năng bảo vệ thuộc tính định danh của điện thoại di động, nh t l đối với những thuộc tính định danh r t quan trọng nhưng khó nhớ của người dùng (như mã số tài khoản credit card, mật khẩu thẻ TM…).
Vấn đề khi lưu trữ thuộc tính định danh thông thường trên Identity Provider bên ngoài
Mặc dù bảo vệ thông tin trên điện thoại di động là r t an toàn. Tuy nhiên, có nhiều thuộc tính định danh thông thường không nh t thiết chúng ta phải lưu trữ trên điện thoại di động. Ví d như ng y sinh, giới tính, địa chỉ, điện thoại… Nếu những thuộc tính định danh này chỉ lưu trên thiết bị di động m không lưu ở bên ngoài thì thành phần Identity Provider không thể thực hiện c c định danh thông thường nếu không có điện thoại di động.Việc lưu những thuộc tính định danh thông thường trên Identity Provider sẽ tiện d ng hơn cho người dùng trong những trường hợp thành phần Relying Party chỉ yêu cầu định danh ở những thuộc tính thông thường của người dùng.
Nhận xét: Việc chia thuộc tính định danh ra làm hai loại: Thuộc tính định danh
quan trọng lưu trên điện thoại di động và thuộc tính định danh ít quan trọng lưu trên Identity Provider đã tận d ng được c c ưu điểm của hai hệ thống quản lý định danh tập trung và quản lý định danh phân tán.
Người dùng và Relying Party mới biết các thuộc tính định danh quan trọng
Thuộc tính định danh quan trọng lưu trên thiết bị di động được mã hóa bằng public key của Relying Party. Hơn nữa, thông tin trên điện thoại di động được mã hóa bằng password người dùng nhập vào. Vì vậy, chỉ có người dùng và Relying Party biết những thông tin này. Điều này không những chỉ bảo mật với những thành phần khác mà ngay cả Identity Provider v MobileIdP cũng không thể biết thuộc tính định danh do không có password của người dùng. Việc không cho thành phần Identity Provider biết các thuộc tính định danh quan trọng không những đảm bảo bí mật đối với Identity Provider mà còn giúp cho hệ thống cải tiến tương thích với nhiều Idenity Provider khác nữa.
Vấn đề khi người dùng mất điện thoại di động
Password người dùng sử d ng ở MobileIdP được sử d ng với hai vai trò sau: MobileIdP sẽ hash password cùng thông tin ngẫu nhiên (thời gian tạo). Giá
trị hash và thông tin ngẫu nhiên sẽ được lưu lại để kiểm tra password sau này.
MobileIdP sẽ hash password để làm khóa cho thuật to n đối xứng mã hóa các thuộc tính định danh của người dùng.
Với cách xử lý như trên đảm bảo rằng MobileIdP không thể biết khóa của thuật toán mã hóa đối xứng. Khóa chỉ được biết khi người dùng nhập vào password. Vì vậy, MobileIdP không thể biết được thuộc tính định danh. Điều n y đảm bảo mặc dù bị m t điện thoại thì vẫn không lộ thuộc tính định danh.
Vấn đề về lịch sử trình duyệt
Do t t cả các thông tin truyền qua lại đều được mã hóa, kẻ t n công không thể dựa vào lịch sử trình duyệt để suy ra những thông tin có ích cho mình. Vì vậy, v n đề về lịch sử trình duyệt an to n đối với hệ thống cải tiến.
Khả năng tương thích với hệ thống vốn có
Hệ thống cải tiến chỉ bổ sung mà không sửa đổi c u trúc có sẵn của hệ thống OpenID vì vậy có khả năng tương thích với t t cả các thành phần có hỗ trợ sẵn
OpenID trên mạng. Hơn nữa, với hướng mở rộng này sẽ làm cho OpenID trở nên tin cậy hơn do các thuộc tính định danh quan trọng được lưu trữ trên thiết bị di động. Qua đó giúp cho ng y c ng nhiều c c định danh quan trọng qua mạng có thể dựa trên nền tảng của hệ thống đề xu t như: mua bán trực tiếp qua mạng, truyền và nhận các thông tin tuyệt mật giữa hai đối t c, tư v n những v n đề về sức khỏe, tâm lý...
Tính thân thiện
Trong các thành phần của hệ thống, người dùng chỉ cần nhập password một lần trong suốt quá trình thực hiện định danh. Sau khi kết thúc, chương trình sẽ tự động xóa các thuộc tính định danh. Điều này vừa tạo nên cảm giác thoải m i khi người dùng sử d ng hệ thống, vừa đảm bảo tính an toàn của các thuộc tính định danh.
Phân tích các phương pháp tấn công đối với hệ thống cải tiến
Phương ph p tấn công phishing: Việc thực hiện quản lý thuộc tính định danh quan trọng trên thiết bị di động làm cho kẻ t n công sử d ng phương pháp phishing trở nên khó khăn hơn r t nhiều. Kẻ t n công khó có thể tiếp cận trực tiếp điện thoại di động của người dùng để cài đặt các phần mềm thực hiện phương ph p phishing do điện thoại thường được bảo vệ bởi mã PIN của máy. Vì vậy, hệ thống cải tiến khá an toàn với phương pháp phishing.
Phương ph p tấn công man-in-the-middle: Đường truyền từ Identity Provider v Relying Party đã c i đặt SS . Thông tin trên đường truyền này sẽ chống lại được phương ph p t n công man-in-the-middle. Thông tin truyền từ Mobile IdP đến Identity Provider được mã hóa b t đối xứng bằng public key của Relying Party nên đảm bảo chỉ có Relying Party mới có thể đọc được thông điệp. Thông tin public key của Relying Party được xác nhận trực tiếp bởi người dùng. Vì vậy, hệ thống phần lớn sẽ an toàn với phương pháp t n công man-in-the-middle. Giải pháp của chúng tôi sắp tới sẽ dùng C để kiểm tra trực tiếp public key của Relying Party. Khi đó, phương ph p t n công man-in-the-middle sẽ được khống chế hoàn toàn.
Phương ph p tấn công replay: Mỗi thông điệp truyền qua lại giữa các thành phần trong hệ thống đều có giá trị thời gian quy định thời gian hết hạn của thông điệp. Vì vậy, tổ chức bên ngoài không thể sử d ng phương ph p t n công replay để t n công hệ thống.
Tạo Relying Party giả để lấy thông tin người dùng
Trường hợp mà kẻ t n công có thể thực hiện là giả thành phần Relying Party để l y các thuộc tính định danh quan trọng của người dùng. Phương ph p t n công này có thể bị hạn chế do Idenity Provider đã gởi cho MobileIdP thông tin của Relying Party (public key của Relying Party). Người dùng thực hiện kiểm tra thông tin trực tiếp trên điện thoại di động trước khi xác nhận truyền thông điệp quan trọng đi. Có một cách khác mà hệ thống cải tiến có thể phát triển trong tương lai l Identity Provider sẽ gởi thông tin gi y chứng nhận của Relying Party. MobileIdP sẽ kiểm tra gi y chứng nhận này bằng cách kiểm tra trực tiếp trên tổ chức CA. Nếu điều này thực hiện được thì kẻ t n công không thể giả Relying Party để l y thông tin của người dùng được.
4.3 Q nh đ nh danh ng ường hợp Relying Party không hỗ trợ OpenID
4.3.1 V n đ
Hiện nay, đã có r t nhiều Relying Party trên mạng sử d ng OpenID. Tuy nhiên, vẫn còn r t nhiều các Relying Party chưa p d ng OpenID mà chỉ sử d ng định danh thông thường như đăng nhập username và password (Yahoo Messenger, Skype, Google Talk, Yahoo Mail...). Vì vậy, v n đề làm sao cho hệ thống quản lý định danh vẫn có thể áp d ng cho những thành phần Relying Party này.
4.3.2 Hướng giải quy t
Hướng giải quyết m chúng tôi đề xu t là xây dựng một plugin có khả năng tự động tìm ra được những đối tượng cần định danh trên web (như ô đăng nhập username và password, các ô liên quan đến qu trình đăng ký như địa chỉ, giới tính, ngày sinh...) để từ đó có thể tự động điền các thuộc tính định danh nhận từ điện thoại di động.
Các thành phần trong hệ thống định danh trong trường hợp Relying Party không hỗ trợ OpenID được minh họa trong hình Hình 4.2.
Internet
Máy tính bên ngoài
MobileIdP Website khác Application Browser Plugin Browser Coordinator Hình 4.4 Các thành phần củ nh đ nh nh ng ường hợp Relying Party không hỗ trợ OpenID.
4.3.3 Quy trình hoạt động
Quy trình hoạt động chia làm hai loại
Quy trình điền thông tin tự động lên trang web
Quy trình điền thông tin tự động lên ứng d ng windows Quy trình điền thông tin tự động lên trang web
Quy trình của hệ thống sẽ điền thông tin tự động lên các trang web có sẵn không hỗ trợ OpenID được thể hiện trong Hình 4.5.
- Trang yêu cầu người dùng nhập vào URI của Identity Provider theo cơ chế đăng nhập của OpenID.
Bước 6: Trình duyệt dựa v o UR người dùng nhập v o để truy cập vào Website tương ứng.
Bước 7: Website sẽ trả về người dùng trang yêu cầu người dùng cung c p thông tin:
- Thông tin về username v password đối với trang đăng nhập
- Thông tin về tên người dùng, email, ngày sinh, giới tính, địa chỉ... đối với những trang đăng nhập
- Thông tin về URI của Identity Provider đối với những trang đăng nhập theo cơ chế OpenID.
Bước 8: Browser sẽ hiển thị các thông tin nhận được từ Website đến người dùng.
Bước 9: Plugin hiện thị màn hình yêu cầu người dùng nhâp password để giải mã các thông tin nhận được từ điện thoại di động ở bước 4.
Bước 10: Người dùng sẽ nhập password để giải mã thông tin định danh. Bước 11: Plugin Browser sẽ kiểm tra password người dùng. Sau đó, Plugin
Browser sẽ giải mã các thuộc tính định danh. Cuối cùng sẽ điền các thông tin định danh tương ứng với các Website theo cơ chế sau và trả về cho Relying Party.
- Đối với những trang đăng nhập: Plugin tự động tìm Textbox có thuộc tính password. Từ đó, Plugin sẽ x c định Textbox ngay trước password sẽ là username. Cuối cùng, Plugin sẽ điền thông tin vào các ô tương ứng.
- Đối với những trang đăng ý: Plugin sẽ dựa trên danh sách tên các control đã được đăng ký sẵn trước đó đề điền thông tin vào các control tương ứng. Control này có thể là textbox, combobox, Radio button, Checkbox...
- Đối với trang cần điền URI của Identity Provider: Plugin sẽ tìm Textbox với tên được đăng ký sẵn v điền URI của Identity v o tương ứng.
Quy trình điền thông tin tự động lên các ứng dụng trên máy tính cá nhân
Quy trình điền thông tin tự động lên các ứng d ng của window được thể hiện trong Hình 4.6. a bước đầu tiên của quy trình thực hiện truyền thông tin định danh từ điện thoại di động sang thành phần Coordinator giống với quy trình điền thông tin tự động lên các website. Vì vậy, chúng tôi sẽ chỉ trình bày từ bước 4 đến bước 6 trong quy trình:
Hình 4.6 Q nh đi n thông tin t động lên các ứng dụng của window
Bước 4: Coordinator hiển thị màn hình yêu cầu người dùng nhâp password để giải mã các thông tin nhận được từ điện thoại di động ở bước 3.
Bước 5: Người dùng sẽ nhập password để giải mã thông tin định danh. Sau đó, người dùng yêu cầu Coordinator kích hoạt ứng d ng v điền các thông tin định danh tương ứng.
Bước 6: Coordinator kích hoạt ứng d ng v điền thông tin định danh tương ứng. Thông tin ở đây thông thường là các ô username và password trong các ứng d ng như Yahoo Messenger, Google Talk, Skype...
MobileIdP 3 6 1 2 Coordinator Application Người dùng 4 5
4.3.4 Phân tích quy trình
Khả năng phòng tránh lỗi
Khi sử d ng hệ thống OpenID, người dùng phải điền chính x c UR v o ô đăng nhập. Việc nhớ t t cả c c địa chỉ n y l không đơn giản. Thông thường, để vào một trang web, người dùng thường có xu hướng tìm trang đó trên Google, hoặc đã bookmark trang đó lại trước. Với sự hỗ trợ của hệ thống cải tiến, plugin trên Browser sẽ hỗ trợ điền tự động chính xác URL của Identity Provider. Điều này góp phần hỗ trợ hạn chế những lỗi xảy ra. Hơn nữa, người dùng cảm th y thoải m i hơn khi sử d ng hệ thống.
Khả năng tương thích với các chức năng vốn có của hệ thống
Hiện nay trên mạng có r t nhiều trang web đăng nhập kh c nhau. Để những trang web này hỗ trợ OpenID cần phải chỉnh sửa nội dung của trang web. Điều này r t khó thực hiện vì phải thay đổi cơ chế hoạt động của các trang web này. Tuy nhiên, với hệ thống đề xu t có thể tương thích ngay với các hệ thống sẵn có trên mạng. Plugin của hệ thống sẽ tự động tìm những ô username và password cần thiết để điền thông tin thay vì Relying Party chủ động sửa trang web theo cơ chế của OpenID để l y được những thuộc tính định danh thích hợp.
Độ an toàn thông tin khi lưu trữ thuộc tính định danh trên điện thoại di động
Trong quy trình cải tiến thứ hai, các thuộc tính định danh đều được lưu trữ trên điện thoại di động. Các thuộc tính định danh này chỉ thật sự truyền qua máy tính bên ngoài khi thực hiện định danh. Phần mềm không lưu trữ password và thông tin cá nhân của người dùng trong quá trình thực hiện định danh. Các thông tin truyền qua lại giữa các thành phần đã được mã hóa bằng password của người dùng. Vì vậy, thuộc tính định danh của người dùng sẽ đảm bảo không bị lộ ra bên ngoài.
Khả năng sử dụng định danh trên nhiều máy khác nhau
Việc sử d ng điện thoại di động để lưu trữ thuộc tính định danh giúp người dùng có thể sử d ng hệ thống trên nhiều máy khác nhau trên mạng với cùng thuộc tính định danh. Máy tính bên ngoài chỉ cần c i đặt thêm plugin và thành phần Coordinator để thực hiện định danh. Hai phần mềm này không lưu trữ thuộc tính định danh nên có thể công bố rộng rãi trên mạng.
Phân tích phương pháp tấn công phishing
Phương ph p t n công phishing đối với thiết bị di động là r t khó khăn vì đây l thiết bị được quản lý trực tiếp bởi người dùng. Trong quy trình cải tiến này, có sử d ng phần mềm bên ngoài. Vì vậy, kẻ t n công vẫn có thể tận d ng cài key logger trên m y tính bên ngo i. Khi đó c c thông tin về các tài khoản vẫn có thể bị lộ. Giải pháp này có thể được khắc ph c trong window cardspace nhờ cơ chế ngăn c m c c chương trình không liên quan chạy trong quá trình thực hiện định danh. Chúng tôi đang thực hiện nghiên cứu để áp d ng giải pháp này vào hệ thống.
Trong chương này đã trình bày về các thành phần của hệ thống do chúng tôi đề xuất nhằm mở rộng hệ thống OpenID và trình bày cũng như ph n tích những quy trình mở rộng của hệ thống đề xuất. Trong Chương 5 chúng tôi s trình bày phần thử nghiệm hệ thống đã đề nghị.
C ương 5
T ử ng iệm ệ t ống
Nội dung của chương 5 trình bày về phần thử nghiệm hệ thống à chúng tôi đã đề xuất.
5.1 Thử nghi m h th ng
Hệ thống đề xu t đã được chúng tôi xây dựng và thử nghiệm trên máy laptop: