Sanket.Chat
নিরাপত্তা: সংকেতায়ন

সর্বত্র Signal Protocol-এর প্রান্ত থেকে প্রান্তে এনক্রিপশন ও AES-256

Tosh Defence-এর SANKET (Sanket.Chat) Signal-এর আনুষ্ঠানিক, স্বাধীনভাবে নিরীক্ষিত libsignal ব্যবহার করে Signal Protocol-এর মাধ্যমে প্রতিটি বার্তা, প্রতিক্রিয়া ও এনক্রিপ্ট করা সম্প্রচার প্রান্ত থেকে প্রান্তে এনক্রিপ্ট করে; এতে কী বিনিময়ের জন্য PQXDH এবং SPQR-সহ Double Ratchet ব্যবহৃত হয়। ফাইল, কলের ফ্রেম, কল পরিবহন, স্থানীয় সংরক্ষণ এবং ইনস্টলেশনে সমাপ্ত হওয়া প্রতিটি TLS সেশনে AES-256 ব্যবহৃত হয়; AES-128-এ ফিরে যাওয়ার ব্যবস্থা বা সামঞ্জস্যতা মোড নেই।

AES-256 ব্যবহার করতে হবে, নইলে কার্যক্রম হবে না - এটাই SANKET-এর প্রকৌশলনীতি, যা কার্যকরী সংকেতে বলবৎ করা হয়েছে। পরিকল্পিত পদ্ধতিতে ঠিকমতো এনক্রিপশন করা না গেলে সুরক্ষা দুর্বল করার পরিবর্তে কার্যক্রমটি প্রত্যাখ্যান করা হয়।

বার্তা: অপরিবর্তিত Signal Protocol

সব বার্তা এনক্রিপ্ট করতে Sanket iOS, Android, ডেস্কটপ ও সার্ভারে একই সংস্করণের Signal-এর আনুষ্ঠানিক libsignal লাইব্রেরি ব্যবহার করে। এতে Signal Protocol-এর নতুন করে তৈরি কোনো বাস্তবায়ন বা বার্তা এনক্রিপশনের বিকল্প অ্যালগরিদম নেই।

PQXDH দিয়ে অধিবেশন প্রতিষ্ঠিত হয়। এটি X3DH-এর পোস্ট-কোয়ান্টাম সম্প্রসারণ, যা X25519 কী-সম্মতি ও একটি Kyber কী-এনক্যাপসুলেশন একত্র করে। এরপর Double Ratchet দিয়ে বার্তাগুলো এনক্রিপ্ট করা হয়: প্রতিটি বার্তার কী থেকে একটি AES-256 কী, একটি HMAC-SHA256 কী ও একটি প্রারম্ভিক ভেক্টর তৈরি করা হয়; বার্তাটি AES-256 দিয়ে এনক্রিপ্ট ও HMAC-SHA256 দিয়ে প্রমাণীকৃত হয়; এবং ব্যবহারের পর কীটি মুছে ফেলা হয়। প্রতিটি অধিবেশনে পাশাপাশি Signal-এর স্পার্স পোস্ট-কোয়ান্টাম র‍্যাচেটও চলে।

নকশাগতভাবেই বিকল্প ব্যবস্থায় ফেরার সুযোগ নেই

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

অংশীদারি কি ছাড়া গ্রুপ

দলের বার্তা প্রত্যেক জোড়ার জন্য আলাদা সংকেতায়নের মাধ্যমে পাঠানো হয়: প্রেরকের ডিভাইস প্রতিটি সদস্যের প্রতিটি বিশ্বস্ত ডিভাইসের জন্য বার্তাটি আলাদাভাবে সংকেতায়িত করে, প্রতিটির নিজস্ব libsignal সেশনের মাধ্যমে। সদস্যপদ পরিবর্তন হলে সংকেতায়নের চাবি নতুন করে নির্ধারণের প্রয়োজন হয় না; অপসারিত সদস্যকে শুধু বার্তা পাঠানোর তালিকা থেকে বাদ দেওয়া হয়।

এনক্রিপ্ট করার আগে প্রেরক প্রতিটি প্রাপকের অ্যাকাউন্টের নিজস্ব কী দিয়ে স্বাক্ষরিত ডিভাইসের তালিকা যাচাই করেন এবং তালিকায় নেই এমন কোনো ডিভাইসে কিছু পাঠান না।

ফাইল ও কল

