মোবাইল অ্যাপে এনক্রিপশন — মৌলিক বিষয়, অ্যালগরিদম এবং কার্যনীতি

মোবাইল অ্যাপ্লিকেশনে এনক্রিপশন কী?

এনক্রিপশন মোবাইল অ্যাপ্লিকেশনের প্রসঙ্গে হল ডিভাইসে সঞ্চিত ডেটা (data at rest) এবং নেটওয়ার্কে প্রেরিত ডেটা (data in transit) সুরক্ষিত করতে ক্রিপ্টোগ্রাফিক অ্যালগরিদমের প্রয়োগ। ডিভাইস স্তরে, স্থানীয় স্টোরেজ এনক্রিপ্ট করা হয়: ফাইল, ডেটাবেস, SharedPreferences এবং ক্যাশে। নেটওয়ার্ক স্তরে, অ্যাপ এবং সার্ভারের মধ্যে ট্র্যাফিক TLS/HTTPS প্রোটোকলের মাধ্যমে এনক্রিপ্ট করা হয়। চূড়ান্ত লক্ষ্য হল নিশ্চিত করা যে ডিভাইসে শারীরিক অ্যাক্সেস বা ট্র্যাফিক ইন্টারসেপশন সত্ত্বেও, একজন আক্রমণকারী ক্রিপ্টোগ্রাফিক কী ছাড়া সুরক্ষিত ডেটা পড়তে পারবে না।

মোবাইল অ্যাপ্লিকেশনে এনক্রিপশন কেন প্রয়োজন

মোবাইল ডিভাইসগুলি ডেটা হারানোর জন্য বিশেষভাবে ঝুঁকিপূর্ণ: ফোন সহজেই হারানো, চুরি হওয়া বা ম্যালওয়্যার দ্বারা সংক্রমিত হতে পারে। Ponemon Institute (2023) অনুসারে, ডেটা লঙ্ঘনের শিকার 42% কোম্পানি মোবাইল ডিভাইসকে ঘটনার কারণ হিসেবে চিহ্নিত করে। এনক্রিপশন ছাড়া, একজন আক্রমণকারী USB-এর মাধ্যমে ডিভাইসের সাথে সংযোগ স্থাপন করতে পারে, SQLite ডেটাবেস বের করতে পারে এবং সমস্ত সঞ্চিত ডেটা পড়তে পারে। এনক্রিপশন এই সমস্যার সমাধান করে: ডেটাবেস বের করা হলেও, এর বিষয়বস্তু এনক্রিপ্টেড থাকে। অতিরিক্তভাবে, মার্কিন যুক্তরাষ্ট্র এবং ইইউতে আইন (GDPR, CCPA) রয়েছে যা ব্যক্তিগত ডেটার এনক্রিপশন প্রয়োজন করে এবং লঙ্ঘনের জন্য বার্ষিক আয়ের 4% পর্যন্ত জরিমানা আরোপ করে। ব্যবহারকারীর ডেটা নিয়ে কাজ করা যেকোনো মোবাইল অ্যাপ্লিকেশনের জন্য এনক্রিপশনের ব্যবহার শুধুমাত্র প্রযুক্তিগত নয়, আইনগত প্রয়োজনীয়তাও বটে।

প্রতিসম এবং অপ্রতিসম এনক্রিপশন

সমস্ত এনক্রিপশন অ্যালগরিদম দুটি প্রধান প্রকারে বিভক্ত: প্রতিসম (এনক্রিপশন এবং ডিক্রিপশনের জন্য একটি কী) এবং অপ্রতিসম (এক জোড়া কী — পাবলিক এবং প্রাইভেট)। প্রকারের পছন্দ ব্যবহারের পরিস্থিতির উপর নির্ভর করে: স্থানীয় ডেটা এনক্রিপ্ট করতে প্রায়শই প্রতিসম অ্যালগরিদম ব্যবহার করা হয় তাদের গতির কারণে, এবং কী বিনিময় এবং প্রমাণীকরণের জন্য অপ্রতিসম ব্যবহার করা হয়।

