Certificate Pinning: এটি কী, প্রক্রিয়া এবং ফিক্সেশনের পদ্ধতি

Certificate Pinning কী?

Certificate Pinning একটি নিরাপত্তা কৌশল যেখানে অ্যাপ্লিকেশন একটি বিশ্বস্ত সার্টিফিকেটের ফিঙ্গারপ্রিন্ট সংরক্ষণ করে এবং HTTPS সংযোগ স্থাপনের জন্য একমাত্র মানদণ্ড হিসাবে ব্যবহার করে। মানক TLS মডেলে, ক্লায়েন্ট যাচাই করে যে সার্ভারের সার্টিফিকেট একটি বিশ্বস্ত রুট CA দ্বারা স্বাক্ষরিত — সিস্টেমে পূর্ব-ইনস্টল করা শত শত সার্টিফিকেট কর্তৃপক্ষের যেকোনো একটি। Certificate Pinning এই শৃঙ্খলটিকে সরাসরি যাচাই দিয়ে প্রতিস্থাপন করে: সার্টিফিকেটটি সংরক্ষিত নমুনার সাথে মিলতে হবে বা প্রত্যাশিত পাবলিক কী ধারণ করতে হবে।

মানক মডেলের সমস্যাটি CA আপস ঘটনার পরে স্পষ্ট হয়েছিল — DigiNotar (2011), Comodo (2011), TrustCor (2022)। যদি কোনো CA আপনার ডোমেনের জন্য জাল সার্টিফিকেট ইস্যু করে, ব্রাউজার বা অ্যাপ্লিকেশন এটি বৈধ হিসাবে গ্রহণ করে। Certificate Pinning এই আক্রমণ প্রতিরোধ করে: এমনকি পুরোপুরি স্বাক্ষরিত জাল সার্টিফিকেটও প্রত্যাখ্যান করা হবে কারণ এর ফিঙ্গারপ্রিন্ট অ্যাপ্লিকেশনে পিন করা ফিঙ্গারপ্রিন্টের সাথে মেলে না।

pinning শব্দটি pin থেকে এসেছে — «পিন» বা «ফিক্সেটর»: ডেভেলপার একটি বিশ্বস্ত সার্টিফিকেট ফিক্স করে, এবং তা থেকে যেকোনো বিচ্যুতি সংযোগ ব্লক করে। Mitre CWE-295-এর গবেষণা অনুসারে, অনুপযুক্ত সার্টিফিকেট যাচাই মোবাইল অ্যাপ্লিকেশনের শীর্ষ 10টি সবচেয়ে বিপজ্জনক নিরাপত্তা ত্রুটির মধ্যে একটি, এবং Certificate Pinning এটি প্রতিরোধের একটি সরাসরি পদ্ধতি।

Certificate Pinning-এর ইতিহাস এবং বিবর্তন

মূলত, Certificate Pinning ব্রাউজারে HPKP (HTTP Public Key Pinning) প্রক্রিয়ার মাধ্যমে ব্যবহৃত হত, যা RFC 7469-এ মানকৃত। ডেভেলপার প্রত্যাশিত কীগুলির হ্যাশ সহ একটি HTTP Public-Key-Pins হেডার পাঠাত, এবং ব্রাউজার সেগুলি নির্দিষ্ট সময়ের জন্য সংরক্ষণ করত। তবে, HPKP বিপজ্জনক প্রমাণিত হয়েছিল: কনফিগারেশনে একটি একক ত্রুটি একটি সাইটকে মাসের জন্য ব্লক করতে পারত। 2018 সালে, Chrome HPKP-এর সমর্থন বন্ধ করে দেয়, এবং বর্তমান মান ক্লায়েন্ট-সাইড বাস্তবায়ন হয়ে ওঠে — একটি মোবাইল অ্যাপ্লিকেশন বা ব্রাউজার এক্সটেনশনের ভিতরে।

Certificate Pinning কীভাবে কাজ করে?

Certificate Pinning প্রক্রিয়ায় তিনটি মূল ধাপ অন্তর্ভুক্ত: ফিঙ্গারপ্রিন্ট গণনা, সংযোগ যাচাই এবং ত্রুটি পরিচালনা। প্রস্তুতির সময়, ডেভেলপার প্রোডাকশন সার্ভারের সার্টিফিকেট বা পাবলিক কী-এর SHA-256 হ্যাশ প্রাপ্ত করে। GDPR এবং PCI DSS-সম্মত অ্যাপ্লিকেশনের জন্য, শৃঙ্খলে মধ্যবর্তী CAs-এর ফিঙ্গারপ্রিন্টও ফিক্স করা প্রয়োজন।

প্রতিটি HTTPS অনুরোধের সাথে, অ্যাপ্লিকেশন TLS প্রমাণীকরণ কলব্যাক ইন্টারসেপ্ট করে, সার্ভারের সার্টিফিকেট বের করে এবং এর SHA-256 হ্যাশ গণনা করে। এই হ্যাশটি সংরক্ষিত বিশ্বস্ত ফিঙ্গারপ্রিন্ট তালিকার সাথে তুলনা করা হয়। যদি মিল পাওয়া যায় — সংযোগ চলতে থাকে। যদি না — অ্যাপ্লিকেশনটিকে সংযোগ বন্ধ করতে হবে এবং আক্রমণকারীর কাছে বাস্তবায়নের বিবরণ প্রকাশ না করে ত্রুটি রিপোর্ট করতে হবে।

fun validateCertificate(certificate: X509Certificate,
    expectedHash: String): Boolean {
    val digest = MessageDigest.getInstance("SHA-256")
    val hash = Base64.encodeToString(
        digest.digest(certificate.publicKey.getEncoded()),
        Base64.DEFAULT
    ).trim()
    return hash == expectedHash
}

ফাংশনটি সার্ভার থেকে X509Certificate অবজেক্ট এবং প্রত্যাশিত হ্যাশ গ্রহণ করে। এটি প্রথমে সার্টিফিকেটের পাবলিক কী বের করে, SHA-256 হ্যাশ গণনা করে এবং Base64-এ এনকোড করে। ফলাফল প্রত্যাশিত ফিঙ্গারপ্রিন্ট-এর সাথে তুলনা করা হয়। প্রোডাকশনে, রোটেশন সমর্থনের জন্য 2–3টি ফিঙ্গারপ্রিন্টের একটি অ্যারের বিরুদ্ধে যাচাই যোগ করা উচিত।

Certificate Pinning বনাম Public Key Pinning

pinning বাস্তবায়ন করার সময়, কোন ক্রিপ্টোগ্রাফিক অবজেক্ট ফিক্স করতে হবে তা নির্বাচন করতে হবে। Certificate Pinning নিজস্ব X.509 সার্টিফিকেটের সাথে আবদ্ধ — এর সিরিয়াল নম্বর, বৈধতা সময়কাল এবং সম্পূর্ণ শৃঙ্খল। Public Key Pinning সার্টিফিকেটের ভিতরে শুধুমাত্র পাবলিক কী ফিক্স করে, অন্যান্য ক্ষেত্র উপেক্ষা করে। এই পছন্দটি পরিচালন ব্যয়কে উল্লেখযোগ্যভাবে প্রভাবিত করে।

Public Key Pinning বেশিরভাগ প্রকল্পের জন্য পছন্দের বিকল্প। সার্টিফিকেট পুনরায় ইস্যু করার সময় সার্ভারের পাবলিক কী সাধারণত অপরিবর্তিত থাকে — কোম্পানি পুরানো কীটি নতুন সার্টিফিকেট দিয়ে স্বাক্ষর করে। এর মানে হল যে যদি কী জোড়া পরিবর্তন না হয় তবে সার্টিফিকেট পরিবর্তনের পরে অ্যাপ্লিকেশনটির আপডেটের প্রয়োজন হয় না। অন্যদিকে, Certificate Pinning সেই পরিস্থিতিতে সুপারিশ করা হয় যেখানে ডেভেলপার সার্ভার এবং ক্লায়েন্ট কোড উভয়ই সম্পূর্ণরূপে নিয়ন্ত্রণ করে, যেমন কঠোর আপডেট চক্র সহ এন্টারপ্রাইজ অ্যাপ্লিকেশনে।

