andRie's Blog

January 6, 2011

Solusi Enkripsi Untuk Masalah User Authentication

Filed under: v-class — andriedwicn @ 1:02 pm

Bila ditanya tentang solusi yang digunakan untuk masalah user authentication maka jawabannya adalah KERBEROS…
Karena  KERBEROS dapat digunakan sebagai :
• solusi untuk user authentication
• dapat menangani multiple platform/system
• free charge (open source)
• IBM menyediakan versi komersial : Global Sign On (GSO)

Tetapi bila saya boleh artikan satu persatu dimana Authentication atau autentikasi adalah proses verifikasi identitas dari seorang anggota yang memberikan suatu data, dan integritas dari data tersebut.
Sedangkan KERBEROS merupakan layanan autentikasi yang dikembangkan oleh MIT (Massachusetts Institute of Technology) Amerika Serikat, dengan bantuan dari Proyek Athena.
Tujuannya adalah untuk memungkinkan pengguna (user) dan layanan (service) untuk saling mengautentikasi satu dengan yang lainnya. Dengan kata lain, saling menunjukkan identitasnya.

Untuk lebih jelasnya mengenai KERBEROS maka dibawah ini akan saya jelaskan operasi atau cara kerja KERBEROS yang berhubungan dengan user authentication.

1. Authentication Server Request (AS_REQ)
Pada tahap ini, pengguna meminta AS untuk mendapatkan Ticket Granting Ticket. Request ini tidak dienkripsi dan tampak seperti ini:

AS_REQ = ( Principal Client, Principal Service, IP_list , Lifetime )

2 Authentication Server Reply (AS_REP)
Ketika pesan sebelumnya masuk, AS memeriksa apakah PrincipalClient dan PrincipalService berada di database KDC. Jika salah satu saja dari antaranya tidak ada, maka pesan error dikirimkan kepada pengguna. Jika keduanya ada, maka AS akan memroses sebagai berikut:
• Secara random, AS akan membuat session key yang akan menjadi rahasia antara pengguna dan TGS, sebutlah SKTGS.
• AS membuat Ticket Granting Ticket. Di dalamnya terdapat request dari principal pengguna, principal layanan, daftar IP address, tanggal dan waktu, lifetime, dan SKTGS.

TGT = ( Principal Client, krbtgt/REALM@REALM , IP_list , Timestamp , Lifetime , SK TGS)

• AS membuat dan mengirimkan balasan yang berisi: ticket yang dibuat sebelumnya yang dienkripsi menggunakan secret key untuk layanan (K TGS), principal layanan, timestamp, lifetime, dan session key semuanya dienkripsi menggunakan secret key untuk pengguna melakukan request terhadap layanan (K USER)

AS_REP = { Principal Service, Timestamp , Lifetime , SK TGS}K User{ TGT }KTGS

3 Ticket Granting Server Request (TGS_REQ)
Pada tahap ini, pengguna yang sudah terautentikasi (artinya dalam credential cache nya terdapat TGT dan session key SK TGS) dan ingin mengakses layanan tetapi belum mempunyai tiket yang sesuai, mengirimkan request (TGS_REQ) kepada Ticket Granting Service dengan konstruksi sebagai berikut:
• Membuat authenticator dengan principal pengguna, timestamp dari mesin pengguna dan mengenkripsi semuanya dengan session key yang dibagi bersama dengan TGS.
• Membuat paket request yang berisi: principal layanan yang mana dibutuhkan ticket dan lifetime yang tidak dienkripsi, Ticket Granting Ticket yang sudah dienkripsi menggunakan key dari TGS, dan authenticator yang baru saja dibuat

TGS_REQ = ( Principal Service, Lifetime , Authenticator) { TGT }K TGS

4 Ticket Granting Server Reply (TGS_REP)
Ketika pesan sebelumnya tiba, pertama-tama TGS memverifikasi bahwa principal dari layanan yang diminta ada di dalam database KDC. Jika ada, TGS membuka TGT dan mengekstrak session key SKTGS yang digunakan untuk mendekripsikan authenticator. Agar service ticket dapat dibuat, TGS memeriksa apakah kondisi-kondisi ini tercapai:
• TGT belum kadaluwarsa
• PrincipalCLIENT yang terdapat pada authenticator cocok dengan yang ada pada TGT
• Authenticator tidak terdapat pada replay cache dan belum kadaluwarsa
• Jika IP_List tidak kosong, maka TGS memeriksa apakah alamat IP sumber dari paket request terdapat pada list tersebut
Kondisi-kondisi tersebut di atas membuktikan bahwa TGT benar-benar kepunyaan pengguna yang melakukan request dan kemudian TGS memulai proses sebagai berikut:
• Secara random, TGS membuat session key yang akan menjadi rahasia antara pengguna dengan layanan, sebutlah SKSERVICE.
• TGS membuat service ticket yang di dalamnya berisi principal pengguna, principal layanan, daftar alamat IP, tanggal dan waktu, lifetime, dan SKSERVICE. Ticket ini disebut T SERVICE.

T Service = ( Principal Service, Principal Service, IP_list , Timestamp , Lifetime , SK Service)

• TGS mengirim pesan balasan yang berisi: ticket yang baru saja dibuat yang dienkripsi menggunakan secret key milik layanan (K SERVICE), principal layanan, timestamp, lifetime, dan session key yang baru, semuanya dienkripsi menggunakan session key yang diekstrak dari TGT.

TGS_REP = { Principal Service, Timestamp , Lifetime , SK Service}SK TGS{ T Service}K Service

5 Application Request (AP_REQ)
Pengguna, yang mempunyai credential untuk mengakses layanan, dapat meminta server layanan agar ia dapat mengakses sumber-sumber melalui pesan AP_REQ. Tidak seperti pesan-pesan sebelumnya dimana KDC terlibat, AP_REQ bukanlah standar tetapi bervariasi bergantung aplikasi yang digunakan. Oleh karena itu, programmer aplikasi harus membuat strategi dimana pengguna dapat menggunakan credentialnya untuk membuktikan identitasnya kepada server. Contoh strategi yang dapat digunakan adalah sebagai berikut:
• Pengguna membuat authenticator yang berisi principal pengguna dan timestamp, dan mengenkripsi semuanya dengan menggunakan session key SK SERVICE

Authenticator = { Principal Client, Timestamp }SK Service

• Membuat paket request yang berisi ticket layanan TSERVICE yang dienkripsi menggunakan secret key nya dan authenticator yang baru saja dibuat.

AP_REQ = Authenticator { T Service}K Service

Ketika request sebelumnya tiba, server layanan membuka ticket menggunakan secret key untuk layanan yang diminta dan mengekstrak session key SK Service yang digunakan untuk mendekripsikan authenticator. Untuk mengautentikasi pengguna, maka server memeriksa kondisi-kondisi sebagai berikut:
• Ticket belum kadaluwarsa
• Principal CLIENT yang ada dalam authenticator cocok dengan yang ada di ticket
• Authenticator tidak terdapat dalam replay cache dan belum kadaluwarsa
• Jika IP_List (diekstrak dari ticket) tidak kosong, maka diperiksa apakah alamat IP dari AP_REQ berada dalam daftar tersebut..

 

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: