AAOS SDV - Secure by Design

Google-এ আমরা বিশ্বাস করি যে আমাদের প্রোডাক্টগুলি ডিজাইন অনুযায়ী সুরক্ষিত হওয়া উচিত, সেই কারণেই আমরা আগে থেকে থাকা মার্কেট-প্রুভেন প্ল্যাটফর্মে, সফ্টওয়্যার ডিফাইনড ভেহিকেলের (AAOS SDV) জন্য Android Automotive অপারেটিং সিস্টেম তৈরি করেছি, যা কাটলফিশের মতো ভার্চুয়ালাইজেশন টেকনোলজি ব্যবহার করে। আমাদের রিলিজ সংক্রান্ত ঘোষণায় ফিচারগুলির উপর ফোকাস করা হলেও, এই ব্লগ পোস্টে কিছু নিরাপত্তা সংক্রান্ত ধারণা তুলে ধরা হয়েছে।

ফাউন্ডেশন: ডোমেন আইসোলেশন

কো-হোস্ট করা ইনস্ট্যান্স আলাদা করতে ভার্চুয়ালাইজেশন

ইলেকট্রনিক কন্ট্রোল ইউনিট (ECU) একটি চিপে একত্রিত করার বর্তমান প্রবণতা একাধিক ডোমেন পাশাপাশি চালানোর মাধ্যমে আইসোলেশন কমিয়ে দেয়।

AAOS SDV ইনস্ট্যান্স ইন্টার্নাল আইসোলেশন মেকানিজম প্রদান করলেও, লজিক্যাল ডোমেন স্বাধীনভাবে চালানোই বেশি পছন্দ করা হয়। যেমন, ক্লাস্টার ও ইনফোটেনমেন্ট সিস্টেমের আলাদা আলাদা প্রয়োজনীয়তা আছে। আমরা প্যারালাল প্রসেসে একাধিক ইনস্ট্যান্স চালানোর জন্য ভার্চুয়াল মেশিন ব্যবহার করি। এর ফলে শেয়ারিং যে এক্সপ্লিসিট থাকে এবং আইসোলেশন যে ডিফল্ট আচরণ হয় তা নিশ্চিত করা যায়।

ইনহেরিটেড Android নিরাপত্তা

AAOS SDV Microdroid থেকে তৈরি হয়েছে, এটি হল Android-এর একটি মিনিমালিস্টিক ভার্সন যা প্রাইভেসি ভার্চুয়াল মেশিনের (pVM) জন্য অপ্টিমাইজ করা হয়েছে। এই লিনেজ Android প্ল্যাটফর্ম ইঞ্জিনিয়ারদের আগে থেকেই জানা প্রতিষ্ঠিত নিরাপত্তা ফিচার প্রদান করে।

প্রসেস আইসোলেশন ও ডিফল্ট হিসেবে প্রত্যাখ্যান করা

AAOS SDV প্রতিটি অ্যাপ্লিকেশনের জন্য স্যান্ডবক্স সেট-আপ করতে Android-এর ব্যবহারকারীর আইডি (UID)-ভিত্তিক আইসোলেশন মডেল অনুসরণ করে। প্রতিটি পরিষেবা অ্যাক্সেস অধিকার, ডেটা ডিরেক্টরি ও অন্যান্য বিধিনিষেধ ম্যানেজ করার জন্য অনন্য UID সহ একটি ডেডিকেটেড প্রসেসে চলে। আমরা পোর্টেবল অপারেটিং সিস্টেম ইন্টারফেস (POSIX) ক্ষমতা ব্যবহার করে অপারেশন কঠোরভাবে সীমিত করি এবং "ডিফল্ট হিসেবে প্রত্যাখ্যান" ভঙ্গি প্রয়োগ করতে এটিকে নিরাপত্তা-উন্নত Linux (SELinux)-এর সাথে যুক্ত করি। এই পদ্ধতি প্রতিটি পরিষেবাকে একেবারে ন্যূনতম প্রয়োজনীয়তার মধ্যে সীমাবদ্ধ করে, যার অর্থ হল কনফিগারেশন না থাকলে অ্যাক্সেস ব্লক করা হয়, অতিরিক্ত অনুমতি সহ সিস্টেম তৈরি করা হয় না। আমরা এই একই স্ট্র্যাটেজি আমাদের যোগাযোগের অনুমতি সিস্টেমে প্রয়োগ করি, যা এই নিবন্ধে পরে ব্যাখ্যা করা হয়েছে।

প্রমাণিত দুর্বলতা ম্যানেজমেন্ট

