Perkembangan pesat dari sistem komunikasi mobile, penerapan sistem 3G saat ini, penyebaran
sistem 4G masa depan, dan interkoneksi dari banyak jaringan nirkabel yang berbeda-beda, telah
memfasilitasi pelanggan untuk mengakses layanan mobile dan aplikasi kapan saja dari mana
saja. Telah digarisbawahi bahwa yang sangat bersifat personal, konteks aware, lokasi yang
sensitif, aplikasi pada waktu kritis, yang dilakukan dengan cara yang sangat aman adalah layanan mobile paling menjanjikan. Layanan tersebut secara teknis dimungkinkan sebagai perangkat mobile modern seperti ponsel 3G dan PDA biasanya dilengkapi dengan fungsi lanjutan
(misalnya, browsing internet) dan kemampuan komputasi yang kuat (yang dapat digunakan
untuk melakukan operasi seperti encryptions kriptografi kunci publik).
Untuk menyediakan layanan mobile berkualitas tinggi di lingkungan nirkabel, satu kebutuhan
tidak hanya kenyamanan dan fleksibilitas, tetapi juga keamanan dan privasi pada desain
arsitektur dan protokol. Meskipun ada banyak usulan untuk mengamankan layanan mobile
(misalnya, [1,4,10,14,16,18,20,22,25-27,34-36]), kebanyakan mereka hanya memberikan bagian dari sifat yang diinginkan. Sebagai contoh, protokol yang diusulkan dalam [34-36] sangat rentan terhadap pemalsuan dan serangan modifikasi (lihat bagian 7.1 untuk rincian), sedangkan [10, 22] tidak memberikan anonimitas identitas untuk pelanggan. Selain itu, banyak solusi yang terbatas pada teknik spesifik atau jenis layanan tertentu. Sebagai contoh, keamanan modul diperkenalkan pada [10] adalah khusus untuk gateway WAP, dan protokol di [34-36] didasarkan pada algoritma kriptografi tertentu.
Dalam tulisan ini, kami mengusulkan sebuah tiket berbasis arsitektur serta protokol generic.
Untuk mengontrol akses ke layanan mobile. tiket adalah sepotong informasi yang memungkinkan pelanggan untuk mengakses jenis layanan tertentu., protokol kami memiliki
properti berikut. Pertama, merupakan solusi generik independen dari algoritma kriptografi dan
mode layanan. Kedua, aman terhadap berbagai serangan berbahaya pada layanan mobile. Ketiga, anonimitas memberikan identitas untuk pelanggan dan / atau penyedia layanan tergantung pada kebutuhan bisnis. Keempat, fleksibel dalam lingkungan yang dinamis di mana pelanggan dan / atau penyedia layanan cross multiply domain. Kami juga menunjukkan pilihan implementasi yang efisien dari protokol generik berdasarkan algoritma tanda tangan digital kurva eliptik.
The Ticket-based Architecture (Arsitektur berbasis Tiket)
Ada empat peran/pihak pada arsitektur yang kami ajukan, yaitu trusted authority (TA), trusted
credential (TC), customer (C) dan provider (P). Kita menggunakan nama user (U) ketika kita
tetapkan sebagai C atau P.
Dalam protokol ini, diasumsikan bahwa (1) TA benar-benar dipercaya oleh semua pihak lain; (2)
TC dipercaya untuk menjalankan proses pengisiian tagihan, membuat clearance, dan
memperbarui informasi publik dengan benar. (3) C dan P tidak memiliki kepercayaan satu sama
lain dan dan ingin menjadi anonymous terhadap entitas lain kecuali TA Pelanggan dan provider (penyedia layanan) perlu mendaftar ke TA sehingga bisa terlibat dalam layanan mobile. Pada proses registrasi, identitas sebenarnya dari semua peserta diverifikasi.
Pasangan informasi public dan rahasia kemudian dibangkitkan/dibuat untuk setiap entitas yang
terdaftar, bersama dengan identitas virtual yang akan digunakan dalam transaksi ke depan untuk alasan anonymous (jika entitas yang terlibat tidak peduli dengan anonimitas, makaidentitas virtual bisa berupa identitas sebenarnya).
Ketika seorang pelanggan bermaksud untuk mengakses layanan suatu provider (pengedia
layanan),pendahulu (the former) diperlukan untuk melewatkan tiket yang sesuai yang nantinya
oleh yang belakangan (the latter) dapat memeriksa informasi tentang layanan yang sedang
diminta. Tiket dibangkitkan sendiri oleh pelanggan dengan menggunakan kunci rahasia (secret
key) milik pelanggan itu sendiri.
Setelah menerima tiket, provider memeriksa validitas dan menyediakan layanan sesuai dengan
tiket. Tiket kemudian diteruskan ke TC untuk pengisian tagihan terhadap pelanggan
(pembayaran kepada TC) dan membuat clearance (pembayaran terhadap penyedia layanan).
Rincian prosedur tagihan berada di luar cakupan makalah ini, yang mana banyak protokol secure
electronic payment dapat digunakan. Terakhir, informasi rinci tentang tiket, tagihan-tagihan, dan clearance disimpan di pusat data (data center) milik TC. Informasi publik milik pelanggan dan provider seperti virtual ID, public key (yang terikat untuk identitas virtual), tipe layanan, dan waktu valid juga disimpan di pusat data. Untuk mencegah duplikasi dan pemalsuan tiket,
informasi public key milik pelanggan diperbarui melalui key update protocol setelah setiap
eksekusi penggunaan tiket. Akibatnya, skema kita tidak membutuhkan banyak kunci disimpan di sisi pelanggan, di mana penyimpanan terbatas dalam lingkungan mobile.
2.3 Protokol Umum untuk Kontrol Akses pada Layanan Mobile (Generic Protocol for
Controlling Access to Mobile Services)
Berikut ini definisi – definisi yang digunakan pada protokol umum ini, :
a. Fungsi hash.
Fungsi hash juga dikatakan fungsi satu arah yang digunakan dalam komponen
kriptofrafis seperti pseudo-random generation, digital signature dan otentikasi pesan.
Misal H(x) adalah fungsi hash. Secara komputasi susah untuk menemukan x dari y
sehingga H(x)= y, di mana x merupakan sebuah vektor. Secara umum, fungsi hash adalah
pemetaan satu arah dari bit-string dengan panjang sembarang {0, 1}* ke bit-string dengan
panjang tetap {0, 1}k, dan nilai image diasumsikan terdistribusi merata pada {0, 1}k.
b. Signature.
Sebuah skema signature terdiri dari algoritma berikut.
• (SK,PK) = Gen(1k): Key generation adalah probabilistic polynomial-time algorithm yang mengambil security parameter 1k sebagai input dan menghasilkan pasangan kunci public
dan kunci rahasia (SK,PK). • σ = Sig(SK,m): Signature signing adalah algoritma yang mengambil (SK,m) sebagai input dan menghasilkan signature σ pada pesan m.
• Ver(PK,σ) ?= 1: Signature verification adalah (probabilistic) polynomial-time algorithm
yang mengambil (PK,σ) sebagai input dan menghasilkan nilai 1 (True) untuk penerimaan
signature atau 0 (False) untuk penolakan signature
Generic Protocol
Protokol yang diusulkan dapat diimplementasikan berdasarkan suatu algoritma kunci publik
praktis, seperti RSA, ElGamal, dan ECC. Selain itu, protokol ini dapat dengan mudah
digabungkan dengan mode layanan yang berbeda yang masing-masing berkorespondensi dengan jenis tiket. Buttyán dan Hubaux mengklasifikasikan tiket dalam layanan mobile menjadi empat kategori, tergantung pada apakah tiket terikat kepada pelanggan dan penyedia layanan. Dalam solusi kami, baik pelanggan dan penyedia layanan dapat memilih untuk menjadi anonim,
sehingga memungkinkan untuk semua jenis tiket. Seorang pelanggan dapat menjual atau
memberikan tiket kepada pelanggan lain, atau menetapkan berbagai layanan dimana tiketnya
berlaku. Pelanggan dapat menggabungkan penggunaan beberapa kendala (misalnya, yang akan
menyediakan / menerima apa jenis layanan di mana kondisi) menjadi sebuah tiket (lebih
tepatnya, pesan m) sehingga menggagalkan penangkapan atau penyalahgunaan tiket. Di sisi lain,
kendala penggunaan dapat dipublikasikan dalam TC (bersama-sama dengan identitas pengguna
dan kunci publik), sebuah penyedia layanan dapat memeriksa tiket terhadap informasi tersebut
sehingga memudahkan kontrol akses yang bagus di layanan mobile.
Perhatikan bahwa protokol kita dapat dengan mudah diintegrasikan dengan teknik enkripsi
standar dan metode billing. Standar enkripsi dapat disediakan pada lapisan jaringan yang
mendasar sehingga semua komunikasi (antara TA, TC, pelanggan, dan penyedia layanan)
terenkripsi. Untuk proses billing, banyak protokol pembayaran elektronik yang aman seperti
pembayaran-mikro [25, 38] dapat diterapkan antara TC, pelanggan, dan penyedia. Sebuah
pembayaran dapat dibayar di muka (seperti pembayaran kartu telepon) atau pasca bayar (seperti pembayaran kartu kredit), diputuskan saat pendaftaran.
3.2.Keamanan
Kami membahas aspek keamanan dari protokol kami dengan mengindahkan serangan tipe I dan
tipe II yang dijelaskan dalam bagian 2.1.
Serangan tipe I (menggunakan-tanpa-bayar) dapat dikategorikan ke dalam duplikasi, pemalsuan, dan modifikasi tiket.
Ada dua jenis serangan duplikasi. Tipe pertama adalah pelanggan baik menggunakan atau
transfer tiket berkali-kali (mirip dengan pengeluaran ganda dalam sistem kas belanja elektronik).
Tipe kedua adalah ikut mendengarkan rahasia (eavesdropper), yang mendengarkan orang lain
memperoleh tiket, membuat salinan untuk dirinya sendiri. Dalam protokol kami, keduanya dicegah dengan memperbarui informasi publik pengguna (kunci publik atau counter) setelah
setiap penggunaan tiket.
Untuk mencegah serangan Tipe II (get-paid-without-serve/dibayar tanpa melayani), tanda tangan
SigP penyedia jasa digunakan ketika provider memforward tiket Ticket untuk TC untuk
pengisian tagihan (pembayaran kepada TC) dan membuat clearance (pembayaran ke layanan
operator). tanda tangan tersebut digunakan oleh TC untuk mengotentikasi penyedia layanan
(berdasarkan virtual ID nya). Setelah proses ini, baik Ticket dan SigP (Ticket) disimpan dalam
data center TC untuk suatu jangka waktu yang wajar. Jika angka pelanggan bahwa dia
dibebankan tanpa menerima layanan yang sesuai, dia bisa melaporkan ke TC. Setelah
memverifikasi tiket pelanggan dan penyedia layanan tanda tangan yang berkorespondensi, TC
meminta penyedia layanan untuk memberikan bukti. Jika laporan pelanggan adalah terbukti
benar, TC menghapus dari daftar operator layanan, laporan ke TA untuk melacak identitas
sesungguhnya dari provider, dan tuntutan ganti rugi. Setelah menerima laporan dari TC, TA
menyiarkan pesan untuk semua TC untuk menangguhkan atau mencabut hak istimewa dari
operator selular dalam layanan mobile.
3.3.Skalabilitas
Solusi Tradisional untuk mengimplementasikan mobilitas pengguna mengandalkan otentikasi
cross-domain dan perjanjian roaming. Seorang pelanggan, ketika mengunjungi sebuah domain
asing dan mengakses layanan di sana, harus otentikasi dirinya sendiri ke penyedia layanan asing
dengan bantuan agen domain asalnya. Ini mungkin melibatkan proses otentikasi melalui jarak
jauh, yang bisa memakan waktu dan biaya mahal. Selain itu, otentikasi cross-domain
membutuhkan seorang penyedia jasa asing untuk mempercayai agen domain asal. Dengan
berkembang pesatnya penyedia layanan, skema tersebut akan tidak lagi praktis.
Alih-alih menghubungi agen domain asal untuk layanan lintas domain, penyedia layanan dalam
protokol kami memverifikasi tiket. Tiket dihasilkan oleh nasabah sendiri, dengan kunci rahasia
sendiri. Akuisisi tiket tidak memerlukan bantuan dari agen domain utama atau protokol jarak
jauh. Perjanjian bisnis antara domain yang berbeda mungkin tidak diperlukan, meskipun, mereka
mungkin akan bermanfaat dalam memfasilitasi pembayaran antara TC dan penyedia layanan.
3.4.Efisiensi
Efisiensi sebuah protokol akses layanan mobile dapat dilihat dalam dua aspek. Salah satu aspek
adalah jumlah putaran untuk menyelesaikan transaksi. Dalam protokol kami, parameter ini
dirancang menjadi relatif kecil. Sebagai contoh, untuk menghasilkan tiket, banyak tiket berbasis
solusi (misalnya, [4] dan [29]) mewajibkan pelanggan untuk kontak dengan server agen tiket
atau pelanggan perawatan, yang pada gilirannya kontak dengan penyedia layanan (dan mungkin
otoritas sertifikat); proses akuisisi tiket mungkin memerlukan empat hingga enam putaran komunikasi. Sebagai perbandingan, dalam protokol kami, pelanggan dapat menghasilkan tiket
sendiri, tidak ada perlu kontak dengan pihak lain dalam proses ini. Untuk penggunaan tiket,
protokol kami hanya memerlukan satu putaran komunikasi di mana pelanggan mengirimkan
tiket ke penyedia layanan, sementara beberapa solusi lain yang membutuhkan putaran lebih
(misalnya, nilai Nonce diminta untuk mengirim bolak-balik antara pelanggan dan penyedia jasa
dalam [4]).
Aspek kedua adalah untuk memilih sebuah algoritma kriptografi yang efisien untuk
melaksanakan protokol generik. Kami telah merekomendasikan untuk menggunakan ECDSA
[11] dalam bagian 5,1 karena merupakan salah satu algoritma signature yang paling efisien
sistem 4G masa depan, dan interkoneksi dari banyak jaringan nirkabel yang berbeda-beda, telah
memfasilitasi pelanggan untuk mengakses layanan mobile dan aplikasi kapan saja dari mana
saja. Telah digarisbawahi bahwa yang sangat bersifat personal, konteks aware, lokasi yang
sensitif, aplikasi pada waktu kritis, yang dilakukan dengan cara yang sangat aman adalah layanan mobile paling menjanjikan. Layanan tersebut secara teknis dimungkinkan sebagai perangkat mobile modern seperti ponsel 3G dan PDA biasanya dilengkapi dengan fungsi lanjutan
(misalnya, browsing internet) dan kemampuan komputasi yang kuat (yang dapat digunakan
untuk melakukan operasi seperti encryptions kriptografi kunci publik).
Untuk menyediakan layanan mobile berkualitas tinggi di lingkungan nirkabel, satu kebutuhan
tidak hanya kenyamanan dan fleksibilitas, tetapi juga keamanan dan privasi pada desain
arsitektur dan protokol. Meskipun ada banyak usulan untuk mengamankan layanan mobile
(misalnya, [1,4,10,14,16,18,20,22,25-27,34-36]), kebanyakan mereka hanya memberikan bagian dari sifat yang diinginkan. Sebagai contoh, protokol yang diusulkan dalam [34-36] sangat rentan terhadap pemalsuan dan serangan modifikasi (lihat bagian 7.1 untuk rincian), sedangkan [10, 22] tidak memberikan anonimitas identitas untuk pelanggan. Selain itu, banyak solusi yang terbatas pada teknik spesifik atau jenis layanan tertentu. Sebagai contoh, keamanan modul diperkenalkan pada [10] adalah khusus untuk gateway WAP, dan protokol di [34-36] didasarkan pada algoritma kriptografi tertentu.
Dalam tulisan ini, kami mengusulkan sebuah tiket berbasis arsitektur serta protokol generic.
Untuk mengontrol akses ke layanan mobile. tiket adalah sepotong informasi yang memungkinkan pelanggan untuk mengakses jenis layanan tertentu., protokol kami memiliki
properti berikut. Pertama, merupakan solusi generik independen dari algoritma kriptografi dan
mode layanan. Kedua, aman terhadap berbagai serangan berbahaya pada layanan mobile. Ketiga, anonimitas memberikan identitas untuk pelanggan dan / atau penyedia layanan tergantung pada kebutuhan bisnis. Keempat, fleksibel dalam lingkungan yang dinamis di mana pelanggan dan / atau penyedia layanan cross multiply domain. Kami juga menunjukkan pilihan implementasi yang efisien dari protokol generik berdasarkan algoritma tanda tangan digital kurva eliptik.
The Ticket-based Architecture (Arsitektur berbasis Tiket)
Ada empat peran/pihak pada arsitektur yang kami ajukan, yaitu trusted authority (TA), trusted
credential (TC), customer (C) dan provider (P). Kita menggunakan nama user (U) ketika kita
tetapkan sebagai C atau P.
Dalam protokol ini, diasumsikan bahwa (1) TA benar-benar dipercaya oleh semua pihak lain; (2)
TC dipercaya untuk menjalankan proses pengisiian tagihan, membuat clearance, dan
memperbarui informasi publik dengan benar. (3) C dan P tidak memiliki kepercayaan satu sama
lain dan dan ingin menjadi anonymous terhadap entitas lain kecuali TA Pelanggan dan provider (penyedia layanan) perlu mendaftar ke TA sehingga bisa terlibat dalam layanan mobile. Pada proses registrasi, identitas sebenarnya dari semua peserta diverifikasi.
Pasangan informasi public dan rahasia kemudian dibangkitkan/dibuat untuk setiap entitas yang
terdaftar, bersama dengan identitas virtual yang akan digunakan dalam transaksi ke depan untuk alasan anonymous (jika entitas yang terlibat tidak peduli dengan anonimitas, makaidentitas virtual bisa berupa identitas sebenarnya).
Ketika seorang pelanggan bermaksud untuk mengakses layanan suatu provider (pengedia
layanan),pendahulu (the former) diperlukan untuk melewatkan tiket yang sesuai yang nantinya
oleh yang belakangan (the latter) dapat memeriksa informasi tentang layanan yang sedang
diminta. Tiket dibangkitkan sendiri oleh pelanggan dengan menggunakan kunci rahasia (secret
key) milik pelanggan itu sendiri.
Setelah menerima tiket, provider memeriksa validitas dan menyediakan layanan sesuai dengan
tiket. Tiket kemudian diteruskan ke TC untuk pengisian tagihan terhadap pelanggan
(pembayaran kepada TC) dan membuat clearance (pembayaran terhadap penyedia layanan).
Rincian prosedur tagihan berada di luar cakupan makalah ini, yang mana banyak protokol secure
electronic payment dapat digunakan. Terakhir, informasi rinci tentang tiket, tagihan-tagihan, dan clearance disimpan di pusat data (data center) milik TC. Informasi publik milik pelanggan dan provider seperti virtual ID, public key (yang terikat untuk identitas virtual), tipe layanan, dan waktu valid juga disimpan di pusat data. Untuk mencegah duplikasi dan pemalsuan tiket,
informasi public key milik pelanggan diperbarui melalui key update protocol setelah setiap
eksekusi penggunaan tiket. Akibatnya, skema kita tidak membutuhkan banyak kunci disimpan di sisi pelanggan, di mana penyimpanan terbatas dalam lingkungan mobile.
2.3 Protokol Umum untuk Kontrol Akses pada Layanan Mobile (Generic Protocol for
Controlling Access to Mobile Services)
Berikut ini definisi – definisi yang digunakan pada protokol umum ini, :
a. Fungsi hash.
Fungsi hash juga dikatakan fungsi satu arah yang digunakan dalam komponen
kriptofrafis seperti pseudo-random generation, digital signature dan otentikasi pesan.
Misal H(x) adalah fungsi hash. Secara komputasi susah untuk menemukan x dari y
sehingga H(x)= y, di mana x merupakan sebuah vektor. Secara umum, fungsi hash adalah
pemetaan satu arah dari bit-string dengan panjang sembarang {0, 1}* ke bit-string dengan
panjang tetap {0, 1}k, dan nilai image diasumsikan terdistribusi merata pada {0, 1}k.
b. Signature.
Sebuah skema signature terdiri dari algoritma berikut.
• (SK,PK) = Gen(1k): Key generation adalah probabilistic polynomial-time algorithm yang mengambil security parameter 1k sebagai input dan menghasilkan pasangan kunci public
dan kunci rahasia (SK,PK). • σ = Sig(SK,m): Signature signing adalah algoritma yang mengambil (SK,m) sebagai input dan menghasilkan signature σ pada pesan m.
• Ver(PK,σ) ?= 1: Signature verification adalah (probabilistic) polynomial-time algorithm
yang mengambil (PK,σ) sebagai input dan menghasilkan nilai 1 (True) untuk penerimaan
signature atau 0 (False) untuk penolakan signature
Generic Protocol
Protokol yang diusulkan dapat diimplementasikan berdasarkan suatu algoritma kunci publik
praktis, seperti RSA, ElGamal, dan ECC. Selain itu, protokol ini dapat dengan mudah
digabungkan dengan mode layanan yang berbeda yang masing-masing berkorespondensi dengan jenis tiket. Buttyán dan Hubaux mengklasifikasikan tiket dalam layanan mobile menjadi empat kategori, tergantung pada apakah tiket terikat kepada pelanggan dan penyedia layanan. Dalam solusi kami, baik pelanggan dan penyedia layanan dapat memilih untuk menjadi anonim,
sehingga memungkinkan untuk semua jenis tiket. Seorang pelanggan dapat menjual atau
memberikan tiket kepada pelanggan lain, atau menetapkan berbagai layanan dimana tiketnya
berlaku. Pelanggan dapat menggabungkan penggunaan beberapa kendala (misalnya, yang akan
menyediakan / menerima apa jenis layanan di mana kondisi) menjadi sebuah tiket (lebih
tepatnya, pesan m) sehingga menggagalkan penangkapan atau penyalahgunaan tiket. Di sisi lain,
kendala penggunaan dapat dipublikasikan dalam TC (bersama-sama dengan identitas pengguna
dan kunci publik), sebuah penyedia layanan dapat memeriksa tiket terhadap informasi tersebut
sehingga memudahkan kontrol akses yang bagus di layanan mobile.
Perhatikan bahwa protokol kita dapat dengan mudah diintegrasikan dengan teknik enkripsi
standar dan metode billing. Standar enkripsi dapat disediakan pada lapisan jaringan yang
mendasar sehingga semua komunikasi (antara TA, TC, pelanggan, dan penyedia layanan)
terenkripsi. Untuk proses billing, banyak protokol pembayaran elektronik yang aman seperti
pembayaran-mikro [25, 38] dapat diterapkan antara TC, pelanggan, dan penyedia. Sebuah
pembayaran dapat dibayar di muka (seperti pembayaran kartu telepon) atau pasca bayar (seperti pembayaran kartu kredit), diputuskan saat pendaftaran.
3.2.Keamanan
Kami membahas aspek keamanan dari protokol kami dengan mengindahkan serangan tipe I dan
tipe II yang dijelaskan dalam bagian 2.1.
Serangan tipe I (menggunakan-tanpa-bayar) dapat dikategorikan ke dalam duplikasi, pemalsuan, dan modifikasi tiket.
Ada dua jenis serangan duplikasi. Tipe pertama adalah pelanggan baik menggunakan atau
transfer tiket berkali-kali (mirip dengan pengeluaran ganda dalam sistem kas belanja elektronik).
Tipe kedua adalah ikut mendengarkan rahasia (eavesdropper), yang mendengarkan orang lain
memperoleh tiket, membuat salinan untuk dirinya sendiri. Dalam protokol kami, keduanya dicegah dengan memperbarui informasi publik pengguna (kunci publik atau counter) setelah
setiap penggunaan tiket.
Untuk mencegah serangan Tipe II (get-paid-without-serve/dibayar tanpa melayani), tanda tangan
SigP penyedia jasa digunakan ketika provider memforward tiket Ticket untuk TC untuk
pengisian tagihan (pembayaran kepada TC) dan membuat clearance (pembayaran ke layanan
operator). tanda tangan tersebut digunakan oleh TC untuk mengotentikasi penyedia layanan
(berdasarkan virtual ID nya). Setelah proses ini, baik Ticket dan SigP (Ticket) disimpan dalam
data center TC untuk suatu jangka waktu yang wajar. Jika angka pelanggan bahwa dia
dibebankan tanpa menerima layanan yang sesuai, dia bisa melaporkan ke TC. Setelah
memverifikasi tiket pelanggan dan penyedia layanan tanda tangan yang berkorespondensi, TC
meminta penyedia layanan untuk memberikan bukti. Jika laporan pelanggan adalah terbukti
benar, TC menghapus dari daftar operator layanan, laporan ke TA untuk melacak identitas
sesungguhnya dari provider, dan tuntutan ganti rugi. Setelah menerima laporan dari TC, TA
menyiarkan pesan untuk semua TC untuk menangguhkan atau mencabut hak istimewa dari
operator selular dalam layanan mobile.
3.3.Skalabilitas
Solusi Tradisional untuk mengimplementasikan mobilitas pengguna mengandalkan otentikasi
cross-domain dan perjanjian roaming. Seorang pelanggan, ketika mengunjungi sebuah domain
asing dan mengakses layanan di sana, harus otentikasi dirinya sendiri ke penyedia layanan asing
dengan bantuan agen domain asalnya. Ini mungkin melibatkan proses otentikasi melalui jarak
jauh, yang bisa memakan waktu dan biaya mahal. Selain itu, otentikasi cross-domain
membutuhkan seorang penyedia jasa asing untuk mempercayai agen domain asal. Dengan
berkembang pesatnya penyedia layanan, skema tersebut akan tidak lagi praktis.
Alih-alih menghubungi agen domain asal untuk layanan lintas domain, penyedia layanan dalam
protokol kami memverifikasi tiket. Tiket dihasilkan oleh nasabah sendiri, dengan kunci rahasia
sendiri. Akuisisi tiket tidak memerlukan bantuan dari agen domain utama atau protokol jarak
jauh. Perjanjian bisnis antara domain yang berbeda mungkin tidak diperlukan, meskipun, mereka
mungkin akan bermanfaat dalam memfasilitasi pembayaran antara TC dan penyedia layanan.
3.4.Efisiensi
Efisiensi sebuah protokol akses layanan mobile dapat dilihat dalam dua aspek. Salah satu aspek
adalah jumlah putaran untuk menyelesaikan transaksi. Dalam protokol kami, parameter ini
dirancang menjadi relatif kecil. Sebagai contoh, untuk menghasilkan tiket, banyak tiket berbasis
solusi (misalnya, [4] dan [29]) mewajibkan pelanggan untuk kontak dengan server agen tiket
atau pelanggan perawatan, yang pada gilirannya kontak dengan penyedia layanan (dan mungkin
otoritas sertifikat); proses akuisisi tiket mungkin memerlukan empat hingga enam putaran komunikasi. Sebagai perbandingan, dalam protokol kami, pelanggan dapat menghasilkan tiket
sendiri, tidak ada perlu kontak dengan pihak lain dalam proses ini. Untuk penggunaan tiket,
protokol kami hanya memerlukan satu putaran komunikasi di mana pelanggan mengirimkan
tiket ke penyedia layanan, sementara beberapa solusi lain yang membutuhkan putaran lebih
(misalnya, nilai Nonce diminta untuk mengirim bolak-balik antara pelanggan dan penyedia jasa
dalam [4]).
Aspek kedua adalah untuk memilih sebuah algoritma kriptografi yang efisien untuk
melaksanakan protokol generik. Kami telah merekomendasikan untuk menggunakan ECDSA
[11] dalam bagian 5,1 karena merupakan salah satu algoritma signature yang paling efisien
0 komentar:
Posting Komentar