প্রতিটি ফাইলের জন্য এলোমেলোভাবে তৈরি একটি 256-বিট কী ব্যবহার করে ডিভাইসেই AES-256-GCM-এর মাধ্যমে সংযুক্ত ফাইলের বিষয়বস্তু, নাম ও ধরন এনক্রিপ্ট করা হয়; সেই কী libsignal বার্তার ভেতর দিয়ে পাঠানো হয়।

কণ্ঠস্বর ও ভিডিও দুই স্তরে সুরক্ষিত। প্রত্যেক অংশগ্রহণকারীর ফ্রেম প্রেরকপ্রতি পৃথক চাবি দিয়ে AES-256-GCM পদ্ধতিতে প্রান্ত থেকে প্রান্তে এনক্রিপ্ট করা হয়। চাবিটি প্রতি 200 মিলিসেকেন্ডে পরিবর্তিত হয়, ফলে প্রত্যেক প্রেরকের জন্য প্রতি সেকেন্ডে পাঁচটি নতুন ফ্রেম চাবি তৈরি হয়। কেউ যোগ দিলে বা চলে গেলে নতুন একটি দৈব চাবি তৈরি হয়। প্রতিটি যন্ত্র ও গণমাধ্যম সার্ভারের মধ্যে SRTP শুধু AEAD_AES_256_GCM গ্রহণ করে। গণমাধ্যম সার্ভার এনক্রিপ্ট করা ফ্রেম পাঠিয়ে দেয়, কিন্তু সেগুলির পাঠোদ্ধার করতে পারে না। এই নকশায় সার্ভারের দিকে কল রেকর্ড করার ব্যবস্থা নেই।

  • প্রতিটি ফাইলে AES-256-GCM
  • প্রতিটি প্রেরকের জন্য পৃথক কলের চাবি, সবার জন্য একই চাবি কখনো নয়
  • প্রতি প্রেরকের জন্য প্রতি সেকেন্ডে 5টি ফ্রেম কী
  • শুধুমাত্র SRTP AES-256-GCM

তথ্য পরিবহণ ও সংরক্ষণ

প্রতিটি ক্লায়েন্ট সংযোগে TLS_AES_256_GCM_SHA384-সহ TLS 1.3 ব্যবহার করা হয়; অথবা যে প্ল্যাটফর্মের নেটওয়ার্ক ব্যবস্থা তা প্রয়োজন করে, সেখানে ECDHE ও AES-256-GCM-সহ TLS 1.2 ব্যবহার করা হয়। AES-128, ChaCha20, CBC-পদ্ধতির অ্যালগরিদম সমষ্টি এবং স্থির RSA বাদ দেওয়া হয়েছে, আর সংকর কোয়ান্টাম-পরবর্তী গোষ্ঠী X25519MLKEM768 প্রথমে প্রস্তাব করা হয়। প্রতিটি অনুমোদিত যন্ত্র পারস্পরিক TLS-এর মাধ্যমে নিজস্ব ক্লায়েন্ট সনদ দিয়েও নিজের পরিচয় প্রমাণ করতে পারে।

ডিভাইসে স্থানীয় ডেটাবেসগুলো AES-256 দিয়ে এনক্রিপ্ট করা হয় এবং HMAC-SHA256 দিয়ে সেগুলোর প্রামাণিকতা যাচাই করা হয়। ফোনে প্রোটোকল সংরক্ষণাগার ও ডিভাইসের গোপন তথ্য সুরক্ষিত হার্ডওয়্যারের সমর্থনযুক্ত একটি কী দিয়ে এনক্রিপ্ট করা হয়, যা সিকিউর এনক্লেভ, স্ট্রংবক্স বা বিশ্বস্ত নির্বাহ পরিবেশে থাকে।

প্রযুক্তিগত প্রমাণ

Sanket-এর শ্বেতপত্রে বিস্তারিত পড়ুন

এই পৃষ্ঠার প্রতিটি বক্তব্য প্রকাশ্যে উপলব্ধ Sanket-এর প্রযুক্তিগত নিরাপত্তা ও স্থাপত্যসংক্রান্ত শ্বেতপত্রে বিস্তারিতভাবে তুলে ধরা হয়েছে। নিবন্ধন ছাড়াই এটি বিনা মূল্যে পড়া যায়।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

প্রায়শই জিজ্ঞাসিত প্রশ্ন

আমাদের দলকে প্রশ্ন করুন