AAOS SDV, নিরাপত্তা সংক্রান্ত সমস্যা শনাক্ত, ট্রায়াজ, সমাধান ও প্রকাশ করার জন্য Android-এর উন্নত নিরাপত্তা সংক্রান্ত উত্তর ও দুর্বলতা ম্যানেজমেন্ট পরিকাঠামোকে ইন্টিগ্রেট করে। এই লাইফসাইকেলে ক্রমাগত অটোমেটেড স্ক্যানিং, বার্ষিক ডিপ-ডাইভ পেনিট্রেশন টেস্টিং এবং Android নিরাপত্তা সংক্রান্ত দুর্বলতা রিপোর্টিং প্রসেসের মাধ্যমে পার্টনার-চালিত ইন্টেলিজেন্স অন্তর্ভুক্ত থাকে। নিরাপত্তা টিম শনাক্ত করা দুর্বলতাগুলি ট্রায়াজ করে, ঝুঁকির ভিত্তিতে গুরুত্বের রেটিং অ্যাসাইন করে এবং সম্পূর্ণ করার মাধ্যমে উপশম ট্র্যাক করে। আমরা মাসিক Android নিরাপত্তা বুলেটিনের মাধ্যমে তথ্য প্রকাশ ও রিলিজ সংক্রান্ত নীতি কোঅর্ডিনেট করি। এর সাথে, দীর্ঘমেয়াদী প্ল্যাটফর্মের স্থিতিশীলতা নিশ্চিত করতে কঠোর পর্যায়ক্রমিক নিরাপত্তা অডিট ও সামগ্রিক আর্কিটেকচার পর্যালোচনা করা হয়।

অখণ্ডতা: সুরক্ষিত সফ্টওয়্যার ডেলিভারি

প্রসেস আইসোলেশনের গ্যারান্টি দেওয়ার পাশাপাশি, একটি নিরাপদ প্ল্যাটফর্মকে অবশ্যই এক্সিকিউশনের আগে কোড ইন্টিগ্রিটি নিশ্চিত করতে হবে। আমরা নিম্নলিখিত উপায়ে সফ্টওয়্যার ডেলিভারি সুরক্ষিত করি:

যাচাই করা সফ্টওয়্যার ডেলিভারি

AAOS SDV দুটি ইনস্টলেশন পদ্ধতি প্রদান করে। প্রথমে, আমরা সরাসরি শুধু-পঠনযোগ্য সিস্টেম, প্রোডাক্ট বা ভেন্ডর পার্টিশনে সফ্টওয়্যার ইনস্টল করি, যা প্রতিটি বুটে স্বাক্ষর যাচাই করে। এটি বেসিক সিস্টেম কম্পোনেন্ট সুরক্ষিত করে।

দ্বিতীয়ত, আমরা পরিষেবার জন্য Android Pony EXpress (APEX) প্যাকেজ ব্যবহার করি। প্রতিটি APEX সফ্টওয়্যার এবং এর ডিপেন্ডেন্সি এনক্যাপসুলেট করে, প্যাকেজটিকে বাধ্যতামূলক স্বাক্ষর যাচাইকরণ সহ একটি পার্টিশন হিসাবে বিবেচনা করে। AAOS SDV-তে, APEX কোড সাইনিংকে একটি অবিচ্ছিন্ন, হার্ডওয়্যার-এনফোর্সড চুক্তি হিসেবে বিবেচনা করে। APEX চারটি মূল স্তম্ভের মাধ্যমে ক্ষতিকর কোড এক্সিকিউশন প্রশমিত করা নিশ্চিত করে: 

১. ইমিউটেবল স্টোরেজ

• মেকানিজম: Android কার্নেল apex_payload.img ফাইলকে সরাসরি একটি র স্টোরেজ ডিভাইস হিসেবে রিড-ওনলি লুপব্যাক ব্যবহার করে লুপ করে, এটিকে কঠোর MS_RDONLY ফ্ল্যাগ দিয়ে মাউন্ট করে।
• এটি কেন আরও নিরাপদ: এটি OS-এ কোনও রাইট পাথ দেখায় না কারণ ফাইলগুলি গাড়ির স্টোরেজে আনপ্যাক করা হয় না। এমনকি আক্রমণকারী রুট প্রিভিলেজ পেলেও, তিনি চলমান APEX কোড পরিবর্তন করতে পারবেন না কারণ ফাইল সিস্টেম লেয়ার সব রাইট কমান্ড বাতিল করে দেয়।

২. ক্রিপ্টোগ্রাফিক ইন্টিগ্রিটি

