AAOS SDV - Secure by Design

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

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

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

বর্তমান ট্রেন্ড অনুযায়ী, ইলেকট্রনিক কন্ট্রোল ইউনিট (ECU)-কে একটি চিপে একত্রিত করা হচ্ছে। এর ফলে একাধিক ডোমেন পাশাপাশি রান করার মাধ্যমে আইসোলেশন কমে যায়।

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

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

AAOS SDV Microdroid থেকে উন্নত হয়েছে, এটি হল গোপনীয়তা ভার্চুয়াল মেশিনের (pVM) জন্য অপ্টিমাইজ করা একটি মিনিমালিস্টিক Android ভার্সন। এই লিনিয়েজ 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 ডেমন এটিকে প্রাথমিক বুটের সময় "ব্যর্থ" হিসেবে চিহ্নিত করে। সিস্টেমটি সাথে সাথেই সিম্বলিক লিঙ্কগুলিকে /সিস্টেম পার্টিশনে অদল-বদল করে। এই অ্যাটমিক রিকভারি নিশ্চিত করে যে সিস্টেমটি ভাঙা অবস্থায় থাকবে না।

স্থিতিস্থাপকতা: মেমরি-সেফ ডেভেলপমেন্ট

যাচাই করা লোডিং সিস্টেমকে এক্সটার্নাল পরিবর্তন থেকে রক্ষা করে, কিন্তু প্ল্যাটফর্মের স্থিতিশীলতাও নির্ভর করে কীভাবে অন্তর্নিহিত কোড তৈরি করা হয়েছে তার উপর। 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 ওভারভিউ পৃষ্ঠায় উপলভ্য।