Public Key Cryptography နှင့် Internet ပေါ်တွင် လျို့ဝှက်စွာ ဆက်သွယ်ခြင်း နည်းနာများ (Part 3)

(Part 1 & 2 ကို အရင်ဖတ်ပြီးမှ ဒါကိုဖတ်ပါ)

အခြေခံလေးတွေ သိပြီဆိုတော့ ကျွန်တော်တို့ တကယ့်လက်တွေ့ internet သိုမဟုတ် web မှာ ကျနော်တို့ ဆက်သွယ်တဲ့ အဆင့်လေးတွေကို ကြည့်ကြပါမယ်။

ကျနော်တို့ browser သုံးသုံး facebook app လိုမျိုး ဖုန်းထဲက app တွေပဲ သုံးသုံး စစချင်းမှာ ကျတော်တို့ လိုတဲ့ data ကိုရဖို့ ကျနော်တို့ဘက်ကစပြီး request လုပ်ရမှာဖြစ်ပါတယ်။

ဆိုပါစို့ ကျနော်တို့က google.com ဆိုတာကို လိုချင်တယ်ဆိုပါစို့။ URL bar မှာရိုက်ထည့်လိုက်ရင် browser က google.com ဆိုတဲ့ webpage ရှိရာ google ရဲ့ server တွေဆီကို request သွားလုပ်မှာပါ။ (ကြားထဲမှာ DNS လိုမျိုးအဆင့်တွေ ရှိပေမယ့် သာမန်စာဖတ်သူတို့ ရှုပ်သွားပြီး တိုက်ရိုက်မသက်ဆိုင်တာကြောင့် နောက်မှ ဖော်ပြပါ့မယ်)

• 

ဒါဆို လက်ရှိ client (Browser တို့ App တို့ အင်တာနက်သုံးတဲ့ program မှန်သမျှကို client လို့ပဲ ကျနော် ခြုံငုံသုံးလိုက်ပါ့မယ်) က “ကျွန်တော့်ကို google.com ရဲ့ main page ကိုပေးပါ” ဆိုပြီး google ရဲ့ server တွေကို သွား request လုပ်ပါတယ်။

ဒါကို Server က ချက်ချင်းပြန်မပေးပါဘူး။ ချက်ချင်းပြန်ပေးရင် ဘာမှ encryption မရှိဘာမရှိ plain data ကိုပေးရမလိုဖြစ်နေလို့ပါ။

ဟိုးအရင်တချိန်ကတော့ ဒီလိုပဲ plain data နဲ့ ဆက်သွယ်ခဲ့ဘူးပါတယ်။ HTTP ခေတ်ကပေါ့ ။ လက်ရှိသုံးနေကြတာ HTTPS စနစ်ပါ ‘S’ ပါပါတယ်။ အခုပြောမှာက လက်ရှိသုံးနေကြတဲ့ HTTPS စနစ်ပါပဲ။

HTTP စနစ်မှာတုန်းကတော့ plain text တွေနဲ့ပဲ ပို့ခဲ့ကြပေမဲ့ အခု HTTPS မှာ client က request စလုပ်ရင် server ကဘာလုပ်လဲဆိုတော့ သူ့ရဲ့ public key လေးကို ပြန်ပေးပါတယ်။

Server ပို့လိုက်တဲ့ public key က client ဆီကို ရောက်လာတဲ့ အချိန်မှာ client က session key ၂ ခုကို generate လုပ်ထားပါတယ်။ session key ဆိုတာက symmetric key ပါပဲ။ ဒီ key နဲ့ encrypt လုပ်ထားရင် ဒီ key နဲ့ပဲ decrypt လုပ်လို့ရတဲ့ သဘောပေါ့။

• 

ကိုယ်အိမ်က သော့ကိုပဲ မြင်ကြည့်ပါပေါ့။ ဒါမျိုး ၂ ချောင်း client က generate လုပ်လိုက်ပါတယ်။

အဲ့ထဲက တစ်ချောင်းကို client က server ရဲ့ public key ကိုသုံး encrypt လုပ်ပြီး server ကိုပြန်ပို့ပေးလိုက်ပါတယ်။ Server ဆီရောက်တဲ့အချိန်မှာ server ကသူ့ရဲ့ private key ကိုသုံး decrypt လုပ်ပြီး session key ကိုရရှိမှာဖြစ်ပါတယ်။

အဲ့တာဆိုရင် client နဲ့ server ၂ ဦးသာသိတဲ့ session key တစ်ချောင်းစီ တစ်ဖက်စီမှာ ရှိနေပြီဖြစ်လို့ ပို့သမျှ data ကို ဒီ session key နဲ့ပဲ encrypt လုပ် တစ်ဖက်ကလည်း ဒီ key နဲ့ပဲ decrypt လုပ်ပြီး secure connection တစ်ခုရပြီလို့ဆိုနိုင်ပါတယ်။

အရှေ့က ပို့စ်တွေသေချာဖတ်ခဲ့သူတွေဆိုရင်တော့ ဒီနေရာမှာ ဘာမှားနေလဲ မေးခွန်းထုတ်နေကြပါပြီ။ ဟုတ်ပါတယ်။

Server က client ဆီကို public key ပြန်ပို့လိုက်တဲ့ အခြေအနေကိုကြည့်ပါ။ ဆိုပါစို့ ဒီနေရာမှာ server မဟုတ်တဲ့ တခြား ဘေးလူတစ်ယောက်က ဖြတ်ပြီး သူ့ရဲ့ public key ကို server ယောင်ဆောင်ပြီး client ပေးပို့လာနိုင်ပါတယ်။

အဲ့တာဆို client ကလဲ ယုံပြီး သူ့ session key ကို encrypt လုပ်ချပြီး ပြန်ပို့လိုက်တဲ့ အခါမှာ attacker မှာကျတော်တို့ ရဲ့ session key ရသွားပြီဖြစ်လို့ ကျတော်တို့ ပို့သမျှ data ဟာ server ဆီမရောက်ဘဲ သူ့ဆီပဲရောက်နေတော့မှာပါ။ (ဒါမျိုးကို Man in the middle attack လို့ခေါ်ပါတယ်၊ ကြားက ဖြတ်ခုတ်တဲ့လူပေါ့)

• 

အဲ့လို false identity နဲ့ man-in-the-middle attack တွေကို အတိုင်းအတာတစ်ခုအထိ ဖြေရှင်းဖို့ ယနေ့မှာ digital certificate တွေကို အသုံးပြုကြပါတယ်။ဆက်လက်ဖော်ပြပါ့မယ်။

Kevin

အသိအမြင်၊ အတွေးအခေါ် အသစ်တစ်ခုခုရသွားလို့ လှူဒါန်းလိုပါက Science Nuts (Facebook Page) ကို ဆက်သွယ်လှူဒါန်းနိုင်ပါတယ်။
လှူသမျှငွေအကုန်လုံးကို လိုအပ်တဲ့နေရာတွေမှာ ပြန်လည်လှူဒါန်းပေးသွားမှာပါ။