• মেকানিজম: ক্রিপ্টোগ্রাফিক সিগনেচার, সম্পূর্ণ ফাইল সিস্টেম ইমেজের মার্কেল ট্রি যাচাই করে।
• এটি কেন আরও সুরক্ষিত: কার্নেল প্রতি-ব্লক dm-verity ব্যবহার করে যাতে প্রতি ৪কেবি ডেটা ব্লকের জন্য অন-দ্য-ফ্লাই স্বাক্ষর যাচাই করা যায়। কোনও অ্যাটাকার ফ্ল্যাশ মেমরিতে কোনও র ব্লক পরিবর্তন করলে, কার্নেল হ্যাশ না মেলা শনাক্ত করে এবং সঙ্গে সঙ্গে এক্সিকিউশন বন্ধ করে দেয়।

৩. কঠোর আইসোলেশন

• মেকানিজম: এটি প্রসেস আইসোলেশন বিভাগে বর্ণিত প্রসেস আইসোলেশন নিয়ম প্রয়োগ করে স্যান্ডবক্স তৈরি করে, যেখানে APEX-কে /apex-এর অধীনে একটি ডেডিকেটেড পার্টিশন হিসেবে মাউন্ট করা হয়।
• এটি কেন আরও সুরক্ষিত: প্রতিটি পরিষেবা নিজস্ব ব্যবহারকারী ও ডেটা ডিরেক্টরি পায়, যার ফলে স্পষ্টভাবে শেয়ার না করা পর্যন্ত অ্যাক্সেস সীমিত থাকে। একটি ডেডিকেটেড পার্টিশন তৈরি করে, Android একটি ডেডিকেটেড লিঙ্কার নেমস্পেস প্রতিষ্ঠা করে, এটি নিশ্চিত করে যে শুধুমাত্র স্পষ্টভাবে প্রকাশ করা লাইব্রেরিগুলি নন-প্রিভিলেজড সিস্টেম ডেমন থেকে অ্যাক্সেসযোগ্য, এইভাবে অ্যাটাক সারফেস কমিয়ে দেয়।

৪. অ্যাটমিক রিকভারি

• মেকানিজম: APEX ডবল-বাফার্ড রোলব্যাক চালু করতে "অ্যাক্টিভ/ব্যাকআপ" ডিজাইন ব্যবহার করে। ফ্যাক্টরি-ফ্ল্যাশ করা APEX অপরিবর্তনীয় /system পার্টিশনে থাকে, অন্যদিকে আপডেটগুলি পরিবর্তনযোগ্য /data পার্টিশনে থাকে।
• এটি কেন আরও সুরক্ষিত: কোনও আপডেট ব্যর্থ হলে বা ক্ষতিকর বলে মনে হলে, apexd ডেমন এটিকে প্রাথমিক বুটের সময় "ব্যর্থ" হিসেবে চিহ্নিত করে। সিস্টেমটি অবিলম্বে সিম্বলিক লিঙ্কগুলিকে /system পার্টিশনে ফিরিয়ে আনে। এই অ্যাটমিক রিকভারি সিস্টেমকে খারাপ অবস্থায় থাকা থেকে রক্ষা করে।

রেজিলিয়েন্স: মেমরি-সেফ ডেভেলপমেন্ট

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

প্রাথমিক ভাষা হিসেবে Rust

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

ডিস্ট্রিবিউটেড ট্রাস্ট: নেটওয়ার্ক ও অ্যাক্সেস কন্ট্রোল

সফ্টওয়্যার-ডিফাইন্ড ভেহিকেলের জন্য বিচ্ছিন্ন ডোমেনের মধ্যে নিরাপদ ইন্টার‍্যাকশন প্রয়োজন। AAOS SDV মেশ প্রোভিশনিং আর্কিটেকচার, প্রতিটি কমিউনিকেশন এন্ডপয়েন্টের ভার্সন ও লেখককে ক্রিপ্টোগ্রাফিক পদ্ধতিতে যাচাই করে এই জটিলতার সমাধান করে।

ডিভাইস ও মেশ প্রভিশনিং

AAOS SDV Mesh প্রকৃত বাইনারি এক্সিকিউশন স্টেট-এর সাথে প্রতিটি কম্পোনেন্টের নেটওয়ার্ক আইডেন্টিটি গাণিতিকভাবে বাইন্ড করার মাধ্যমে যাচাইকরণ প্রতিষ্ঠা করে। এই মডেলটি হার্ডওয়্যার-রুটেড যাচাইকরণের মাধ্যমে ইমপ্লিসিট সফ্টওয়্যার ট্রাস্টকে প্রতিস্থাপন করে।

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

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

