Người dùng phải có password mới sử d ng được thành phần Coordinator. Password người dùng chỉ nhập lần đầu tiên trong quá trình sử d ng. Thành phần Coordinator có các chức năng chính được minh họa trong Hình 5.5 bao gồm:
Chức năng Receive Data Giao tiếp với điện thoại di động để l y các thông
Chức năng Auto Fill Điền thông tin tự động v o c c chương trình ứng
d ng trên window như Skype, Yahoo Messenger, Google Talk...
Chức năng Send Data Truyền dữ liệu thơng tin bí mật đã được mã hóa
băng public key của Relying Party đến Identity Provider.
Chức năng Receive Key Nhận public key của Relying Party từ thành phần
Identity Provider.
Chức năng Send Key Truyền public key đến MobileIdP.
Hình 5.6 minh họa qu trình điền thơng tin vào Yahoo Messenger và Google Talk.
Hình 5.6 Chức năng đi n thông tin t động vào Yahoo và Google Talk
5.2.5 Thành phần Plugin Browser
Người dùng phải có password mới sử d ng được thành phần Plugin Browser. Password người dùng chỉ nhập lần đầu tiên trong quá trình sử d ng. Thành phần Coordinator có các chức năng chính bao gồm:
Nhận các thuộc tính định danh từ thành phần Coordinator. Đây l những thuộc tính định danh mà Coordinator nhận được từ MobileIdP trước đó. Điền thuộc tính định danh tự động vào các trang web có sẵn trên mạng như
Google Mail, Yahoo Mail... Hình 5.7 minh họa qu trình điền thơng tin tự động vào trong Google Mail.
Hình 5.9 i n t động URI vào trang LiveJournal[29] 5.3 K t quả thử nghi m
Bảng 5.2 mô tả một số kết quả thử nghiệm hệ thống bao gồm các thuật tốn mã hóa đối xứng và b t đối xứng có sử d ng trong hệ thống.
Bảng 5.2 Th ng kê thời gian ký và giải mã thuộc nh đ nh danh quan trọng Chức năng Thu t toán Thời gian
(mili giây) Tham s
Thời gian mã hóa b t đối xứng (MobileIdP)
RSA 1433 Chiều d i thông điệp
là chuỗi 10 ký tự Thời gian giải mã b t
đối xứng (MobileIdP)
RSA 31 Chiều d i thông điệp
là chuỗi 10 ký tự Thời gian mã hóa đối
xứng (MobileIdP)
Rijndael 256 bit
124 Chiều d i thông điệp
là chuỗi 528 ký tự Thời gian giải mã đối
xứng
Rijndael 256 bit
62 Chiều d i thông điệp
là chuỗi 528 ký tự
Trong các thông kê này, thời gian mã hóa b t đối xứng trên điện thoại tốn nhiều thời gian nh t. Do điện thoại di động hạn chế về tốc độ và khả năng xử lý. Các thời gian xử lý trên mạng cũng như m y tính bên ngo i kh nhanh. Vì vậy, có thể áp d ng hệ thống vào thực tế.
Trong chương này chúng tơi đã trình bày về mơ hình triển khai của hệ thống đề nghị. Trong Chương 6 chúng tơi s trình bày về kết luận cũng như hướng phát triển của đề tài trong tương lai.
C ương 6
Kết luận v ướng p át triển
Nội dung của chương 6 trình bày về những kết quả đã đạt được trong luận văn và hướng phát triển của luận văn trong tương lai.
6.1 K t quả đạ được đ tài
Luận văn đã tìm hiểu, phân tích, đ nh gi về hệ thống quản lý định danh OpenID. Từ đó, chúng tơi đã tìm ra những ưu điểm và khuyết điểm của hệ thống OpenID. Dựa trên kết quả phân tích, chúng tơi đã tiến h nh đề xu t những mơ hình cải tiến dựa trên hệ thống OpenID chuẩn. Mơ hình cải tiến của hệ thống đã giải quyết hai v n đề chính:
Luận văn đã đề xu t phân loại thuộc tính định danh thành hai phần: Loại thứ nh t là các thuộc tính định danh thơng thường được lưu trữ trên mạng. Loại thứ hai là các thuộc tính định danh đặc biệt quan trọng được lưu trữ trên thiết bị di động. Dưa trên việc phân loại thuộc tính định danh, luận văn đã đề xu t mơ hình sử d ng hai loại thuộc tính định danh một cách hợp lý vừa đảm bảo tương thích với các hệ thống quản lý định danh sẵn có, vừa có thể bảo vệ an tồn những thơng tin bảo mật.
Để tương thích với các Relying Party trên mạng, luận văn đã đề xu t giải ph p điền thông tin tự động lên các Relying Party. Cải tiến này nhằm mở rộng hệ thống khơng những tương thích với các hệ thống đã hỗ trợ sẵn OpenID, mà hệ thống cịn có khả năng tương thích với các hệ thống khơng hỗ trợ OpenID.
Luận văn cịn tiến hành phân tích những v n đề liên quan đến hệ thống đã đề xu t dựa trên những tiêu chí chuẩn khi xây dựng một hệ thống quản lý định danh. Qua đó đã đề xu t sử d ng cơ chế mã hóa b t đối xứng bằng c ch mã hóa thơng điệp chứa thuộc tính định danh quan trọng bằng public key của Relying Party. Bên cạnh đó, luận văn cũng đề xu t các cơ chế truyền và nhận thông điệp giữa các thành phần để đảm bảo chỉ có đúng th nh phần Relying Party mới có thể giải mã được thơng điệp bằng cách hiện lên thông tin về public key về Relying Party cho người dùng kiểm tra và xác nhận.
Luận văn không những là mơ hình thử nghiệm v đã triển khai trên thực tế để kiểm tra tính tương thích với các hệ thống khác trong phân tích của hệ thống. Ngoài ra, trong phạm vi luận văn cũng đã tiến hành khảo s t v đưa ra những kết quả thống kê về thời gian mã hóa, giải mã của thuật tốn b t đối xứng, đối xứng...
6.2 Hướng phát tri n
Mặc dù luận văn đã có nhiều thử nghiệm, tuy nhiên hệ thống vẫn chưa được áp d ng rộng rãi trên mạng. Hướng sắp tới sẽ hoàn thiện, bổ sung các chức năng giúp cho hệ thống trở nên hoàn thiện hơn như:
Sử d ng C để kiểm tra public key của Relying Party, đồng thời l y thông tin Relying Party từ C để hiện lên cho người dùng xác thực. Điều này nhằm đảm bảo kẻ t n công không thể cung c p thông tin giả để lừa người dùng l y được thông tin cá nhân.
Áp d ng mạng ngữ ngh a để điền vào các trang b t kỳ trên mạng chứ không dừng lại ở hỗ trợ cho c c trang đăng nhập đơn giản nhập username và password hay điền tự động thông tin đăng ký v o c c trang đã biết trước c u trúc như hiện nay để tăng phạm vi sử d ng của hệ thống.
Triển khai rộng rãi hệ thống ở trên mạng, để qua đó nhận được những sự phản hồi từ nhiều người dùng nhắm cải thiện hệ thống được tốt hơn.
P ụ lục A CÁC T ÔNG ĐIỆP CỦA OPENID
Để hồn thành q trình chứng thực, các thành phần trong OpenID sẽ phải trao đổi nhiều thông điệp khác nhau. Những thông điệp n y đều theo một định dạng chuẩn, Relying Party và Identity Provider phải tuân theo những định dạng n y để giao tiếp.
Mỗi thơng điệp sẽ có một cặp (request và response). Request và response có thể có những tập tham số khác nhau. Tùy vào loại thông điệp, Relying Party và Identity Provider sẽ sử d ng phương ph p liên lạc trực tiếp hay gián tiếp (HTTP POST dùng cho liên lạc trực tiếp và HTTP GET dùng cho liên lạc gián tiếp).
Sau đây l một số c c thông điệp cơ bản được sử d ng trong hệ thống OpenID: Thông điệp associate.
Thông điệp checkid_immediate. Thông điệp checkid_setup.
Thông điệp check_authentication. Thông điệp associate request:
Thông điệp asscociate request được gửi từ Relying Party tới Identity Provider. M c đích chính của thơng điệp associate request l để thiết lập một khóa chia sẻ bí mật giữa Relying Party v Identity Provider. Thông điệp này có thể được Relying Party gửi vào b t cứ lúc nào. Đây là một liên lạc trực tiếp giữa Relying Party và Identity Provider nên HTTP POST được sử d ng cho thông điệp associate. Relying Party sẽ gửi một số các tham số kèm với associate request. Sau đây l danh s ch c c tham số của associate request:
openid.ns: đây là một tham số tùy chọn. Tham số n y dùng để khai báo phiên bản OpenID. Nếu tham số openid.ns không được khai báo, hệ thống sẽ tự hiểu phiên bản của OpenID là OpenID Authentication Compatibility Mode.
openid.mode: tham số n y dùng để phân biệt loại thông điệp. C thể ở đây
openid.assoc_type: tham số n y được dùng để chỉ ra thuật toán sử d ng để
ký lên thơng điệp. Ở đây có hai giá trị có thể có l : “HM C-SH 1” v “HM C-SH 256”.
openid.session_type: được dùng để khai báo loại mã hóa được sử d ng trong thông điệp để mã hóa khóa MAC (Message Authentication Code). Thuật tốn sẽ dùng một khóa cá nhân cùng với một thông điệp như đầu vào và cho ra một đoạn mã. Trong OpenID hỗ trợ hai thuật to n “DH-SH 1“ v “DH-SH 256”. Nếu giá trị của tham số n y l “no-encryption”, MAC sẽ khơng được mã hóa. Điều này chỉ nên sử d ng khi sử d ng một kết nối SSL giữa Relying Party và Identity Provider.
openid.dh_modulus: tham số đi kèm với DH-SHA1 hoặc DH-SHA256.
openid.dh_gen: tham số đi kèm với DH-SHA1 hoặc DH-SHA256.
openid.dh_consumer_public: tham số đi kèm với DH-SHA1 hoặc DH- SHA256.
Ba tham số trên là các thơng số cho thuật tốn DH-SHA1 và DH-SHA256, chi tiết về việc sinh ra giá trị cho các tham số n y được nêu chi tiết trong RFC-2631 (Diffie- Hellman Key Agreement Method)[39]. Bảng A.1 là một ví d về thơng điệp associate request.
Bảng A.1 Ví dụ v mộ h ng đi p associate request
openid.mode=associate&openid.assoc_type=HMAC-SHA1 &openid.session_type=DH-SHA1 &openid.dh_consumer_public=KC6IpA00A6SlCikafFSlrTGql9H8+de6GFi5YLK z4pyDxUMS5Z8pMOm/Ptr1gFmCcgAXjFbuxS73ZutDTFJYpADoIntFVrah9eaezMcw6 SDR24cnFjNc14xq0zGt3QcRLXaNTRVKfMW8evDAmLCrvEhU5c7B3eqmk+bMMrbQpcE =&openid.dh_modulus=ANz5OguIOXLsDhmYmsWizjEOHTdxfo2Vcbt2I3MYZuYe91 ouJ4mLBX+YkcLiemOcPym2CBRYHNOyyjmG0mg3BVd9RcLn5S3IHHoXGHblzqdLFEi/ 368Ygo79JRnxTkXjgmY0rxlJ5bU1zIKaSDuKdiI+XUkKJX8Fvf8W8vsixYOr&openi d.dh_gen=Ag==
Thông điệp associate response:
Thông điệp associate response được gởi từ Identity Provider đến Relying Party. Đây l một thông điệp HTTP 200 được định ngh a trong Hypertext Transfer Protocol [RFC 2616][15]. Thông điệp này chỉ ra sự kết hợp giữa Identity Provider và Relying Party thành công hay th t bại. Trong trường hợp kết hợp th nh công, thông điệp sẽ bao gồm một xử lý thông điệp và thời gian sống của xử lý đó tính bằng giây. Ngược lại, một lỗi sẽ được trả về. Danh sách các tham số của associate response:
openid.ns: đã được giải thích ở trên.
openid.assoc_handle: tham số này chỉ ra một chuỗi ASCII với chiều dài tối
đa 255 ký tự được dùng để quyết định khóa nào sẽ được sử d ng lại cho q trình mã hóa và giải mã.
openid.session_type: tham số này giống như trong trường hợp request nếu
kết hợp thành công. Ngược lại, tham số này sẽ l “unsuccessful response”. Có nhiều lý do khác nhau cho việc kết hợp không thành cơng. Ví d , Relying Party yêu cầu sử d ng SH 256 nhưng Identity Provider chỉ hỗ trợ SHA1.
openid.assoc_type: tham số này giống như trong trường hợp request nếu
kết hợp th nh công. Ngược lại, tham số này sẽ l “unsuccessful response”. openid.expires_in: tham số này chỉ ra thời gian (tính bằng giây) sự kết hợp
này sẽ khơng cịn hiệu lực nữa và relying party nên yêu cầu một sự kết hợp mới.
openid.mac_key: tham số n y được sử d ng chỉ khi giá trị của
“openid.session_type” l “no-encryption”. Gi trị của tham số này là khóa MAC mã hóa dựa trên cơ số 64.
openid.dh_server_public: tham số này là khóa cơng cộng của Identity
Provider. Tham số n y được sử d ng nếu request yêu cầu sử d ng thuật toán Diffie-Hellman.
openid.enc_mac_key: tham số n y l khóa M C đã được mã hóa, được sử
d ng nếu request yêu cầu sử d ng thuật toán Diffie-Hellman. Bảng A.2 là một ví d về thơng điệp associate response.
openid.assoc_handle: tham số này là tùy chọn. Tham số này chỉ ra một sự
kết hợp đã được khởi tạo giữa OpenID và Relying Party. Tham số n y đã được miêu tả trong phần associate request.
openid.return_to: tham số n y được sử d ng để khai báo cho máy chủ
OpenID vị trí của UR nơi sẽ chuyển tiếp cho trình duyệt sau khi xử lý yêu cầu. Máy chủ OpenID sẽ sử d ng địa chỉ UR n y để gởi response về cho Relying Party.
openid.realm: một tham số tùy chọn khác chỉ ra một URL máy chủ sử
d ng để định danh một Relying Party trong một cách duy nh t. Realm có thể bao gồm các ký tự wildcard như “*”. Ví d , realm có thể là
http://*.conformix.com.
Bảng A.3 là một ví d về thơng điệp checkid_setup request.
Bảng A.3 Ví dụ v một h ng đi p checkid_setup request
GET /index.php/serve?openid.assoc_handle={HMAC- SHA1}{46071e25}{Tt8MwQ==} &openid.identity=http://idp.conformix.com/?user= openidbook &openid.mode=checkid_setup&openid.return_to=http://consumer.con formix.com:80/finish_auth.php?nonce=nC5sKquX&openid.sreg.optional= email&o penid.trust_root=http://consumer.conformix.com:80/ HTTP/1.1
Thông điệp checkid_setup và checkid_immediate response:
Mỗi lần máy chủ OpenID nhận thông điệp checkid_setup, OpenID sẽ xử lý và gởi phản hồi về cho Relying Party thơng qua trình duyệt. Trong thơng điệp phản hồi, OpenID sẽ gởi nhiều tham số về cho Relying Party. Danh sách các tham số của checkid_setup response:
openid.ns: đã được giải thích ở trên.
openid.mode: có giá trị “id_res” khi kết hợp th nh công. Ngược lại sẽ
mang giá trị:
“setup_needed” khi request l checkid_immediate. “cancel” khi request l checkid_setup.
openid.op_endpoint: chỉ ra URL máy chủ OpenID.
openid.identity: đã được giải thích ở trên.
openid.return_to: tham số này là bản sao chép của URL Relying Party đã
gởi với thông điệp request.
openid.response_nonce: tham số n y được sử d ng để tránh các t n công
replay v được dùng đơn nh t cho mỗi thơng điệp, có chiều dài tối đa 255 ký tự, bao gồm một nhãn thời gian và các ký tự SCII thêm v o để trở th nh đơn nh t. Relying Party có thể từ chối kết hợp nếu nhãn thời gian quá xa so với thời điểm hiện tại. Ngày và giờ được định dạng trong phần 5.6 của [RFC3339] (Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps”)[27] với c c quy ước sau:
- Nằm trong múi giờ của UTC được nhận biết với ký tự “Z”. - Khơng được phép có phân số.
- Ví d : 2005-05-15T17:11:51ZUNIQUE.
openid.invalidate_handle: được sử d ng khi xử lý (handle) gắn với request
có đúng hay khơng. Nếu khơng đúng, tham số này là tùy chọn. Mặt khác, các xử lý sai nên được gắn với tham số này sẽ giúp cho Relying Party loại bỏ các xử lý sai từ các record của Relying Party.
openid.assoc_handle: handle được dùng để ký thơng điệp. Handle này có
thể khác với handle gốc được Relying Party gởi với request nếu OpenID không nhận ra handle gốc. Trong trường hợp này, máy chủ sẽ giữ một bản sao chép của handle mới để Relying Party có thể sử d ng cho m c đích kiểm tra.
openid.signed: bao gồm danh sách các tham số được ký. Các tham số cách
nhau bởi d u phẩy.
openid.sig: bao gồm chữ ký được mã hóa dựa trên cơ số 64.
Bảng A.5 Ví dụ v một h ng đi p check_authentication request openid.assoc_handle={HMAC-SHA1}{460730e1}{zr1gKg==} &openid.identity=http://idp.conformix.com/?user= openidbook &openid.invalidate_handle={HMAC- SHA1}{46071e25}{Tt8MwQ==} &openid.mode=check_authentication&openid.return_to=http://consumer.c onformix.com:80/finish_auth.php?nonce=mAotRbGM&openid.sig=4hwwyWbPt SAmP2dYxEC+dq605Os=&openid.signed=mode,identity,return_to,sreg.ema il&openid.sreg.email=rr@conformix.com
Thông điệp check_authentication response:
Danh sách các tham số của check_authentication response: openid.ns: đã được giải thích ở trên.
is_valid: tham số có giá trị “true” hoặc “false” để x c định chữ ký của việc
xác thực tính hợp lệ của request.
invalidate_handle: tham số tùy chọn được sử d ng trong trường hợp tham
số is_valid mang giá trị “true”, Relying Party sẽ loại bỏ handle từ danh sách c c handle đã lưu trữ.
Bảng A.6 Ví dụ v một h ng đi p check_authentication response
invalidate_handle:{HMAC-SHA1}{46071e25}{Tt8MwQ==} is_valid:true
Để tăng tính linh hoạt v tương thích, một số mở rộng (extension) của OpenID đã được đề xu t. Một số mở rộng đã ho n thiện trong khi một số kh c còn đang trong giai đoạn phác thảo, thử nghiệm. Những thông tin mới nh t về các mở rộng có thể xem tại đây http://openid.net/developers/specs .
Những mở rộng đã v đang ph t triển có chức năng giải quyết các công việc sau: Đăng ký người dùng (User Registration): cho phép Relying Party đăng ký
người dùng mới khi họ đăng nhập lần đầu tiên vào một website.
Tra cứu khóa dịch v (OpenID Service Key Discovery) sử d ng Yadis. Thơng điệp DTP (DTP Message), được mã hóa MIME.
Trao đổi thuộc tính (Attribute Exchange). Độ tin cậy của xác thực (Assertion Quality).
Quản lý chính sách chứng thực của Identity Provider (Provider Authentication Policy Extension – P PE), dùng để chống giả mạo (anti- phishing) và những m c đích kh c.
Bảng A.7 Một h ng đi p checkid_setup request với Simple Registration