ব্যবহারিক ক্ষেত্রে, মোবাইল অ্যাপ্লিকেশনে হাইব্রিড এনক্রিপশন ব্যবহার করা হয়: একটি অপ্রতিসম অ্যালগরিদম (যেমন ECDH) দিয়ে পক্ষগুলি সেশন কী বিনিময় করে, এবং পরবর্তী সমস্ত ডেটা একটি প্রতিসম অ্যালগরিদম (AES বা ChaCha20) দিয়ে এনক্রিপ্ট করা হয়। এই পদ্ধতি প্রতিসম এনক্রিপশনের গতি এবং অপ্রতিসম কী বিনিময়ের সুরক্ষাকে একত্রিত করে। এই পদ্ধতি TLS 1.3, Signal Protocol এবং Apple iMessage-এর ভিত্তি।

প্রধান এনক্রিপশন অ্যালগরিদম

আধুনিক মোবাইল ডেভেলপমেন্ট বেশ কয়েকটি প্রমিত এনক্রিপশন অ্যালগরিদম ব্যবহার করে, প্রতিটি নির্দিষ্ট কাজের জন্য ডিজাইন করা হয়েছে এবং এর নিজস্ব প্রয়োগের ক্ষেত্র রয়েছে।

• AES (Advanced Encryption Standard) — 2001 সালে NIST দ্বারা প্রত্যয়িত একটি প্রতিসম ব্লক সাইফার। 128, 192 বা 256 বিটের কী ব্যবহার করে। প্রস্তাবিত মোড হল GCM (Galois/Counter Mode) যা প্রমাণিত এনক্রিপশন সরবরাহ করে। AES-256 Android Keystore, iOS Keychain এবং সমস্ত আধুনিক TLS প্রোটোকলে ব্যবহৃত হয়।
• ChaCha20-Poly1305 — Daniel Bernstein দ্বারা বিকশিত একটি প্রতিসম স্ট্রিম সাইফার। AES-256-এর সমান সুরক্ষা প্রদান করে কিন্তু হার্ডওয়্যার AES ত্বরণ ছাড়া ডিভাইসে (সাধারণত বাজেট Android স্মার্টফোন) দ্রুত কাজ করে। ChaCha20 TLS 1.3-এ AES-GCM-এর বিকল্প হিসাবে ব্যবহৃত হয় এবং Signal Protocol-এ প্রাথমিক সাইফার।
• RSA (Rivest-Shamir-Adleman) — কী এনক্রিপশন এবং ডিজিটাল স্বাক্ষরের জন্য ব্যবহৃত একটি অপ্রতিসম অ্যালগরিদম। ন্যূনতম প্রস্তাবিত কী আকার 2048 বিট। RSA ECDH-এর চেয়ে ধীর, তাই আধুনিক মোবাইল অ্যাপ্লিকেশনে এটি উপবৃত্তাকার বক্ররেখা ক্রিপ্টোগ্রাফি (ECC) দ্বারা প্রতিস্থাপিত হচ্ছে।
• ECDH (Elliptic Curve Diffie-Hellman) — উপবৃত্তাকার বক্ররেখার উপর ভিত্তি করে একটি অপ্রতিসম কী বিনিময় প্রোটোকল। Perfect Forward Secrecy সরবরাহ করে এবং TLS 1.3-এ ডিফল্টরূপে ব্যবহৃত হয়। Curve25519 (X25519) বক্ররেখা মোবাইল অ্যাপ্লিকেশনে সবচেয়ে সাধারণ।

এনক্রিপশন কীভাবে ব্যবহারকারীর ডেটা সুরক্ষিত করে

এনক্রিপশন তিনটি মূল পরিস্থিতিতে ডেটা সুরক্ষিত করে: ডিভাইস হারানো (ডিস্ক এবং অ্যাপ কন্টেইনার এনক্রিপশন), ট্র্যাফিক ইন্টারসেপশন (TLS/HTTPS নেটওয়ার্ক প্রোটোকল) এবং সার্ভার থেকে ফাঁস (এন্ড-টু-এন্ড এনক্রিপশন)। প্রতিটি পরিস্থিতির নিজস্ব পদ্ধতি এবং সরঞ্জাম প্রয়োজন।

ডেটা অ্যাট রেস্ট এবং ডেটা ইন ট্রানজিট

