ভূমিকা

২০২১ সালের July-এ Nym, বিখ্যাত নিরাপত্তা বিশেষজ্ঞ Jean-Philippe Aumasson-এর দ্বারা একটি নিরাপত্তা নিরীক্ষা করায়। এর লক্ষ্য ছিল ক্রিপ্টোগ্রাফি, কোড নিরাপত্তা এবং প্রোটোকল নিরাপত্তার উপর মনোযোগ দিয়ে Nym কোডবেসের সম্ভাব্য দুর্বলতা ও ত্রুটিগুলো শনাক্ত করা। এই পর্যালোচনার লক্ষ্য ছিল সিস্টেমটির স্থাপত্য ও বাস্তবায়নের মূল দিকগুলো অন্তর্ভুক্ত করে এর অখণ্ডতা ও দৃঢ়তা নিশ্চিত করা। আপনি সম্পূর্ণ নিরীক্ষা প্রতিবেদনটি এখানে দেখতে পারেন।

নিরীক্ষার সারাংশ

নিরীক্ষাটি ২০২১ সালের গ্রীষ্মকালে অনুষ্ঠিত হয়েছিল। এই নিরীক্ষার আওতায় Nym প্রকল্পের একাধিক সংগ্রহস্থল অন্তর্ভুক্ত ছিল, যার মধ্যে রয়েছে:

• Nym-এর মূল রিপোজিটরি: nymtech/nym, যা মিক্সনোড, গেটওয়ে ও ভ্যালিডেটর সার্ভিসগুলো বাস্তবায়ন করে।
• Sphinx মিক্সনেট প্যাকেট ফরম্যাট: nymtech/sphinx, যা মিক্সনোড দ্বারা ব্যবহৃত হয়।
• Coconut থ্রেশহোল্ড ব্লাইন্ড সিগনেচার প্রোটোকল: nymtech/coconut, যা ক্রেডেনশিয়াল ইস্যু করার জন্য ব্যবহৃত হয়।

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

নিরীক্ষার প্রধান বিবেচ্য বিষয়সমূহ

নিরীক্ষাটি তিনটি প্রধান ক্ষেত্রের উপর আলোকপাত করেছিল: কোড নিরাপত্তা, ক্রিপ্টোগ্রাফি এবং প্রোটোকল ডিজাইন। নিরীক্ষকরা দুর্বলতা শনাক্ত করার জন্য Nym-এর কোডবেস পুঙ্খানুপুঙ্খভাবে পরীক্ষা করেছেন এবং অনিরাপদ কোডিং প্যাটার্ন ও ভুলভাবে সামলানো ত্রুটির মতো সাধারণ সমস্যাগুলো খুঁজেছেন। মেমোরি সুরক্ষা এবং ইন্টিজার ওভারফ্লোর মতো জটিল ত্রুটি এড়ানোর উপর বিশেষ মনোযোগ দেওয়া হয়েছিল।

ক্রিপ্টোগ্রাফিক পর্যালোচনাটিতে Nym(https://nym.com/trust-center/cryptography) দ্বারা ব্যবহৃত বিস্তৃত পরিসরের মূল আদিম উপাদানগুলো অন্তর্ভুক্ত ছিল, যেমন AES-128-CTR, BLAKE2b, ChaCha, Ed25519 এবং অন্যান্য। এর লক্ষ্য ছিল এই অ্যালগরিদমগুলোর যথাযথ বাস্তবায়ন নিশ্চিত করা এবং সাইড-চ্যানেল আক্রমণ, প্যারামিটারের অপব্যবহার ও র‍্যান্ডমনেস তৈরিতে ত্রুটির বিরুদ্ধে এগুলোর প্রতিরোধ ক্ষমতা যাচাই করা।

স্বতন্ত্র উপাদানগুলো পর্যালোচনা করার পাশাপাশি, নিরীক্ষাটি Nym-এর মূল কার্যকারিতা নির্ধারণকারী প্রোটোকলগুলোও খতিয়ে দেখেছে। গোপনীয়তা বা নিরাপত্তা বিঘ্নিত করতে পারে এমন কোনো দুর্বলতা শনাক্ত করার জন্য Sphinx প্যাকেট ফরম্যাট এবং Coconut থ্রেশহোল্ড ব্লাইন্ড সিগনেচার প্রোটোকল পরীক্ষা করা হয়েছিল। এই পর্যালোচনায় ব্যবহারকারীর পরিচয় গোপনীয়তার জন্য হুমকিস্বরূপ সম্ভাব্য তথ্য ফাঁসের পাশাপাশি ম্যাক ভেরিফিকেশন বাইপাস, ক্ষুদ্র উপদলীয় আক্রমণ এবং BLS12-381 অ্যারিথমেটিক ও জিরো-নলেজ প্রুফের মতো ক্রিপ্টোগ্রাফিক কার্যক্রমের ত্রুটির মতো দুর্বলতাগুলোর উপর আলোকপাত করা হয়েছে।

প্রাপ্ত ফলাফলের সংক্ষিপ্ত বিবরণ

নিরীক্ষা চলাকালীন নয়টি নিরাপত্তা ত্রুটি শনাক্ত করা হয়েছে। কোনোটিই গুরুতর হিসেবে রেট করা হয়নি, দুটিকে উচ্চ, একটিকে মাঝারি এবং ছয়টিকে নিম্ন হিসেবে রেট করা হয়েছে। এর পাশাপাশি, ১৭টি পর্যবেক্ষণ তুলে ধরা হয়েছে, যা Nym নেটওয়ার্ককে আরও শক্তিশালী করার জন্য বিভিন্ন পরামর্শ ও সুপারিশ প্রদান করে। নিম্নে, চিহ্নিত সকল নিরাপত্তা দুর্বলতা নিরসনে বাস্তবায়িত সমাধানগুলোর একটি সংক্ষিপ্ত বিবরণ দেওয়া হলো।

S-SPHX-01: কি-সমূহের যাচাইকরণের অনুপস্থিতি (নিম্ন)

প্রাইভেট এবং পাবলিক কি-সমূহের অপর্যাপ্ত যাচাইকরণের বিষয়ে nymtech/sphinx-এ যে ত্রুটিটি চিহ্নিত হয়েছিল, তা x25519 লাইব্রেরিতে স্থানান্তরের মাধ্যমে সমাধান করা হয়েছে; যা মূলত নিজস্ব ডিজাইনের ফলেই কি-সমূহের বৈধতা নিশ্চিত করে। x25519 ইমপ্লিমেন্টেশনটি নিশ্চিত করে যে প্রাইভেট কীগুলো সঠিকভাবে ক্ল্যাম্প করা হয়েছে, অর্থাৎ এগুলো স্বয়ংক্রিয়ভাবে স্কেলারের একটি বৈধ উপসেটের মধ্যে সীমাবদ্ধ থাকে, যা অবৈধ প্রাইভেট কী ব্যবহারের ঝুঁকি দূর করে। এছাড়াও, যদিও x25519 সরাসরি পাবলিক কী যাচাই করে না, এর Montgomery ladder বাস্তবায়ন সহজাতভাবেই কিছু অবৈধ কার্ভ পয়েন্ট ব্যবহার হওয়া থেকে বিরত রাখে। এর ফলে অসীম বিন্দু বা অন্যান্য ত্রুটিপূর্ণ পাবলিক কী পাওয়ার ঝুঁকি হ্রাস পায়। তাছাড়া, কী এক্সচেঞ্জ প্রক্রিয়াটি নিশ্চিত করে যে, প্রয়োজনে একটি সম্পূর্ণ শূন্য শেয়ার্ড সিক্রেট শনাক্ত ও বাতিল করা যায়। x25519 ব্যবহার করে আমরা কী ভ্যালিডেশনকে উল্লেখযোগ্যভাবে উন্নত করেছি, যার ফলে সিস্টেমে অবৈধ বা ভুল ফরম্যাটের কী ব্যবহৃত হওয়ার ঝুঁকি কমেছে। এর মাধ্যমে নিরীক্ষায় উত্থাপিত কী ভ্যালিডেশন সংক্রান্ত উদ্বেগগুলোর কার্যকরভাবে সমাধান করা হলো।

S-COCO-01: হ্যাশ-টু-স্কেলার বায়েসড ডিস্ট্রিবিউশন (নিম্ন)

BLS12-381 ফিল্ডে একটি স্কেলার নির্ণয় করার হ্যাশিং প্রক্রিয়ায় পূর্বে হ্যাশ ফাংশনের আউটপুটকে সরাসরি একটি স্কেলার ক্ষেত্রের উপাদানা ম্যাপ করা হতো। তবে, এই পদ্ধতিটি মডিউলার রিডাকশন অপারেশন (mod p)-এর কারণে পক্ষপাতিত্ব তৈরি করে, যার ফলে হ্যাশ আউটপুটটি ফিল্ডের প্রাইম মডিউলাসের সাথে পুরোপুরি সামঞ্জস্যপূর্ণ না হলে একটি অসম বন্টন হতে পারে। এই সমস্যাটির সমাধান করার জন্য, আমরা বিদ্যমান hash-to-scalar ফাংশনটিকে bls12_381 crate থেকে hash_to_field ফাংশন দিয়ে প্রতিস্থাপন করেছি। এই ফাংশনটি মানসম্মত হ্যাশ-টু-ফিল্ড স্পেসিফিকেশন অনুসরণ করে, যা হ্যাশ আউটপুট থেকে ফিল্ড উপাদানগুলোতে একটি অভিন্ন এবং নিরপেক্ষ ম্যাপিং নিশ্চিত করে। এছাড়াও, Coconut প্রোটোকলের প্রতিস্থাপক zk-Nym প্রোটোকলটিও তার হ্যাশিং অপারেশনের জন্য এই ফাংশনটির উপর নির্ভর করে, যা ক্রিপ্টোগ্রাফিক গণনায় সামঞ্জস্য ও নির্ভুলতা নিশ্চিত করে।

S-COCO-02: keygen-cli কি ফাইলের পারমিশন (নিম্ন)

নিরীক্ষকরা উল্লেখ করেছেন যে keygen-cli কী ফাইলগুলোর ডিফল্ট পারমিশন রয়েছে, কিন্তু উন্নততর নিরাপত্তার জন্য সেগুলোর পারমিশন আরও সীমাবদ্ধ হওয়া উচিত। এই সমস্যাটির জন্য কোনো পরিবর্তনের প্রয়োজন ছিল না, কারণ আমাদের Coconut বাস্তবায়নের শুধুমাত্র প্রাথমিক পর্যায়ে keygen-cli ব্যবহৃত হয়েছিল। এটি এখন আর মূল Nym রিপোজিটরির অংশ নয় এবং সক্রিয়ভাবে ব্যবহৃত হয় না। যেহেতু টুলটি অপ্রচলিত হয়ে গেছে, তাই এর ফাইল পারমিশন সংক্রান্ত আর কোনো পদক্ষেপের প্রয়োজন ছিল না।

-CRYP-01: স্ট্রিম সাইফার IV-এর সম্ভাব্য পুনঃব্যবহার (উচ্চ)

এই ত্রুটিটি এমন একটি ফাংশনের সাথে জড়িত যা একটি প্রারম্ভিক ভেক্টর (IV) ব্যবহার করে ডেটা এনক্রিপ্ট করে। যদি কোনো IV প্রদান করা না হয়, তাহলে ফাংশনটি ডিফল্টরূপে একটি শূন্য IV ব্যবহার করে, যার ফলে IV-এর পুনঃব্যবহার হতে পারে। নিবন্ধন পর্বে AES-GCM-SIV প্রোটোকল প্রবর্তনের মাধ্যমে এই সমস্যার সমাধান করা হয়েছে। ডাউনগ্রেড আক্রমণ প্রতিরোধের জন্য, আমরা ক্লায়েন্ট এবং গেটওয়ের মধ্যে যোগাযোগের ক্ষেত্রে লিগ্যাসি AES-128-CTR কী ব্যবহারের অপশনটি সরিয়ে ফেলেছি। যতক্ষণ ক্লায়েন্ট এবং গেটওয়ে উভয়ই আপডেট থাকবে, তারা সর্বদা একটি র‍্যান্ডম, অশূন্য IV তৈরি করবে।

S-PROT-01: ক্রেডেনশিয়ালগুলোর একাধিকবার খরচের সম্ভাবনা (উচ্চ)

নিরীক্ষকরা লক্ষ্য করেছেন যে Coconut-এর পর্যালোচিত সংস্করণটিতে একাধিকবার খরচ শনাক্তকরণ ব্যবস্থার অভাব ছিল, যার ফলে একাধিক গেটওয়ে একই সময়ে একটি ক্রেডেনশিয়ালকে ভুলভাবে অব্যবহৃত হিসেবে যাচাই করতে পারত। তবে, পরবর্তীতে Coconut ব্যান্ডউইথ কন্ট্রাক্টটি অন-চেইনে স্টেট সংরক্ষণের মাধ্যমে ক্রেডেনশিয়াল ব্যবহারের হিসাব রাখার জন্য আপডেট করা হয়, যা এই সমস্যাটির সমাধান করে। এর পাশাপাশি, Coconut-কে পরবর্তীতে zk-nyms প্রোটোকল দ্বারা প্রতিস্থাপন করা হয়েছে, যার মধ্যে বিল্ট-ইন একাধিকবার খরচ শনাক্তকরণ কার্যকারিতা অন্তর্ভুক্ত রয়েছে।

S-NYM-01: পরিচিত দুর্বলতাযুক্ত নির্ভরশীলতা (মাঝারি)

নিরীক্ষকরা শনাক্ত করেছেন যে Nym প্রকল্পের বেশ কয়েকটি উপাদান পরিচিত নিরাপত্তা দুর্বলতাযুক্ত নির্ভরতার পুরোনো সংস্করণের উপর নির্ভর করছিল। উদাহরণস্বরূপ, Sphinx রিপোজিটরি generic-array ক্রেটের একটি অসুরক্ষিত সংস্করণ ব্যবহার করত, Nym-এর কোর রিপোজিটরি একটি পুরোনো tokio-এর উপর নির্ভর করত, এবং Nym ক্লায়েন্টে পরিচিত নিরাপত্তা সমস্যাযুক্ত বেশ কয়েকটি ক্রেট ছিল, যেগুলোর মধ্যে কয়েকটি Nym-এর প্রেক্ষাপটে কাজে লাগানো সম্ভব বলে মনে হয়েছিল। নিরীক্ষকদের সুপারিশ অনুসরণ করে আমরা নিয়মিতভাবে নির্ভরশীলতাগুলো হালনাগাদ করেছি। আমরা এখন Dependabot-এর মাধ্যমে সক্রিয়ভাবে আমাদের ডিপেন্ডেন্সিগুলো পরিচালনা করি, যা আমাদের রিপোজিটরিগুলোতে থাকা পুরোনো বা ঝুঁকিপূর্ণ প্যাকেজগুলোকে ক্রমাগত পর্যবেক্ষণ করে এবং স্বয়ংক্রিয়ভাবে শনাক্ত করে। আমাদের রিপোজিটরিতে Dependabot-এর ক্রমাগত প্রয়োগকৃত সমাধানগুলো দেখুন।

S-NYM-02: ডিক্রিপশন ব্যর্থতা পরিচালনা করা হয়নি (নিম্ন)

কোডে চিহ্নিত সমস্যাটি nym/common/nymsphinx/acknowledgments/identifier.rs ফাইলের recover_identifier ফাংশনে ঘটে, যেখানে অবৈধ প্যারামিটারের মতো ডিক্রিপশন ব্যর্থতাগুলো সঠিকভাবে সামলানো হয় না। এর ফলে আতঙ্ক বা অন্যান্য নিরাপত্তাহীন অবস্থা দেখা দিতে পারে। nym/common/nymsphinx/src/receiver.rs-এর recover_plaintext ফাংশনটিতেও একই ধরনের সমস্যা বিদ্যমান। ডিক্রিপশন ত্রুটিগুলি পরিচালনা করতে ব্যর্থতার ফলে সিস্টেমটি সম্ভাব্যভাবে একটি অস্থিতিশীল বা অনিরাপদ অবস্থায় প্রবেশ করতে পারে। ফাংশনগুলো সতর্কতার সাথে পর্যালোচনা করার পর আমরা এই সিদ্ধান্তে পৌঁছেছি যে, recover_identifier-এ প্রদত্ত প্রথম উদাহরণটি কোনো সমস্যা নয়। ভুল প্যারামিটার প্রদান করা অসম্ভব, কারণ সবকিছু AckEncryptionAlgorithm (লিংক) দ্বারা প্যারামিটারাইজড, যার অর্থ হলো যেকোনো অবৈধ মান কম্পাইল করার সময়ই ধরা পড়ে যাবে। তারা যে দ্বিতীয় কেসটির কথা উল্লেখ করেছিল, recover_plaintext, সেটির আর অস্তিত্ব নেই। তবে, এর পরিবর্তে ব্যবহৃত recover_plaintext_from_regular_packet কোডটিতে তাত্ত্বিকভাবে ব্যর্থ হওয়ার একটি সম্ভাবনা ছিল, যদি আমরা এর কিছু প্যারামিটারকে অস্বাভাবিক মানে পরিবর্তন করতাম। আমরা যথাযথ ত্রুটি ব্যবস্থাপনা যোগ করে এর সমাধান করেছি, যাতে সিস্টেমটি বিশেষ প্রতিকূল পরিস্থিতিতেও স্থিতিশীল থাকে।

S-NYM-03: ফ্র্যাগমেন্ট আইডি তৈরিতে আতঙ্ক (নিম্ন)

নতুন ফ্র্যাগমেন্ট আইডি তৈরি করার জন্য ব্যবহৃত কোডটি দৈবচয়নের ভিত্তিতে একটি i32 মান নির্বাচন করে এবং তার নিশ্চিত মান গ্রহণ করে। তবে, দৈবচয়নের মাধ্যমে নির্বাচিত মানটি i32::MIN হলে এই পদ্ধতিটি আতঙ্কের কারণ হতে পারে, কারণ এর নিশ্চিত মানকে একটি i32-এর সীমার মধ্যে প্রকাশ করা যায় না। এর ফলে 2-complement এনকোডিংয়ের সীমাবদ্ধতার কারণে 'attempt to negate with overflow' ত্রুটি দেখা দেয়। আমরা একমত যে এই সমস্যাটির জন্য তীব্রতার মাত্রা অনেক কম নির্ধারণ করা হয়েছে, কারণ এই ধরনের ঘটনার সম্মুখীন হওয়ার সম্ভাবনা প্রায় ৪ বিলিয়নে ১। যাইহোক, আমরা নিরীক্ষার সুপারিশকৃত সমাধানটি বাস্তবায়ন করে এই সমস্যার সমাধান করেছি, যা সম্ভাব্য প্যানিক ও আকস্মিক ক্র্যাশ প্রতিরোধ করে—বিশেষ করে যখন লাখ লাখ ব্যবহারকারী হাজার হাজার ফ্র্যাগমেন্ট আইডি তৈরি করেন।

S-NYM-04: Mnemonic not zeroized (Low)

শনাক্তকৃত সমস্যাটিতে দেখা গেছে যে, nymd পরিষেবা সংযোগের জন্য ব্যবহৃত BIP39 নেমোনিকটি ব্যবহারের পর শূন্য করা হচ্ছিল না, যার ফলে নেমোনিকটির একাধিক অনুলিপি মেমরিতে থেকে যাচ্ছিল। এর ফলে তথ্য ফাঁসের ঝুঁকি বেড়ে যায়, কারণ সাধারণ ক্রিপ্টোগ্রাফিক কী-এর তুলনায় স্মৃতিসহায়ক কৌশলগুলো স্মৃতিতে আরও সহজে শনাক্ত করা যায়। এর মোকাবিলায় আমরা বেশ কিছু প্রশমনমূলক ব্যবস্থা গ্রহণ করেছি। Rust কম্পোনেন্টগুলোতে, আমরা zeroize ক্রেটটি ইন্টিগ্রেট করেছি, যাতে নেমোনিক ধারণকারী যেকোনো মেমোরি স্কোপের বাইরে যাওয়ার সাথে সাথেই নিরাপদে মুছে ফেলা হয়। যেহেতু জাভাস্ক্রিপ্ট একটি আবর্জনা-সংগ্রাহক ভাষা এবং মেমোরি বিনষ্টকরণের ওপর সরাসরি কোনো নিয়ন্ত্রণ প্রদান করে না, তাই জাভাস্ক্রিপ্ট রানটাইমে এই ঝুঁকির প্রভাব কমাতে আমরা একটি ভিন্ন পদ্ধতি গ্রহণ করেছি। বিশেষভাবে, আমরা সিস্টেমটিকে এমনভাবে পরিবর্তন করেছি যাতে মেমোনিকটি Rust স্তরে প্রেরণ করার সাথে সাথেই জাভাস্ক্রিপ্ট রানটাইম বন্ধ হয়ে যায়। এটি নিশ্চিত করে যে রানটাইম শাটডাউনের সময় জাভাস্ক্রিপ্ট মেমরির মধ্যে থাকা মেমোনিকটি সমস্ত দৃষ্টান্ত মুছে ফেলা হয়। মেমোনিকটি যত তাড়াতাড়ি সম্ভব Rust-এ স্থানান্তর করা হয়, যার ফলে জাভাস্ক্রিপ্টে এর ব্যবহার কমে যায়। Rust মধ্যে zeroize নিশ্চিত করে যে কোনো মেমোনিক-এর আর প্রয়োজন না থাকলে তার সমস্ত দৃষ্টান্ত নিরাপদে মুছে ফেলা হয়। এই পরিবর্তনগুলোর মাধ্যমে, আমরা মেমরিতে স্মারকটির উপস্থিতি উল্লেখযোগ্যভাবে হ্রাস করেছি, যা প্রকাশের ঝুঁকি কমায় এবং সংবেদনশীল তথ্যের নিরাপদ ব্যবস্থাপনা ও মুছে ফেলা নিশ্চিত করে।

শেষ কথা

এই নিরীক্ষা প্রক্রিয়া জুড়ে তাঁর দক্ষতা ও নিষ্ঠার জন্য আমরা JP Aummason-কে ধন্যবাদ জানাতে চাই। সেই সাথে, নিরীক্ষার পরিকল্পনা ও বাস্তবায়ন—উভয় পর্যায়েই তাদের দেখানো সহযোগিতা ও পেশাদারিত্বের আমরা উচ্চ প্রশংসা করি। নিরাপত্তার প্রতি আমাদের চলমান প্রতিশ্রুতি সর্বদা আমাদের শীর্ষ অগ্রাধিকার হিসেবে থাকবে। আমাদের ইকোসিস্টেমের সর্বোচ্চ মান বজায় রাখতে আমরা আগামীতেও নিরাপত্তা বিশেষজ্ঞদের সাথে এই ধরনের অংশীদারিত্ব অব্যাহত রাখার জন্য আশাবাদী।