SANKET কি Signal Protocol ব্যবহার করে?

হ্যাঁ। SANKET সব প্ল্যাটফর্মে Signal-এর আনুষ্ঠানিক libsignal লাইব্রেরি দিয়ে সব বার্তা এনক্রিপ্ট করে; এতে PQXDH কী সমঝোতা এবং SPQR-সহ Double Ratchet ব্যবহৃত হয়। এতে প্রোটোকলটির নতুন করে তৈরি কোনো বাস্তবায়ন নেই।

SANKET-এর বার্তায় কি AES-256 এনক্রিপশন আছে?

হ্যাঁ। বার্তার জন্য libsignal-এর মধ্যে HMAC-SHA256-সহ AES-256-CBC ব্যবহৃত হয়; ফাইল, কলের ফ্রেম, কল পরিবহন, স্থানীয় সংরক্ষণব্যবস্থা এবং TLS-এর জন্য ব্যবহৃত হয় AES-256-GCM। AES-128-এ ফিরে যাওয়ার কোনো ব্যবস্থা নেই।

ভয়েস ও ভিডিও কল কি প্রান্ত থেকে প্রান্ত পর্যন্ত এনক্রিপ্ট করা থাকে?

হ্যাঁ। প্রতিটি প্রেরকের চাবি libsignal-এর মাধ্যমে পৌঁছে দেওয়া হয়; সেই চাবি দিয়ে কলের ফ্রেমগুলো প্রান্ত থেকে প্রান্তে AES-256-GCM ব্যবহার করে এনক্রিপ্ট করা হয়। প্রতিটি প্রেরকের জন্য প্রতি সেকেন্ডে 5টি নতুন ফ্রেম চাবি থাকে, এমন SRTP-এর ভেতরে যা শুধু AES-256-GCM গ্রহণ করে।

প্রতিক্রিয়া ও একাধিক প্রাপকের উদ্দেশে পাঠানো বার্তা কি এনক্রিপ্ট করা হয়?

হ্যাঁ। প্রতিক্রিয়া ও এনক্রিপ্টেড সম্প্রচারও libsignal বার্তা; অন্য সব বার্তার মতো এগুলোও প্রান্ত থেকে প্রান্ত পর্যন্ত এনক্রিপ্টেড। সম্প্রচারের অগ্রাধিকার, সময়সীমা ও মেয়াদ শেষের তথ্যও এনক্রিপশনের আওতায় থাকে।

SANKET কি গোষ্ঠী বার্তার জন্য প্রেরক কী ব্যবহার করে?

না। SANKET প্রতিটি সদস্যের প্রতিটি বিশ্বস্ত ডিভাইসের জন্য নিজস্ব libsignal সেশনের মাধ্যমে গোষ্ঠীর বার্তা আলাদাভাবে এনক্রিপ্ট করে। তাই গোষ্ঠীর সবার জন্য অভিন্ন কোনো কী নেই।

SANKET কোন কোন TLS সংস্করণ গ্রহণ করে?

TLS 1.3 অগ্রাধিকার পায়, শুধু TLS_AES_256_GCM_SHA384 ব্যবহার করে। TLS 1.2 গ্রহণ করা হয় শুধু ECDHE ও AES-256-GCM থাকলে। TLS 1.2-এর নিচের কোনো সংস্করণ গ্রহণ করা হয় না, এবং সংকর কোয়ান্টাম-পরবর্তী চাবি বিনিময় পদ্ধতি X25519MLKEM768 প্রথমে প্রস্তাব করা হয়।

libsignal কি নিরীক্ষিত হয়েছে?

হ্যাঁ। SANKET, Signal-এর স্বতন্ত্রভাবে নিরীক্ষিত libsignal লাইব্রেরির ভিত্তিতে তৈরি, এবং PQXDH প্রোটোকলটির আনুষ্ঠানিক বিশ্লেষণ করা হয়েছে।

আমাদের প্রকৌশলীদের সঙ্গে Sanket-এর ক্রিপ্টোগ্রাফি পর্যালোচনা করুন

Tosh Defence নিরাপত্তা স্থপতি ও মূল্যায়ন কমিটিগুলোকে স্তরে স্তরে ক্রিপ্টোগ্রাফিক নকশা ব্যাখ্যা করে; তথ্য প্রকাশ না করার চুক্তির আওতায় শ্বেতপত্রের নিয়ন্ত্রিত সংস্করণ পাওয়া যায়।