Trust On First Use (TOFU)

TOFU একটি কৌশল যেখানে Certificate Pinning আগে থেকে কনফিগার করা হয় না, বরং সার্ভারে প্রথম সংযোগে সার্টিফিকেটটি মনে রাখে। এই পদ্ধতিটি অ্যাপ্লিকেশনের জন্য সুবিধাজনক যেগুলি আগে থেকে জানে না তারা কোন সার্ভারের সাথে সংযোগ করবে। নেতিবাচক দিক হল প্রাথমিক আক্রমণের প্রতি দুর্বলতা: যদি প্রথম সংযোগ ইন্টারসেপ্ট করা হয়, একটি জাল সার্টিফিকেট বিশ্বস্ত হিসাবে গৃহীত হবে। TOFU SSH সংযোগ এবং কিছু P2P প্রোটোকলে ব্যবহৃত হয়।

iOS এবং Android-এ বাস্তবায়ন

উভয় প্ল্যাটফর্মে, Certificate Pinning নেটওয়ার্ক স্ট্যাক স্তরে TLS সংযোগ ইন্টারসেপ্ট করে বাস্তবায়িত হয়। iOS-এ, URLSession ডেলিগেট বা Alamofire ServerTrustManager ব্যবহার করা হয়। Android-এ, পছন্দের পদ্ধতি হল OkHttp CertificatePinner, যা জনপ্রিয় HTTP ক্লায়েন্টগুলিতে নির্মিত এবং প্রতিটি ডোমেনের জন্য একাধিক ফিঙ্গারপ্রিন্ট কনফিগার করতে সমর্থন করে।

func validate(serverTrust: SecTrust,
    pinnedHash: String) -> Bool {
    guard let certificates = SecTrustCopyCertificateChain(serverTrust)
        as? [SecCertificate] else { return false }

    for certificate in certificates {
        let data = SecCertificateCopyData(certificate)
        var hash = Data(repeating: 0, count: Int(CC_SHA256_DIGEST_LENGTH))
        data.withUnsafeBytes {
            CC_SHA256($0.baseAddress,
                CC_LONG(data.count), &hash)
        }
        if hash.base64EncodedString() == pinnedHash {
            return true
        }
    }
    return false
}

Swift ফাংশনে, serverTrust থেকে সার্টিফিকেট চেইন বের করা হয়, প্রতিটি সার্টিফিকেটের জন্য SHA-256 হ্যাশ গণনা করা হয় এবং ফলাফল প্রত্যাশিতটির সাথে তুলনা করা হয়। চেইনের সমস্ত সার্টিফিকেটের মাধ্যমে পুনরাবৃত্তি মধ্যবর্তী CA স্তরে pinning বাস্তবায়নের অনুমতি দেয় — যদি একটি মধ্যবর্তী সার্টিফিকেট মেলে, সংযোগ গ্রহণ করা হয়। এটি লিফ সার্টিফিকেট রোটেশনের সময় নমনীয়তা প্রদান করে।

Android-এর জন্য কাস্টম TrustManager

যদি অ্যাপ্লিকেশন OkHttp ব্যবহার না করে, কাস্টম X509TrustManager-এর মাধ্যমে Certificate Pinning বাস্তবায়ন করা যেতে পারে। এই পদ্ধতিতে আরও কোড প্রয়োজন কিন্তু যাচাই প্রক্রিয়ার উপর সম্পূর্ণ নিয়ন্ত্রণ দেয়। TrustManager checkServerTrusted পদ্ধতি ওভাররাইড করে, যেখানে ডেভেলপার ম্যানুয়ালি সার্ভার সার্টিফিকেট যাচাই করে এবং সেগুলি বিশ্বাস করার সিদ্ধান্ত নেয়। এটি শুধুমাত্র নির্দিষ্ট পরিস্থিতিতে সুপারিশ করা হয় যেখানে OkHttp লাইব্রেরি উপলব্ধ নয়।

Certificate Pinning বাস্তবায়নে সাধারণ ভুল

সবচেয়ে সাধারণ ভুল হল backup pins-এর অনুপস্থিতি। ডেভেলপার একটি একক সার্টিফিকেট ফিঙ্গারপ্রিন্ট অন্তর্ভুক্ত করে, এবং যখন এর মেয়াদ উত্তীর্ণ হলে, ব্যবহারকারীরা ব্যাপকভাবে সংযোগ হারান। ন্যূনতম গ্রহণযোগ্য কনফিগারেশন হল দুটি ফিঙ্গারপ্রিন্ট: বর্তমান সার্টিফিকেট এবং একটি ব্যাকআপ। আদর্শভাবে তিনটি: বর্তমান, একটি ব্যাকআপ এবং ফলব্যাক হিসাবে রুট CA ফিঙ্গারপ্রিন্ট।

দ্বিতীয় ভুল হল কোডে প্লেইন টেক্সটে পিন সংরক্ষণ করা। APK বা IPA-তে অ্যাক্সেস থাকা আক্রমণকারী সহজেই ফিঙ্গারপ্রিন্ট বের করে প্রতিস্থাপন করতে পারে। হ্যাশ অস্পষ্টকরণ সুপারিশ করা হয়: স্ট্রিংকে অংশে বিভক্ত করুন, এনক্রিপ্টেড রিসোর্সে সংরক্ষণ করুন বা রানটাইমে গণনা করুন। Android-এর জন্য, স্ট্রিং কনস্ট্যান্ট অস্পষ্টকরণ সহ ProGuard কার্যকর।

তৃতীয় ভুল হল ডেভেলপমেন্ট সার্টিফিকেট স্তরে পিনিং করা। ডেভেলপমেন্ট এবং প্রোডাকশন সার্টিফিকেট সাধারণত ভিন্ন হয়, কিন্তু ডেভেলপাররা প্রায়ই রিলিজ বিল্ড করার সময় পিন পরিবর্তন করতে ভুলে যান। ফলাফল হল যে প্রোডাকশন অ্যাপ্লিকেশন সার্ভারের সাথে সংযোগ করতে পারে না। সমাধান হল BuildConfig বা ফ্লেভার-নির্দিষ্ট রিসোর্সের মাধ্যমে ডিবাগ এবং রিলিজের জন্য পৃথক পিন কনফিগারেশন।

• সার্টিফিকেট চেইন উপেক্ষা করা — মধ্যবর্তী CAs বিবেচনা না করে শুধুমাত্র লিফ সার্টিফিকেট যাচাই করা, যা রোটেশনের সময় সংযোগ ভঙ্গ করে
• হার্ডকোডেড তারিখ — সার্টিফিকেটের মেয়াদ উত্তীর্ণের তারিখ হার্ডকোডেড যা আপডেটের পরে পরিবর্তন হয় না
• কোনো মনিটরিং নেই — Certificate Pinning ত্রুটির উপর সতর্কতার অনুপস্থিতি, যার ফলে সমস্যাগুলি শুধুমাত্র ব্যবহারকারীদের কাছ থেকে আবিষ্কৃত হয়
• যাচাই ছাড়া TOFU — অতিরিক্ত যাচাই ছাড়া Trust On First Use ব্যবহার, যা প্রথম MITM আক্রমণকে জাল সার্টিফিকেট পিন করার অনুমতি দেয়