VM-এর মধ্যে যোগাযোগ সুরক্ষিত রাখতে DICE-ভিত্তিক TLS

বাস্তবে হোস্টের পরিচয় যাচাই করা

DICE (ডিভাইস আইডেন্টিফায়ার কম্পোজিশন ইঞ্জিন)-এর গোল্ডেন রুল: ফার্মওয়্যারে একটি কোডের লাইন পরিবর্তন করা হলে (এমনকি কোনও মাইনর আপডেট বা ক্ষতিকারক এক্সপ্লয়েট হলেও), প্রাপ্ত কম্পাউন্ড ডিভাইস আইডেন্টিফায়ার (CDI) সম্পূর্ণভাবে পরিবর্তিত হয়ে যায়, যার ফলে সম্পূর্ণ আলাদা অ্যালিয়াস কী তৈরি হয়।

DICE এবং TLS (ট্রান্সপোর্ট লেয়ার সিকিউরিটি) জিরো-ট্রাস্ট আর্কিটেকচারের মৌলিক চ্যালেঞ্জের সমাধান করতে একত্রিত হয়: কোনও মেশিনের সফ্টওয়্যার ইন্টিগ্রিটি যাচাই করার পাশাপাশি মেশিনটিকে যাচাই করা।

DICE-এর হার্ডওয়্যার-ব্যাকড শনাক্তকরণ এবং TLS-এর এনক্রিপ্ট করা হ্যান্ডশেকের কম্বিনেশন, রিসিভ করা মেশিনকে কলারের পরিচয় এবং তার সঠিক সফ্টওয়্যার স্টেট, দুটিই যাচাই করার অনুমতি দেয়।

প্রচলিত সার্টিফিকেট শুধুমাত্র কোনও সিক্রেট আছে কিনা তা প্রমাণ করে; এটি ফার্মওয়্যার টেম্পারিং শনাক্ত করতে পারে না। DICE পরিমাপ করা বুট লেয়ারিং-এর মাধ্যমে এটি সমাধান করে:

• অনন্য ডিভাইস সিক্রেট (UDS): ম্যানুফ্যাকচারিংয়ের সময় তৈরি হওয়া র‌্যান্ডম ক্রিপ্টোগ্রাফিক সিক্রেট। শুধুমাত্র ফার্স্ট-স্টেজ বুটলোডারই UDS অ্যাক্সেস করতে পারে; এটি অন্য সব সফ্টওয়্যার ও এক্সটার্নাল ইন্টারফেসের জন্য অ্যাক্সেসযোগ্য থাকে না।
• লেয়ার্ড পরিমাপ (কম্পাউন্ড ডিভাইস আইডেন্টিফায়ার): হার্ডওয়্যার ROM, পরবর্তী ফার্মওয়্যার লেয়ারের সঠিক কোড এবং কনফিগারেশন সহ UDS হ্যাশ করার মাধ্যমে চেইন শুরু করে। এর ফলে একটি CDI তৈরি হয়, যা পরবর্তী প্রতিটি লেয়ার বুট করার সাথে সাথে ক্রমিক চেইন তৈরি করে।

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

লেয়ার্ড অ্যাক্সেস কন্ট্রোল

অ্যাক্সেস মেকানিজমকে আপস না করেই ডায়নামিক গাড়ি আপডেট করার জন্য AAOS SDV একটি ডিফেন্স-ইন-ডেপথ স্ট্র্যাটেজি ব্যবহার করে। এই মডেলটি দুটি প্রাথমিক বিশ্বাসযোগ্য লেয়ারের উপর নির্ভর করে:

1. পরিষেবা-লেভেল অনুমতি: নির্দিষ্ট VM-এ কোনও পরিষেবা মেশ জুড়ে অ্যাক্সেস বা প্রকাশ করতে পারে এমন নির্দিষ্ট রিসোর্স নির্ধারণ করুন।
2. VM-লেভেল অনুমতি: নির্দিষ্ট VM-এ হোস্ট করা সব পরিষেবার জন্য ক্রস-VM কমিউনিকেশন সংক্রান্ত সীমা নির্ধারণ করুন।

এই মডেল OEM-কে আপডেট করার ক্ষমতার সাথে নিরাপত্তার ভারসাম্য বজায় রাখতে সাহায্য করে। কম সংবেদনশীল পরিষেবার ক্ষেত্রে, অনুমতিমূলক VM-লেভেল নীতি, সম্পূর্ণ VM রিডিপ্লয়মেন্টের পরিবর্তে হালকা APEX আপডেটের মাধ্যমে ইনস্টলেশন চালু করে।

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

সিদ্ধান্ত

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

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