با نگاهی به اطراف و توجه به فناوریهای موجود، میتوان ادعا کرد که ما اکنون در آینده زندگی میکنیم. بسیاری از کارها از سفارش غذا تا پیدا کردن شغل، بهراحتی و با کمک اینترنت انجام میشود. اما چرا هنوز نمیتوانیم از این فناوریها برای کارهایی مانند رأیگیری استفاده کنیم؟ رایان نورث، یک دانشمند علوم کامپیوتر، در این مطلب توضیح میدهد که چرا نباید هیچگاه در کارهای اینچنینی، به کامپیوترها اعتماد کرد.
رایان برای بررسی این چالش، ابتدا به توضیح چگونگی عملکرد برنامههای کامپیوتری میپردازد. همانطور که میدانیم، کامپیوترها زبان باینری یا صفر و یک دارند. بهعلاوه، برنامهنویسی به زبان باینری نیز بسیار دشوار است و تقریبا هیچکس، تمایلی به نوشتن با این زبان ندارد. حتی اگر موفق به نوشتن با این زبان بشوید، نتیجه، تنها تعدادی عدد خواهد بود. این اعداد برای همهی افراد (حتی خودتان پس از چند هفته)، مفاهیمی مبهم و غیرقابل درک دارند. به بیان دیگر، با نگاه کردن به این زبان، نمیتوان حدس زد که برنامهی شما چه کاری انجام میدهد.
دانشمندان علوم کامپیوتر، برای حل این چالش، مفهومی را با نام زبان ماشین ابداع کردند. عبارتهای این زبان، کدهای باینری را به کلمات و جملاتی تبدیل میکنند که تا حد امکان به زبان انسان نزدیک میشود. اگرچه این عبارات جدید هم نیاز به پیشرفت دارند، اما حداقل، حرکتی در مسیر مثبت محسوب میشوند. زبان ماشین، به سختافزار آن وابستگی دارد.
بههرحال، با این زبان ماشین هم نمیتواند چنین دستوری را بهصورت مستقیم به کامپیوتر داد: «۱۰ را با ۲۰ جمع کن و نتیجه را نشان بده». بهجای این دستور، باید به کامپیوتر بگوییم: «۱۰ را در متغیر اول ثبت کن. ۲۰ را در متغیر دوم ثبت کن. دو متغیر را به متغییر جمع کننده وارد کن. نتیجه را در متغیر سوم ثبت کن. متغیر سوم را چاپ کن.» پس از ارسال این دستور، زبان ماشین بهتعریفی ترجمه (کامپایل) شده و به صفر و یکهای قابل فهم برای کامپیوتر تبدیل میشود.
مشکلات و کمبودهای این زبان از همان ابتدا مشخص هستند. شما باید زبان ماشین سختافزار خود را بشناسید و زبان ماشین سختافزارها نیز با هم تفاوتهای عمده دارند. بهعلاوه، باید مراحل فرآیند را بهصورت تکتک اعلام کنید. البته، بههرحال این زبان بیشتر از رشتههای صفر و یک قابل فهم خواهد بود.
مرحلهی بعدی پیشرفت زبانهای برنامهنویسی، حذف وابستگی به سختافزار است. در نتیجهی این اقدام، کامپایلر هوشمندی ساخته میشود که زبان، صرفنظر از ماشین مقصد، دستورات را به آن ارسال میکند. کامپایلر، دستور را به زبان ماشین مقصد و سپس به کدهای باینری تبدیل میکند. در نهایت، باوجود اینکه زبانهای برنامهنویسی هرکدام روش خاص خود برای حل مسائل را دارند، هدف آنها یکی است. آسانتر کردن خواندن کدها برای انسانها و در نتیجه، آسانتر کردن اصلاح و بهبود کدها، هدف مشترک تمام زبانهای برنامهنویسی محسوب میشود. در نتیجهی همهی این پیشرفتها، امروز، زبانهای برنامه نویسی دستور انسانی روبرو را بهراحتی میفهمند: Print 10+20.
با نگاهی به روند گفتهشده در بالا، احتمالا متوجه شدهاید که چرا نباید به کامپیوترها اعتماد کرد: کامپایلر، مشکل اصلی است. درواقع، صرفنظر از اینکه شما چه عبارتهایی مینویسید، اعتماد نهایی به کامپایلر خواهد بود تا آن را به کدهای باینری تبدیل کند. درواقع اگر کسی قصد خرابکاری در سیستم را داشته باشد، تنها باید کامپایلر را تغییر دهد.
بهعنوان مثال اگر دستور Print بهنوعی تغییر کند که همیشه، عدد یک را به ورودی اضافه کند، برنامه بهدرستی کار نخواهد کرد. از آنجایی که شما برنامه را صحیح نوشتهاید، هیچگاه با نگاه کردن به کدهایتان متوجه این اشکال نخواهید شد.
البته مثال بالا بسیار ساده بوده و با چند بار اجرا کردن و متوقف شدن برنامه، قابل کشف است. اما اگر دستکاری در کامپایلر پیچیدهتر باشد، آنگاه خطر چندبرابر خواهد بود. فرض کنید یک مجرم، کامپایلر را بهنوعی تغییر دهد که هرجا عبارت Password دیده شد، رمز عبور مورد نظر خودش نیز معتبر شناخته شود.
نفوذ بالا، تعریف درب پشتی یا همان Back Door در نفوذهای کامپیوتری است. با این کار، سازندهی کامپایلر به هر برنامهی کامپیوتری که با محصولش نوشته شده، دسترسی خواهد داشت. درواقع شما میتوانید ورود به برنامه را بهسختی قفل و محدود کنید. اما فرد نفوذگر بهراحتی از دربی وارد میشود که هیچکس از آن اطلاعی ندارد.
قطعا مثال بالا چالش بزرگی محسوب میشود؛ اما برنامهنویسهای حرفهای پاسخی برای آن دارند. آنها میگویند کامپایلر نیز یک برنامهی کامپیوتری است و میتوان با نگاه کردن به کدهای آن، متوجه مقاصد خرابکارانه یا نفوذ شد. در مورد مثال بالا، تنها باید به دنبال کدی باشید که پسورد مورد نظر نفوذگر را تأیید میکند.
در اینجا چالش بعدی مطرح میشود. همانطور که فرض کردیم، کامپایلرها نیز برنامههای کامپیوتری هستند. پس آنها نیز یک بار کامپایل شدهاند. در نتیجه، برای نفوذ و سوء استفاده از آنها، تنها باید موارد زیر را انجام دهیم:
ابتدا کدی که پسورد مورد نظر ما را بهعنوان پسورد صحیح میپذیرد، وارد کامپایلر میکنیم. در این مرحله، یک درب پشتی برای هر برنامهای میسازیم که با این کامپایلر نوشته میشود. اما اگر فردی به کدهای کامپایلر نگاه کند، متوجه هدف ما میشود. پس به مرحلهی بعدی میرویم.
کد جدیدی را وارد کامپایلر میکنیم. این کد، هرگاه خود کامپایلر، کامپایل شود، متوجه روند شده و کد مرحلهی قبل (قبول کردن پسورد مورد نظر ما) را به آن اضافه میکند. اکنون، وقتی کامپایلر را کامپایل کنیم، یک نسخهی جدید از خودش ایجاد میکند. این نسخهی جدید، حاوی دستوراتی برای پذیرفتن پسورد مورد نظر ما است. در نهایت برای از بین بردن ردپای خود نیز، دستورات خرابکارانه را از ظاهر کامپایلر حذف میکنیم.
با روش بالا، هر بار که کامپایلر دوباره ساخته میشود، بهگونهای خود را بازسازی میکند که کد مخرب درب پشتی را داشته باشد. در نتیجه، وقتی کامپایلر، برنامههای دیگر را ترجمه میکند، کد مخرب اضافه میشود اما در کد منبع آن قابل مشاهده نخواهد بود.
تنها راه کشف این خرابکاری یا باگ، خواندن کدهای باینری است. کاری که از همان ابتدا دشوار به نظر میرسد و با پیچیدهتر شدن برنامهها، بهسمت غیرممکن شدن پیش میرود. برای درک این دشواری باید بدانید تمام آثار شکسپیر فضای ۶ مگابایت نیاز دارند و برنامهای مانند فایرفاکس، ۲۰۰ مگابایت فضا نیاز دارد. با مقایسهی این اعداد میفهمیم که هیچکس نمیتواند تمام کدهای آن برنامه را بخواند. بهعلاوه، کدها به زبانی قابل فهم برای ما نوشته نشدهاند!
موارد گفته شده در بالا، حقیقت جدیدی نیستند. کن تامسون خالق سیستمعامل یونیکس، در سال ۱۹۸۴ مقالهای تحت عنوان Reflexing on Trusting Trust نوشت و در پایان آن، به این نتیجه رسید:
نتیجه ساده است. شما نمیتوانید به کدی که خودتان بهطور کامل ننوشتهاید، اعتماد کنید. در نهایت، هیچ تأییدیهای شما را در برابر کد غیرقابل اعتماد، مصون نمیدارد.
منظور کن تامسون از عبارت «بهطور کامل نوشتن»، تنها خود برنامه نیست. هدف او، نوشتن کل مسیر برنامه تا مراحل نهایی کامپایلر است. افراد محدودی زمان، مهارت و پول لازم برای ساختن یک کامپیوتر و برنامههای آن از اساس را دارند. کمی توجه به این پیشبینی تامسون، نشان میدهد که اعتماد کردن به کامپیوترها، در هیچ کاری عاقلانه نیست.
باوجود تمامی این هشدارها، ما از کامپیوترها برای همهی کارهایمان استفاده میکنیم. بهراستی چرا ما در همهچیز به این ماشینهای کابوسوار اعتماد داریم؟
پاسخ سوال بالا، ساده است: کامپیوترها، سرگرمکننده و راحت هستند. بهعلاوه، آنها در موارد گوناگون، کاربر دارند. در کنار همهی این موارد، هک کامپایلر کار سادهای نخواهد بود. شما باید زمان و انگیزه بالایی برای هدف قراردادن یک فرد یا جامعه داشته باشید. در نهایت، برخی کارها نیاز به اعتماد کامل به کامپیوتر ندارند. بهعنوان مثال هیچکس برای فهمیدن نوع پیتزای شما، زحمت هک کردن کامپایلر اپلیکیشن تحویل غذا را متقبل نمیشود. اما دستکاری برخی کارها، مانند رأیگیری، ارزش زمان و هزینه را دارند.
رأیگیری پدیدهای است که نتایج هک کردن آن، تأثیرات بزرگی خواهد داشت. بهعلاوه، هدف قرار دادن این فرآیند، دشوار نیست (چون زمان و مکان مشخصی دارد). مهمتر از همه، انگیزهی کافی برای دستکاری در آن نیز همیشه وجود دارد. برای نفوذ به این مورد نیز میتوان به همان روش اضافه کردن پسورد معتبر جعلی، دستوری برای اضافه کردن رأی به فردی خاص را در کامپیوتر تزریق کرد.
بههرحال، رایان با توجه به استدلالهای بالا ادعا میکند که رأیگیری کامپیوتری و رأیگیری اینترنتی، هیچگاه امن نخواهد بود. او تنها روش امن کردن رأیگیری کامپیوتر را، ترکیب آن با رأیگیری سنتی و کاغذی میداند. با این روش، حتی با وجود نفوذ به کامپیوترهای رأیگیری، کاغذهای رأی برای تأیید را رد نفوذ وجود دارند.
رایان پس از انتشار این مقاله در سرویس مدیوم، بخشهایی را نیز در پاسخ به پرسشهای تکراری کاربران به آن اضافه میکند. او در این بخشها به توضیح برخی از ابهامات یا راهکارهای پیشنهادی کاربران برای حل چالش اعتماد میپردازد.
یکی از سوالها، در مورد ماهیت رأیگیری کامپیوتری است. تعریف او از این نوع رأیگیری، فرآیندی است که تماما در کامپیوترها انجام میشود. در این فرآیند، هیچ المان دیگر (مثلا کاغذی) وجود ندارد و کامپیوتر، بهعنوان ابزار تأیید آرا شناخته میشود. راهکار او، اضافه کردن مرحلهی چاپ یا اسکن کاغذ رأیگیری، برای تأیید نهایی آرا بیان میشود.
یکی از کاربران، در نظرات این پست به راهکارهایی همچون ارائهی کد اختصاصی برای رأیدهندگان، اسکنهای بیومتریکی یا پشتیبان گرفتن در اینترنت اشاره میکند. پاسخ رایان به این پیشنهاد، همان عدم اعتماد به کدها است. از نظر او، این فرآیندها نیز توسط کامپیوتر انجام میشود که بههیچوجه قابل اعتماد نخواهد بود.
راهکار دیگر در بخش کامنتها، بررسی کد کامپایلرها بیان میشود. رایان در پاسخ به این راهکار میگوید که کد مخرب کامپایلر، همانطور که قبلا گفته شد، توانایی تشخیص فرآیند بررسی را دارد و در این فرآیند، عملکرد مخرب خود را نشان نمیدهد. اگرچه ایدهی رایان در مورد این کامپایلر مخرب کمی تخیلی بهنظر میرسد، اما او خرابکاری شرکت فولکس واگن در سال ۲۰۱۵ را مثالی عینی معرفی میکند.
کامپیوترهای خودروهای این شرکت، فرآیند بررسی آلایندگی را تشخیص میدادند و در آن حالت، در وضعیت مصرف پایین کار میکردند. پس از پایان تست، روند آنها بهحالت عادی یا مصرف بالا، تغییر میکرد. اصلاح این خرابکاری، ۱۸.۳۲ میلیارد دلار بهعلاوهی ۲.۸ میلیارد دلار جریمه برای فولکس بههمراه داشت. بههرحال شرکت فولکس واگن نیز بهخاطر تصور سوددهی این روش و عدم شناسایی توسط کارشناسان، این کار را انجام داد. همان انگیزههایی که برای نفوذ به انتخابات هم کافی هستند.
رایان در پاسخ به پرسشی در مورد عدم اعتماد به کامپیوترها میگوید:
بله، بهصورت مطلق و ۱۰۰ درصد نباید به کامپیوترها اعتماد کرد. البته قطعا انجام چنین کاری ممکن نخواهد بود. از طرفی، همهی کارها نیاز به اعتماد کامل به کامپیوترها ندارند. تنها چند مورد خاص در این زمینه مانند رأیگیری هستند.
یکی از انتقادات به ایدههای رایان این بود که بههرحال ما امروز از کامپیوترها در اکثر جنبههای زندگی از کار تا بانکداری استفاده میکنیم و حتی همین مقالهی رایان نیز توسط او در کامپیوتر نوشته شده است. با این وجود، چگونه میتوان بدون اعتماد به کامپیوتر زندگی کرد. در پاسخ به این انتقاد هم، بحث اعتماد ۱۰۰ درصد مطرح میشود. ما به بانکداری اینترنتی اعتماد داریم چون بانک میتواند (و تعهد میدهد که) خسارات احتمالی را پوشش دهد. اما در مورد اتفاقاتی همچون خرابکاری در رأیگیری، عواقب عموما جبرانناپذیر هستند.
عدم اعتماد رایان به کامپیوترها بهحدی پیش میرود که پیشنهاد استفاده از بلاکچین برای جبران خطرات گفتهشده را نیز رد میکند. او معتقد است این فناوری نیز قابل دستکاری بوده و هیچگاه ۱۰۰ درصد قابل اعتماد نیست.
در اینجا باید به این نکته اشاره کنیم که نویسندهی این مقاله، تنها قصد تفسیر صحبتهای کن تامسون را دارد. او خود را دانشمند عالِم کامپیوتر نمیداند و تنها، صحبتهای تامسون در مورد عدم اعتماد به کدها و کامپایلرها را با مثالی توضیح میدهد. البته رایان راهکاری نیز برای این مشکل ارائه میدهد و آن، کامپایل کردن کدها در دو کامپایلر متفاوت است. به بیان سادهتر برنامهنویس برای اطمینان از عدم خرابکاری در کامپایلر یک بار هم باید کد خود را در کامپایلر معتبر و تأییدشدهای اجرا کند. در اینجا باز هم این سوال مطرح میشود که آیا آن کامپایلر معتبر و تأییدشده قابل اعتماد خواهد بود؟
نویسندهی مقاله در پایان به این نکته اشاره میکند که هشدارهای او، علاوه بر مثال شرکت فولکس واگن، در پروژههای بزرگ دیگر نیز عینیت پیدا کردهاند. او مثالهایی از نفوذ به سیستمهای هستهای و موشکهای فضایی همچون ویروس استاکس نت بیان میکند که نتیجهی همان اعتماد ۱۰۰ درصدی بودهاند.
البته قطعا در رأیگیریهای کاغذی نیز احتمال سوءاستفاده و خرابکاری وجود دارد؛ اما این قدام بهخاطر ماهیت فیزیکی این رأیها، نیازمند تلاش بیشتر و صرف هزینهی بالاتر خواهد بود. بهعلاوه، کامپیوترها و کدهای آنها همیشه پیچیده هستند و حتی یک اشتباه کوچک در کدنویسی یا کامپایل کردن، نتایج را بهکلی تغییر خواهد داد. بههرحال شاید بتوان ادعا کرد که دنیای کامپیوتر، هنوز برای مقاصد بسیار مهم مانند رأیگیری، امن نیست.
منبع : زومیت