ডেটা অ্যাট রেস্ট — ডিভাইসের ডেটা — Android Keystore এবং iOS Keychain-এর মাধ্যমে এনক্রিপ্ট করা হয়। Android 7.0 থেকে শুরু করে, ফাইল-ভিত্তিক এনক্রিপশন (File-Based Encryption) ব্যবহার করা হয়, এবং অ্যাপগুলি AndroidX Security লাইব্রেরি থেকে EncryptedSharedPreferences এবং EncryptedFile-এর মাধ্যমে তাদের ডেটা অতিরিক্তভাবে এনক্রিপ্ট করতে পারে। iOS-এ, সমস্ত অ্যাপ ডিফল্টরূপে Data Protection API-এর সাথে কাজ করে, যা ডিভাইস পাসকোডের সাথে আবদ্ধ একটি কী দিয়ে ফাইল সিস্টেম স্তরে ফাইল এনক্রিপ্ট করে। ডেটা ইন ট্রানজিট-এর জন্য, বাধ্যতামূলক Certificate Pinning-সহ TLS 1.2/1.3 ব্যবহার করা হয়।

এন্ড-টু-এন্ড এনক্রিপশন

এন্ড-টু-এন্ড এনক্রিপশন (E2E) — ডেটা সুরক্ষার সর্বোচ্চ স্তর, যেখানে বার্তাটি প্রেরকের ডিভাইসে এনক্রিপ্ট করা হয় এবং কেবল প্রাপকের ডিভাইসে ডিক্রিপ্ট করা হয়। স্টোরেজ এবং ট্রান্সমিশন সার্ভারের বিষয়বস্তুতে অ্যাক্সেস নেই — এটি কেবল এনক্রিপ্টেড ব্লবগুলি পরিচালনা করে। মোবাইল অ্যাপ্লিকেশনের জন্য সবচেয়ে পরিচিত E2E বাস্তবায়ন হল Signal Protocol, যা প্রাথমিক কী বিনিময়ের জন্য X3DH (Extended Triple Diffie-Hellman)-এর সাথে Double Ratchet Algorithm ব্যবহার করে। Signal Protocol Perfect Forward Secrecy এবং future secrecy সরবরাহ করে: একটি কী-এর সাথে আপোস করলে পূর্ববর্তী বা পরবর্তী বার্তাগুলি প্রকাশ পায় না। Carnegie Mellon University (2023)-এর একটি গবেষণা অনুসারে, মেসেজিং অ্যাপে E2E এনক্রিপশন শুধুমাত্র TLS এনক্রিপশনের তুলনায় যোগাযোগ ফাঁসের ঝুঁকি 99.7% হ্রাস করে। GDPR এবং HIPAA-র প্রয়োজনীয়তা অনুসারে Health & Fitness এবং Finance বিভাগের অ্যাপ্লিকেশনের জন্য E2E বাধ্যতামূলক। নিজস্ব প্রকল্পে E2E বাস্তবায়নের জন্য, Signal Protocol লাইব্রেরি (Java/Swift) বা Olm (Matrix protocol) ভিত্তিক একটি লাইব্রেরি ব্যবহার করার সুপারিশ করা হয়। E2E সমাধান নির্বাচন করার সময়, প্ল্যাটফর্ম সামঞ্জস্যতা মূল্যায়ন করুন: Signal Protocol-এর অ্যাসিঙ্ক্রোনাস প্রেরণ এবং ক্লায়েন্টে কী সঞ্চয়ের সমর্থন প্রয়োজন, যা মাল্টি-ডিভাইস পরিস্থিতি জটিল করে তোলে — এই ধরনের ক্ষেত্রে, Matrix Protocol তার কক্ষ মডেলের সাথে একটি ভাল পছন্দ হতে পারে।

val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .build()

val encryptedFile = EncryptedFile.Builder(
    context,
    File(context.filesDir, "secret.dat"),
    masterKey,
    EncryptedFile.FileEncryptionScheme.AES256_GCM_HKDF_4KB
).build()

encryptedFile.openFileOutput(applicationContext).use { outputStream ->
    outputStream.write("Sensitive user data".toByteArray(Charsets.UTF_8))
}