کتاب Zhiqun Chen (به روز شد)

سلام دوستان. با توجه به این که خرید این کتاب برای ایرانی ها به خاطر تحریم ساده نیست بنده داخل آدرس زیر کتاب رو آپلود کردم. دوستانی که دلشون میخواد قواعد اخلاقی رو رعایت کنند میتونند داخل گروه شماره کارت بنده رو بگیرند و هر مبلغی رو که مقدور هست براشون بدن که من به حساب دوستم خارج کشور واریز کنم و ایشون به حساب نویسنده ی کتاب واریز کنند. با وجود این که کتاب قدیمی هست ولی توصیه ی شدید میشه که بخونیدش. برای برنامه نویس های کارت فوق العاده س. 

لینک دانلود :

http://www.uschovna.cz/en/zasilka/LIKNTM5ITALKF8G7-MT7/GNW8IS29EJ

نرم افزار Gemalto Developer Suite (به روز شد)

لینک جدید و موقت نرم افزار Gemalto Developer Suite برای دوستانی که نیاز دارند روی برنامه نویسی سیم-کارت کار کنند :

http://www.uschovna.cz/en/zasilka/LI8MJRSXA5LJ6B67-UIT/Y6B79X23AR

گروه جاواکارت

بنام خدا

سلام.

به پیشنهاد یکی از دوستان، گروهی در زمینه ی جاواکارت و سیمکارت تشکیل دادیم که بتونیم با هم دانشمون، ابزارهامون و مستنداتی که داریم رو به اشتراک بذاریم. اگه دوست داشتید Join بشید. خوشحال می شیم.

https://telegram.me/joinchat/DvaxTkChELO1E_UF3XDjbA

آخرین بدافزار پوششی اندروید از طریق فیشینگِ اسمسی در اروپا توزیع می‌شود

مقدمه

در آوریل 2016، هنگام بررسیِ یک کمپین فیشینگِ اسمسی به نام RuMMS که هدف‌هایی از اروپا با سیستم عامل اندروید را هدف قرار می‌داد، متوجه سه کمپینِ فیشینگِ اسمسیِ دیگر شدیم که بنا به گزارش‌ها در دانمارک(فوریه ۲۰۱۶)، در ایتالیا(فوریه ۲۰۱۶) و در ایتالیا و دانمارک(آوریل ۲۰۱۶) پخش می‌شدند.

برخلاف کمپین RuMMS، این سه کمپین در اروپا از تکنیک‌های view overlay(همان تکنیک‌هایی که در بدافزار SlemBunk استفاده شده بودند و توصیف کردیم) استفاده کردند تا ورودی‌هایی مشابه با برنامه‌های گوشی برای اطلاعات ورود به نمایش بگذارند، و در ادامه کاربرانی که در جریان نبودند را گول بزنند تا اطلاعات بانکی خود را در اختیارشان قرار دهند.

شکل۱ پروسه‌ی این‌که چطور این بدافزارهای پوششی توسط فیشینگِ اسمسی پخش می‌شدند و کاربران اندروید را آلوده می‌کردند را نشان می‌دهد.

شکل۱. نمای کلی

عاملان تهدید معمولاً ابتدا سرورهای دستور و کنترل(C2) و سایت‌های میزبانیِ بدافزار را پیکربندی می‌کنند، سپس بدافزارها را بر روی سایت‌های میزبانی قرار می‌دهند و لینکی که به بدافزار هدایت می‌کند را از طریق اسمس برای قربانی می‌فرستند. پس از نصب‌شدن روی دستگاه، بدافزار یک پروسه را برای مانیتور کردن این‌که کدام برنامه در حال اجرا روی صفحه‌ی کاربر(foreground) است، راه‌اندازی می‌کند. وقتی کاربر یک برنامه‌ی آشنا را روی صفحه اجرا می‌کند که بدافزار برای هدف‌قرار دادنِ آن برنامه طراحی شده است(مثلاً اپلیکیشن بانک)، بدافزار یک view برای فیشینگ در روی آن برنامه به صورت overlay(پوششی) به نمایش در می‌آورد. کاربری که در جریان این حمله نیست، با فرض این‌که از برنامه‌ی معتبری استفاده می‌کند، ورودی‌های مورد نیاز(اطلاعات کارت بانکی) را وارد می‌کند؛ که این اطلاعات به سرور C2 که توسط گردانندگان این ویروس کنترل می‌شود ارسال می‌شوند.

در بررسی‌های موشکافانه روی بدافزارهایی که از طریق فیشینگ اسمسی پخش می‌شوند، ما به تازگی مشاهده کرده‌ایم که این نوع حملات با وجود اطلاع‌رسانی محققان امنیتی کماکان در حال اجرا هستند. علاوه بر این تحقیقات نظام‌مند ما یافته‌هایی که در عین جالب بودن، نگران‌کننده هستند را پیدا کرده است:

• ·         از فوریه‌ی 2016 تا ژوئن 2016، ما 55 برنامه‌ی مخرب که در سری‌های فیشینگ اسمسی در اروپا به کار رفته بودند را یافته‌ایم. همه‌ی نمونه‌بدافزارها از تکنیک viewی پوششیِ مشابهی برای سرقت اطلاعات بانکی استفاده می‌کنند و همه‌ی آن‌ها از پروتکل روش اشتراک‌گذاریِ C2 مشابهی بهره می‌برند. در کنار سه کمپینی که به صورت عمومی در دانمارک و ایتالیا مشخص شدند، ما بدافزار مشابهی را در آلمان در مارس 2016 و در اتریش در آوریل 2016 تا مِی 2016 مشاهده کردیم. در ژوئن 2016، ما هنوز نمونه‌های جدیدی در حال ظهور و استفاده شدن در دانمارک؛ و چند کشور اروپایی می‌بینیم که کاربران را هدف قرار داده‌اند.
• ·         کاربرد کلیدی این نمونه‌ها همه یکسان است؛ با این وجود، طی زمان متوجه شدیم که نمونه‌ها در چند شاخه‌ی مختلف در حال تحول و توسعه هستند. برای مثال، کمپین‌های اخیر، برنامه‌های شناخته شده تری را نسبت به کمپین‌های اولیه هدف قرار داده‌اند، به عنوان مثال با تمرکزِ خاصی روی برنامه‌های پیام‌رسان، در مقابل برنامه‌های بانکی. همین‌طور، اپلیکیشن‌های مخربی که در کمپین‌های اخیر استفاده شده اند به دلیل استفاده از تکنیک‌های obfuscation به نسبت سخت‌تر از قبلی‌ها آنالیز می‌شوند. به علاوه، برخی کاربردهای بیشتری به آن‌ها اضافه شده است؛ به طور خاص ما متوجه این شدیم که نسخه‌های جدیدتر، از تکنیک reflection برای دور زدن سرویس App Ops که روی نوشتن SMS محدودیت می‌گذارد(معرفی شده در اندروید نسخه‌ی 4.3) استفاده می‌کنند. همه‌ی این‌ها این معنی را می‌رسانند که عاملان این تهدید به صورت فعالانه در حال توسعه‌ی کدِ بدافزارشان هستند.
• ·         برخلاف کمپین RuMMS، که به طور کلی از سرویس‌های هاستینگِ shared برای پخشِ بدافزار استفاده می‌کرد، کمپین‌های فیشینگِ اسمسیِ اروپایی تنوعِ بیشتری در زیرساخت‌های استفاده شده، برای مثال استفاده از دامنه‌های شخصی، سایت‌های هک‌شده، و سرویس‌های کوتاه‌کردن URL، نشان می‌دهند. از فوریه‌ی 2016، ما ۲۷ لینک bit.ly را مشاهده کردیم که در بدافزار و پخش آن استفاده شده‌بودند. در ژوئن ۲۰۱۶، ما متوجه سه سرویس کوتاه‌کردن URL دیگر شدیم که عبارت بودند از tr.im, jar.mar و is.gd و در کمپین آخری استفاده شده بودند. این مسئله آن معنی را می‌رساند که گردانندگان این تهدید سعی دارند با استفاده از تنوع کوتاه‌کننده‌های URL، از تشخیص داده شدن جلوگیری کنند.
• ·         در مجموع، ما ۱۲ سرورِ C2 را که در ۵ کشور مختلف قرار داشتند و در این کمپین‌ها استفاده می‌شدند را شناسایی کردیم. بین آن‌ها، آی‌پی آدرسِ 85.93.5.109 توسط 24 برنامه‌ی مخرب در دو کمپین و 85.93.5.139 توسط 8 برنامه‌ی مخرب استفاده شده بود. ما همچنین ۴ سرورِ C2 را مشاهده کردیم که همگی در رنج آیپی 85.93.5.0/24 بودند. همه‌ی این‌ها نشانگر آن است که گردانندگان تهدید دسترسی بر منابع شبکه‌ی ارتباطی قابل توجهی دارند.
• ·         سرویس‌های کوتاه‌کردن URL معمولاً سرویس‌های آنالیز بازدید ارائه می‌کنند؛ که ما را در یافتن این‌که چه تعداد کاربر (از چه کشور‌هایی) در چه زمانی روی لینک کوتاهمون کلیک کرده اند، کمک می‌کند. با استفاده از این سرویس‌ها، ما متوجه شدیم که حداقل 161349 کلیک بر روی ۳۰ لینک کوتاهی که به بدافزار پوششی منتقل می‌شدند، انجام شده است که هر یک می‌توانسته است موجب آلودگیِ یک دستگاه اندرویدی شود. اطلاعات زمانی مشخص کرد که بیشترین کلیک‌ها در چند روز ابتدایی ساخته‌شدن لینک انجام شده است.

پنج کمپینِ فیشینگِ اروپایی

از فوریه‌ی 2016 تا آوریل 2016، محققان امنیتی خبر از سه کمپینی دادند که شامل بدافزار پوششی اندرویدی بود که با استفاده از فیشینگِ اسمسی پخش می‌شد. طبق توضیحات گزارش‌ها، 

این کمپین‌ها از طریق اسمسِ فیشینگی که به گوشی کاربر ارسال می‌شده شروع می‌شده‌اند. یک پیام متنی برای مثال در شکل۱ آمده است. پیام به سختی به «ما نتوانستیم سفارش شما را تحویل دهیم. لطفا اطلاعات باربری خود را در لینک ... بررسی کنید» ترجمه می‌شود. کاربران دانمارکی و ایتالیایی از اهداف اولیه‌ی این سه کمپین گزارش شده‌اند.

تحقیقات اخیر ما مشخص کرده که این فعالیت‌ها همچنان در حال توسعه در کشورهای دیگر اروپا؛ مانند آلمان و اتریش نیز هستند که در آن‌جا هم اثراتی داشته‌اند. ما این فعالیت‌ها را در پنج کمپین؛ همان‌طور که در جدول۱ قابل مشاهده است، دسته‌بندی کرده‌ایم.

جدول۱. نمای کلی پنج کمپین فیشینگ اسمسیِ اروپایی که بر اساس زمان شروع مرتب شده‌اند.

(*: در ابتدا توسط محققان FireEye عمومی شد)

لینک‌های کوتاه به صورت مشترک در همه‌ی این پنج کمپین استفاده شده بودند. در مجموع ما ۳۰ لینک کوتاه‌شده یافتیم. برخی سایت‌های کوتاه‌کردن آدرس، سرویس آنالیز ارائه می‌کنند؛ که از طریق آن هر کس می‌تواند ببیند که چند نفر روی لینک کلیک کرده‌اند و این کلیک‌ها از چه کشورهای نشأت می‌گرفته‌اند. برای مثال، تصویر۲ نشان می‌دهد که ۱۳۵ کلیک از آلمان بر روی یکی از نمونه‌های Whats-Germany، و 1633 کلیک از اتریش روی یکی از نمونه‌های Post-Austria انجام شده است.

تصویر۲. صفحه‌ی آنالیز نمونه‌های Whats-Germany و post-Austria

تکامل کد

در کمپین‌های فیشینگ اسمسی فوق، ما مشاهده کردیم که کد بدافزار با گذر زمان در حال تحول است. سازنده‌های بدافزار به نظر با پشتکار در حال تلاش برای بهبود کد هستند؛ برای مثال با اضافه کردن برنامه‌های هدفِ جدید، obfuscate کردن کد برای جلوگیری از تشخیص‌داده‌شدن، و تلاش برای دور زدن محدودیت‌های App Ops.

اضافه‌کردن برنامه‌های هدفِ جدید

همه‌ی پنج کمپین تلاش دارند تا از برنامه‌های خاص هدفی، دزدیِ اطلاعات تعیین هویت کنند. وقتی برنامه‌ی مخرب شروع به کار می‌کند، یک سرویس در پس‌زمینه اجرا می‌شود تا برنامه‌هایی که در حال نمایش روی صفحه هستند را مانیتور کند. وقتی سرویس متوجه آن می‌شود که برنامه‌ی در حال نمایش روی صفحه، یکی از برنامه‌های مورد هدف است، یک نمای روکشی که با دقت مشابه آن طراحی شده است را روی برنامه‌ی هدف به نمایش در می‌آورد.

آنالیز کد بدافزار نشان می‌دهد که این وظیفه با استفاده از یک متد در سرویس اصلی، به نام initInjTask (در اکثر موارد) اجرا می‌شود. شکل۳ کد initInjTask را در یکی از اولین نمونه‌های کمپین MPayDenmark نمایش می‌دهد که در آن یک برنامه‌ی محلی به نام MobilePay مورد هدف قرار گرفته بود.

شکل۳. کلاس MobileBank قرار است اجرا شود تا پوششی باشد برای برنامه‌ای با نام dk.danskebank.mobilepay

(کد از برنامه‌ای با کد MD5 روبرو به دست آمده: 49dac3b35afb2e8d3605c72d0d83f631)

شکل۴ کد initInjTask را در یک نمونه‌ی Whats-Italy نمایش می‌دهد؛ که در آن هدف به یک برنامه با کاربرد گسترده‌تر تغییر کرده بود: مسنجر WhatsApp.

شکل4. کلاس Cards قرار است اجرا شود تا پوششی باشد برای برنامه‌ی com.whatsapp

(کد از برنامه‌ای با کد MD5 روبرو به دست آمده: 97c2d04aa0f3c3b446fc228c1dbc4837)

شکل5 کد initInjTask را در یک نمونه‌ی Whats-Germany نمایش می‌دهد؛ که در آن هدف به دو برنامه‌ی WhatsApp و Google Play Store تغییر کرده بود.

شکل5. کلاس Cards قرار است اجرا شود تا پوششی باشد برای برنامه‌های WhatsApp و Play Store

(کد از برنامه‌ای با کد MD5 روبرو به دست آمده: 9e9d9a3717eed4d558a3f5eddb260901)

شکل6 کد initInjTask را در یک نمونه‌ی Post-Austria نمایش می‌دهد(در این مورد، کد برنامه‌ی مخرب obfuscate شده بود؛ کد از فایل jar افتاده استخراج شده است). در مجموع، هشت برنامه‌ی محبوب جهانی، من‌جمله Uber و WeChat در رادار آن بودند.

شکل6. کلاس cqkwjqjtoz قرار است اجرا شود تا پوششی باشد برای هشت برنامه‌ی محبوب

(کد از برنامه‌ای با کد MD5 روبرو به دست آمده: d70296d3dc4937dedd44f93bb3b74034)

Obfuscateکردنِ کد

در کمپین‌های اولیه، من‌جمله MPay-Denmak, Whats-Italy و Whats-Germany، بیشتر برنامه‌های مخرب به صورت obfuscate نشده بودند و مهندسان معکوسِ با تجربه به سادگی می‌توانستند با کد disassembled شده کار کنند.

شکل7 کد manifest و ساختار کد نمونه‌های ابتدایی را نشان می‌دهد. با این دو بخش از اطلاعات می‌بینیم که سه receiver برای اهداف مختلفی رجیستر شده‌اند: برای مدیریت SMSهای دریافتی؛ برای درخواست برای دسترسی admin؛ و برای شروع برنامه در هنگام بوت شدن و مدیریت دو رویداد مرتبط به اپلیکیشن. همین‌طور دو سرویس وجود دارند که برای اجرا در پس‌زمینه ساخته شده‌اند و چهار activity که برای تعامل با کاربر هستند. با اطلاعات کلی‌ای که در دست داریم، آنالیزورهای بدافزار ماهر می‌توانند به سادگی بفهمند که هر قسمت از کد چه نقشی دارد و در ادامه متوجه شوند که چطور این قسمت‌ها با یکدیگر کار می‌کنند تا به نتیجه‌ی بدافزار برسند.

شکل7. ساختار کد و فایل manifest از یک کد اولیه و obfuscate نشده

از آوریل 2016، مشاهده کردیم که همه‌ی نمونه‌های دیتابیس ما از تکنیک‌های obfuscation استفاده کرده‌اند. با obfuscation، فایل manifest به نسبت برای خواندن سخت‌تر شد و ساختار کد به طور کامل متفاوت شد.

شکل8 یک نمونه را نشان می‌دهد که در کمپین PostDanmark است. ساختار کد در سمت چپ نشان می‌دهد که چهار class به نام‌های a,b,c,d و mrtbeig با نام پکیج مشترک com.atrdectn.ioitsrc وجود دارند. در سمت راست، فایل manifest نشان می‌دهد که چهار receiver وجود دارد؛ هفت سرویس و چهار activity؛ البته با نام پکیج متفاوتِ com.lpygioep.tjzcverotl. خوب پس کدِ این کلاس‌های تعریف شده کجاست؟ هدفِ این کلاس‌هایی که در چپ نام‌گذاری شده‌اند چیست؟ این‌جا کد برای آنالیز شدیداً پیچیده‌تر شده است.

شکل8. ساختار کد و فایل manifest از کد obfuscate شده

تحقیقات عمیق‌تر نشان داد که این کلاس‌ها که در سمت چپ تعریف شده‌اند payload واقعی را می‌سازند و view فیشینگ را روی هشت برنامه‌ی شناخته‌شده‌ی معروف نمایش می‌دهند. کد آن‌ها در واقع در فایل assetای به نام mptxip.dat ذخیره شده است که به صورت خاصی encode شده است.

کلاس‌های سمت چپ در واقع کد را unpack می‌کنند تا فایل asset را دیکد کنند، تا payload واقعی را در زمان اجرا بارگذاری کنند و از reflection برای اجرای کد مخرب در payload استفاده کنند. این پروسه به نسبت پیچیده‌تر است و ابتدا یک سری آنالیز کد استاتیک نیاز دارد تا مشخص شود چه چیزی در کد موجود است، سپس آنالیزهای دینامیک(زمان اجرا) تا payload واقعی را به دست آید؛ و سپس هر دو آنالیز برای فهمِ payload واقعی. سازنده‌های آنتی‌ویروس‌ها همواره در شناسایی این‌گونه تهدیدها دچار مشکل هستند. به طوری‌که در 8 ژوئن 2016، تنها 6 آنتی‌ویروس از 54تا، توانستند این نمونه‌ها را به عنوان ویروس تشخیص دهند.

دورزدن محدودیت App Ops

اندروید از permissionها برای اپلیکیشن‌ها استفاده می‌کند تا مشخص کند که یک برنامه چه رفتارهای حساسی می‌تواند انجام دهد. در نسخه‌های قبلیِ سیستم‌عامل اندروید، وقتی یک برنامه نصب می‌شد، از کاربر خواسته می‌شد تا دسترسی‌هایی که برنامه درخواست می‌کند را تایید کند. اگر کاربر با این دسترسی‌ها مخالفت می‌کرد، برنامه نصب نمی‌شد؛ که مفهومش «همه یا هیچ» است(یا برنامه نصب می‌شود یا کلاً نصب نمی‌شود، حد وسطی نداریم). App Ops یک سرویس است که در اندروید 4.3 برای اولین بار به کار رفت، و کارش آن است که اجازه می‌دهد دسترسی‌های یک برنامه در زمان اجرا تغییر کند. با استفاده از App Ops، کاربر می‌تواند بعضی دسترسی‌های برنامه را در زمان اجرا تایید یا رد کند. به طور جالبی مشاهده کردیم که از کمپین What-Italy به بعد، بدافزارهای پوششی شروع به اضافه کردن کدهایی کردند که سعی داشت این محدودیت را دور بزند.

شکل۱۰ قطعه‌کدی را در کلاسِ MainService نشان می‌دهد که در زمان شروع اپلیکیشن توسط launcher activity اجرا می‌کردد. این قطعه‌کد بررسی می‌کند که آیا build version این دستگاه 19 (یعنی اندروید 4.4) هست یا نه؛ و این‌که آیا App Ops دسترسیِ WRITE_SMS را محدود کرده یا نه. اگه هر دو شرط صحیح باشند، بدافزار تابع setWriteEnabled را از کلاسِ SmsWriteOpUtil(در خط 93) صدا می‌کند تا دوباره دسترسیِ نوشتنِ SMS را فعال کند.

شکل9. کدی برای چک کردن و فعال‌سازی دوباره‌ی دسترسیِ نوشتن SMS

شکل۱۰ کد اصلیِ SmsWriteOpUtil را برای فعال‌سازی دوباره‌ی دسترسی نوشتن SMS نشان می‌دهد. در خط 60، یک handle به سرویس سیستمیِ App Ops وصل شده است. در خط 61، reflection برای گرفتن دسترسی به کلاسِ خاص استفاده شده است. در خط 64 . 65، متدهای reflection، یعنی getMethod و invoke برای صدا زدنِ یک متد به نام setMode استفاده شده‌اند. این متدهای API معمولاً برای استفاده توسط کد فریم‌ورک‌های دیگر و یا اپلیکیشن‌های از پیش نصب شده ساخته می‌شوند. هر چند در این کیسِ خاص، گردانندگان تهدید از reflection برای دور زدن محدودیت App Ops استفاده می‌کنند.

شکل10. کدی که از reflection برای صدا کردن سرویس App Ops استفاده می‌کند تا دسترسی نوشتن SMS را فعال کند.

سایت‌های میزبانی

برای اجرای کمپین‌های فیشینگ اسمسی، گردانندگان تهدید اول باید مشخص کنند که کجا قرار است بدافزارشان را میزبانی کنند. سرویس‌های هاستینگ اشتراکی به شدت در کمپین RuMMS استفاده شده بودند، اما گردانندگان تهدید در این پنج کمپین آن‌را به استفاده از دامنه‌های شخصی، کوتاه‌کننده‌های URL، و سایت‌های هک‌شده کمی تغییر دادند.

دامنه‌های شخصی

در تحقیقات، ما متوجه شدیم که بعضی از دامنه‌های URLها، چند روز قبل از این‌که بدافزار روی آن‌سایت‌ها میزبانی شود رجیستر شده بودند. همچنین متوجه شدیم که هیچ سرویس دیگری روی این دامنه‌ها در حال اجرا نبود. این واقعیت‌ها ما را به این حقیقت می‌رساند که باور کنیم آن سایت‌ها صرفاً برای کمپین‌های فیشینگ اسمسی ثبت شده بودند.

برای این‌که کاربران قربانی فریب بخورند و روی این لینک‌ها کلیک کنند، دامنه‌ها هر کدام صرفاً برای یک کمپین بهینه‌سازی نامی شده بودند. برای مثال، در کمپین اولیه‌ی MPay-Denmark، گردانندگان تهدید از سرویس Danish postal service به عنوان یک نمایه استفاده کرده بودند و پیام دریافت شده عبارت بود از «شما یک MMS از XXX دریافت کرده‌اید. لینک ... را دنبال کنید تا این پیام را مشاهده نمایید». در نتیجه بسیاری از دامنه‌ها حاوی کلمه‌ی mms، و you بودند؛ مانند mmsforyou.pw، mmsservice.pw و mmstildig.net (til dig در زبان دانمارکی به معنای «برای شما» است).

در کمپین بعدی PostDanmark، پیام فیشینگ اسمسی به صورت «بسته‌ی شما برای دریافت آماده است. لینک ... را دنبال کنید تا همه‌ی اطلاعات بسته‌تان را مشاهده کنید» بود. در نتیجه بسیاری از آدرس دامنه‌ها عبارت‌هایی مانند post، و یا danmark را دارا بودند؛ مانند postdanmark.net، postdanmark.online، postdanmark.menu و postdanmarks.com. دقت کنید که آدرس سایت رسمیِ پستِ دانمارک، www.postdanmark.dk است. در نتیجه همه‌ی این آدرس‌های فیشینگ در واقع قصد تقلیدِ دامنه‌ی پست دانمارک اصلی را داشته‌اند.

لینک‌های کوتاه‌شده

یک صفحه نمایش با اندازه‌ی کوچک، لینک‌های کوتاه‌شده را برای دستگاه‌های تلفن بی‌نقص می‌سازد. گردانندگان تهدید به ظاهر این واقعیت را می‌دانسته‌اند، و از آن استفاده کرده‌اند تا به مقصود خود برسند. زمانی که این پنج کمپین را در اروپا مانیتور می‌کردیم، متوجه شدیم که لینک‌های کوتاه‌شده‌ی مشاهده‌شده به تعداد زیاد استفاده می‌شده‌اند. در مجموع، ما چهار سرویس کوتاه‌سازی لینک را مشاهده کردیم که هر کدام حداقل یک بار استفاده شده بودند، من‌جمله bit.ly, tr.im, is.gd و jar.ma.

از این چهارتا، bit.ly از همه بیشتر مورد استفاده قرار گرفته بود. در مجموع ما ۲۷ لینک bit.ly را که از فوریه‌ی 2016 تا ژوئن 2016 استفاده شده بودند، شناسایی کردیم. سه سرویس کوتاه‌سازی لینک دیگر تا ژوئن 2016 مشاهده نشده بودند، و فقط یکی از آن‌ها برای هر سرویس استفاده شده بود. تنوع‌دهی به سرویس‌های کوتاه‌سازی لینک به ما این امر را نشان می‌دهد که گردانندگان این تهدید سعی دارند از شناسایی شدن فرار کنند.

سایت‌های هک‌شده

هزینه‌بر است که بخواهیم از دامنه‌های شخصی برای میزبانی بدافزار استفاده کنیم. گردانندگان تواناتر تهدید ممکن است بخواهند از یکی از وب‌سایت‌هایی که پیش‌تر هک شده و به آن دسترسی دارند برای امر میزبانی استفاده کنند. البته این احتمال موجود است که سایت قربانی متوجه میزبانی بدافزار بشود و آن‌را حذف کند، در غیر این صورت روش میزبانی روی سایت‌های هک‌شده به نظر عملی می‌آید. شناسایی شدن بدافزار روی هاست‌ها عمدتاً تا زمان طولانی انجام نمی‌شود، و تعداد کلیک‌های قربانی‌ها معمولاً در ابتدای زمان شروع کمپین، نسبت به ده‌ها روز بعد بیشتر است.

در زمان مانیتور کردن این پنج کمپین فیشینگ اسمسی، ما مشاهده کردیم که سایت‌های هک‌شده به کرات استفاده می‌شدند. برای مثال، لینکِ آنالیز برای لینک کوتاه‌شده‌ی hxxps://bitly[.]com/1qRey7a+ به ما نشان می‌دهد که در ۱۳آوریل ۲۰۱۶، وب‌سایتِ kgiexport.com یک برنامه‌ی اندروید با نام post.apk را میزبانی می‌کرده است.

چند کلیک؟

دوتا از سرویس‌های کوتاه‌سازیِ لینک، یعنی bit.ly و tr.im صفحات آنالیز برای لینک‌های کوچک‌شده‌ای که می‌سازند ارائه می‌کنند. شکل۲ صفحه‌ی آنالیزی که برای لینکی از bit.ly است را نشان می‌دهد. شکل۱۳ یک اسکرین‌شات از صفحه‌ی آنالیزی که توسط tr.im ارائه شده است را نشان می‌دهد. برای این صفحات، ما می‌توانیم اطلاعاتی در مورد این‌که چند نفر روی لینک کوتاه‌شده در زمانی خاص کلیک کرده‌اند، و همچنین کشور مبدا این کلیک‌ها به دست آوریم.

شکل11. صفحه‌ی آنالیزی که توسط tr.im ارائه شده است.

جدول۲ اطلاعاتی را مرتبط با 28 لینک کوتاه‌شده‌ای که مانیتور شده‌اند به دست می‌دهد.

جدول۲. تعداد کلیک‌ها روی هر لینک کوتاه شده

در مجموع ۲۸ لینک کوتاه‌شده، ۱۶۱۳۴۹ بار کلیک شده اند. از این کلیک‌ها، ۱۳۰۶۳۶ تای آن‌ها از کمپین PostDanmark آمده‌اند، که نشان می‌دهد پیام‌های فیشینگی که ادعا شوند از اداره پست آمده‌اند موفق‌تر خواهند بود(!). ما همچنین متوجه این شدیم که تعداد کلیک‌ها چند روز بعد از ساخت این لینک‌ها افت کردند. برای مثال 96631 کلیک(67.06٪) کلیک‌ها در روز اول ساخته شدن لینک‌های کوتاه انجام شده‌اند و 30749 کلیک (21.33٪) در روز دوم ساخته‌شدن انجام شده‌اند. این کلیک‌ها به صورت عمده از دو کشور می‌آمده‌اند: دانمارک(88.66٪) و اتریش(5.30٪). یک سری کشورهای دیگر نیز ممکن است مورد هدف قرار گرفته باشند؛ من جمله آلمان، لوکزامبورگ، اسپانیا، سوئد، نروژ، بریتانیا، هلند، ایتالیا، یونان و ترکیه.

سرور C2

همه‌ی بدافزارهایی که آنالیز کردیم با یک سرور پیکربندی‌شده‌ی C2 برای ارسال اطلاعات مرتبط با دستگاه و گرفتن دستورات مرتبط بودند. آدرسی که برای ارتباط با سرور استفاده می‌شد به فرم http://$C2.$SERVER.$IP/?action=command بود. در مجموع ما ۱۲ سرور C2 که در پنج کشور مختلف میزبانی می‌شدند را پیدا کردیم که در این کمپین‌ها مورد استفاده قرار گرفته بودند. جدول۳ اطلاعاتی را مرتبط با این سرورهای C2 ارائه می‌کند.

جدول3. اطلاعات مرتبط با سرورهای C2

به طور خاص، آدرس آیپیِ 85.93.5.109 توسط 24 بدافزار در کمپین‌های PostDanmark و post-Austria استفاده شده بود. آدرس آیپیِ 85.93.5.139 توسط 8 بدافزار در کمپین PostDanmark استفاده شده بود. دقت کنید که چهار سرور اول C2 در رنج آیپی مشابه 85.93.5.0/24 هستند. در مجموع ما 38 نمونه بدافزار پیدا کردیم که با این چهار سرور C2 از مارس 2016 تا ژوئن 2016 در ارتباط بودند.

آیا این بدافزارها قسمت کوچکی از یک چیز بزرگتر هستند؟

وقتی اطلاعات ثبت این دامنه‌های شخصی را بررسی می‌کردیم، یک چیز جالب پیدا کردیم: در مارس 2016، یک ایمیل(l[REDACTED][e-mail]) به تنهایی سه دامنه‌را، من‌جمله postdanmark.org, postdanmark.menu و mmstildig.info را برای دوتا از پنج کمپین ثبت کرده است. با استفاده از reverse lookup، ما چهار دامنه‌ی مشابه را پیدا کردیم که با ایمیل آدرس مشابهی در مارس 2016 ثبت شده بودند. جدول 4 اطلاعاتی را در رابطه با این دامنه‌ها ارائه می‌کند.

جدول4. دامنه‌هایی که توسط گرداننده‌ی تهدید احتمالی(l[REDACTED][e-mail]) ثبت شده‌اند.

سه دامنه‌ی اول برای میزبانیِ بدافزار کمپین‌های MPay-Denmark و PostDanmark استفاده شده بودند. ما هیچ شواهدی مبنی بر این‌که چهار دامنه‌ی بعدی برای کمپین‌های مشابه استفاده بشوند پیدا نکردیم؛ اما ایمیل آدرس ثبت‌کننده‌ی مشابه و نام‌گذاری مشابه آن‌ها این مفهوم را منتقل می‌کند که احتمالاً آن‌ها هم برای قصد مشابهی ساخته شده‌اند.

جمع‌بندی

فیشینگ اسمسی یک الگوی جدید برای آلوده‌کردن کاربران موبایل ارائه می‌کند. کمپین‌های فیشینگ اسمسی بعدی که در اروپا پخش شدند نشان می‌دهد که هنوز فیشینگ اسمسی یک ابزار محبوب در بین گردانندگان تهدیدها برای پخش کردن بدافزارشان است. به علاوه گردانندگان تهدید از آدرس‌های میزبانی متنوع و سرورهای C2 متفاوتی استفاده می‌کنند و به طور مداوم در حال بهبود دادن کد مخرب خود برای آلوده‌کردن تعداد کاربران بیشتر و فرار از شناسایی شدن هستند.

برای محافظت از خود در برابر این تهدیدها، FireEye پیشنهاد می‌کند که کاربران برنامه‌هایی خارج از app storeهای رسمی نصب نکنند،  و قبل از کلیک روی هر لینکی که منبع آن مشخص نیست، احتیاط‌ها را رعایت کنند.

برای پیدا کردن و دفاع در برابر این حملات، ما از مشتریان خود می‌خواهیم تا برنامه‌ی FireEye MTP/MSM که برای امنیت موبایل است را نصب کنند. این به مشتریانمان کمک می‌کند تا تهدید‌های مشابه را در حوزه‌ی کاربری خود ببینند و همچنین آن‌ها را قادر می‌سازد تا به سادگی دستگاه‌هایی که ممکن است هک شده باشند را پیدا کنند. به علاوه ما مشتریان خود را به استفاده از لوازم NX توصیه می‌کنیم تا با اسکن شبکه‌ی Wi-Fi خود توسط آن، دسترسی کامل‌تری به دستگاه‌ها موبایل برسانند.

ضمیمه: نمونه‌ها

df53b59e354462cd0e704b7b21a750f7

6eb92667ebbbcb2c7ddf6230462222fd

3841abcef2b1b37aa7e2d47c535ca80e

265d37013e1ea39b868515cce157dfeb

49dac3b35afb2e8d3605c72d0d83f631

ffe98d97e7d827aa19abb968a528f3fe

f4b8d64af0a53472901b50621f19d6bf

e1d79608b649c22004ad7cc1cd049528

ef5c9b15755719597481c501f6b603ce

6a300ded487671ef39388b8d28927a83

d33b718737de5aa685672a2004e0fa3c

d83d833092a4fa5ecc436d4246c2f7ce

97c2d04aa0f3c3b446fc228c1dbc4837

82b1006a5f45a6d2baf69544414ada81

9e9d9a3717eed4d558a3f5eddb260901

82d89319fabd998328cc6d4efc4db863

228a4b723bf3d8adc53a69dd0f36c746

e911df33f1d156b3309a4ac220c52070

2b90fca41272bec8b8ffefbb2456c001

40449a2ec48c3e630b2eb8c8089828cf

8d0a03981daa93210e184e7fff02883c

fbdde37d41d12f21c049c570c9bda3de

a18818cb3fb6f189560991cef6d1f929

bf7b72dbb2a9155dabc4eda31d273b92

9762441d52bdec725eff6f2f65e721e9

dba6b4bbf61e054fb978acaf70c3d849

93922ee5fbd149f31b0161deca76df77

035d1f3b7fb532a33de7a8445f9fa325

3f2017a5acb3e57801e2771341287001

06e74df867e9cb5c1bafc98165c6c248

20f4cd2baa09e0bd5e12dab50c0898cd

af7a8d32865e8caf51a99c52834d4422

82d89319fabd998328cc6d4efc4db863

bee3746684b072867a5b202bfc5527dd

a18818cb3fb6f189560991cef6d1f929

8959513f65bcca6f16faef59ad2d152f

cfa92cbcb0674429cc9ce216cc008902

d73d54f6f86c58030477cc9a96eedb85

2f4d81ef1b10bf72d0dba0fdf354527f

701d57504444344b8d5e79bcabcd3dca

fcb4ef63f1d8a3a044ac6f8a7c262546

05131969af2ae6cbfddf789512f02aa2

6e93a7f7911b3e9b522be4b8f950cca4

542f8f77e101d4e8e5d1ef34a3f0df1c

d0a6ba40e05047dc2cff12935c4cf4fb

23988abad7c7b2ecdda23ae7194b7a0d

2c055d7b5199604cd5cf3441073b36b3

a72aa534973eeaf0782a246d502107a3

f1c8a3337cbd56e01e478774f5d55278

da222d4b7993a62665b9eaef10c1846f

152f626eb92676f940ada4b7077acf16

7a99b60349703aed3ab28f498320f247

1b9e1cd2c7f8e227b2ae5fb5bc735536

d84ff5a7e7c0c33dcfa237299869bc34

d70296d3dc4937dedd44f93bb3b74034

88b23b6a5c1b72aeff2fc42e05c173a7

036258e2c51e21c140b5838ce9bfb4f8

کاظم و بات‌ها

امروز می‌خواهیم یک تمرینِ عملی از بات‌ها را اجرا کنیم؛ این‌بار هدفمان سایتِ «قلم‌چی» است و پروژه‌ای که اجرا می‌کنیم بسیار کارآمد است؛ حداقل خودِ من ابتدا آن‌را به عنوانِ یک نیاز اجرا کردم و سپس تصمیم به نوشتنِ این پست گرفتم.

...

Il lui disait : - Vos chants sont tristes. Qu'avez-vous ? 

Ange inquiet, quels pleurs mouillent vos yeux si doux ? 

Pourquoi, pauvre âme tendre, inclinée et fidèle, 

Comme un jonc que le vent a ployé d'un coup d'aile, 

Pencher votre beau front assombri par instants ? 

Il faut vous réjouir, car voici le printemps, 

Avril, saison dorée, où, parmi les zéphires, 

Les parfums, les chansons, les baisers, les sourires, 

Et les charmants propos qu'on dit à demi-voix, 

L'amour revient aux coeurs comme la feuille aux bois !

Elle lui répondit de sa voix grave et douce :

Ami, vous êtes fort. Sûr du Dieu qui vous pousse, 

L'oeil fixé sur un but, vous marchez droit et fier, 

Sans la peur de demain, sans le souci d'hier, 

Et rien ne peut troubler, pour votre âme ravie, 

La belle vision qui vous cache la vie. 

Mais moi je pleure ! - Morne, attachée à vos pas,

Atteinte à tous ces coups que vous ne sentez pas, 

Coeur fait, moins l'espérance, à l'image du vôtre, 

Je souffre dans ce monde et vous chantez dans l'autre. 

Tout m'attriste, avenir que je vois à faux jour, 

Aigreur de la raison qui querelle l'amour, 

Et l'âcre jalousie alors qu'une autre femme 

Veut tirer de vos yeux un regard de votre âme, 

Et le sort qui nous frappe et qui n'est jamais las. 

Plus le soleil reluit, plus je suis sombre, hélas ! 

Vous allez, moi je suis, vous marchez, moi je tremble, 

Et tandis que, formant mille projets ensemble, 

Vous semblez ignorer, passant robuste et doux, 

Tous les angles que fait le monde autour de nous, 

Je me traîne après vous, pauvre femme blessée. 

D'un corps resté debout l'ombre est parfois brisée.

---

بابت وقفه‌ی پیش اومده، ....!

آموزش ها ادامه دارد ...

جاواکارت مقدماتی/9- Hello World در جاواکارت

قسمت قبلی: برنامه نویسی جاواکارت در محیط Eclipse

پس از آشنا شدن با مراحل ساخت یک پروژه ی ساده در دو IDE مشهورِ Eclipse و Netbeans، اینک نوبت به آن می‌رسد که دست به کُد شویم! :) طبق روال جا افتاده در دنیای برنامه نویسی، کار خود را با برنامه‌ی Hello World در جاواکارت آغاز می‌کنیم. همه‌ی کاری که این اپلت انجام می‌دهد این است که در پاسخ به هر دستوری که به کارت ارسال می‌شود، عبارت "Hello World" را بازگردانی می‌کند.

سلام دنیا!

کار خود را، با افزودن خطوطی به برنامه‌ی قالبی ای که Eclipse یا Netbeans در مراحل قبل در اختیار ما قرار دادند آغاز می‌کنیم. با فرض این که شما در مراحل ایجاد پروژه، اسم پروژه را "HelloWorld" و اسم پکیج را "helloWorldPackage" انتخاب کرده باشید، پس از حذف Commentهای اتوماتیکی که IDE اضافه می‌کند، تکه کدی، مشابه کد زیر خواهید داشت:

همانطور که در تصویر بالا مشاهده می کنید، برنامه به سه قسمت کلی تقسیم شده است. خط اول، نام Package می‌باشد. قبلا نیز اشاره کرده بودیم که حتما به Package اپلت خود،یک نام اختصاص دهید و هیچگاه فیلد آن را خالی مگذارید، چرا که خالی گذاشتن این فیلد، خصوصا در محیط Eclipse، هنگام Compile برنامه، خطاهایی عجیبی نمایان می‌کند! پکیج در واقع، فایلی است که درون آن اپلت قرار گرفته است، و بسته به نوع کارت، پس از نصب اپلت می‌توان نام پکیج را نیز در کارت مشاهده کرد.

قسمت دوم که شامل یک مجموعه خطوط است که با کلمه‌ی import شروع شده اند، قسمت افزودن Libraryهای ضروری به برنامه است. با توجه به کارکردی که یک برنامه‌ی جاواکارت قرار است داشته باشد، اوراکل، کتابخانه‌های مختلفی تهیه کرده است و همراه JCDK در اختیار برنامه‌نویس قرار داده است. تابع های این کتابخانه‌ها(ماژول ها)، با توجه به ارتباط و کاربردشان به دسته‌های مختلف تقسیم شده اند. برنامه نویس هنگامی که نیاز به استفاده از یک تابع دارد، ابتدا باید ماژولی که این تابع در آن قرار دارد را import کند. البته IDE به صورت خودکار، در صورتی که شما تابعی استفاده کنید که ماژول آن import نشده است، با نمایش یک خطا شما را آگاه می‌سازد و پیشنهاد import کردن آن ماژول را می‌دهد. اصلی ترین ماژول ها و تابع ها که به صورت پیش فرض توسط IDE در آغاز ساخت پروژه، import  می شوند، ماژول های زیرمجموعه ی javacard.framework می‎باشند. 

و اما قسمت سوم و قسمت اساسی اپلت، همان "کلاس" آن است. 

همانند زبان جاوا، در زبان جاواکارت نیز، هر اپلت متشکل از یک کلاس است که توابع ما (Methods/Functions) داخل این کلاس قرار می‌گیرند. یکی از نکات حائز اهمیتی که اپلت‌های جاواکارت را از برنامه‌های نوشته شده به زبان جاوا متمایز می‌کند این است که، همه‌ی اپلت‌های جاواکارت باید از کلاس Applet مشتق بشوند (به عبارت دیگر همگی باید فرزند کلاس Applet باشند- لطفا این کلاس را با نام برنامه های جاواکارت اشتباه نگیرید!). کلاس Applet، یکی از کلاس های موجود در کتابخانه‌ی javacard.frameword است که ما در ابتدای برنامه import کردیم. این عمل مشتق شدن(به ارث بردن) با عبارت extends Applet در خط شماره‌ی 5 برنامه انجام شده است.

در زبان جاوا/جاواکارت و سایر زبان‌های برنامه نویسی شیء گرا، وقتی یک کلاس از کلاس دیگری مشتق می‌شود، دو اتفاق می‌افتد:

1. به کلاس فرزند(کلاس که به ارث می‌برد=کلاسی که قبل از کلمه‌ی extends می‌آید)، فیلدها (Fields = Variables = متغیرها) و متدهای کلاس والد اضافه‌ می‌شوند (بجز آنچه که در کلاس والد از نوع Private تعریف شده است) و برنامه نویس می‌تواند از آن‌ها استفاده کند.
2. برنامه نویس مجبور به پیاده سازی متدهای Abstract کلاس والد می‌شود.(متدی که در کلاس والد تنها prototype آن[= خط تعریف] نوشته شده است و پیاده سازی آن به کلاس های به ارث برنده واگذار شده است).

در مورد کلاس Applet نیز به همین صورت است. با مشتق شدن اپلت ما از این کلاس، مجبور می‌شویم متد های Abstract آن را پیاده سازی کنیم. تنها متد Abstract این کلاس، متد process است(خط 16). پیش از آن که به توصیف عملکرد این کلاس بپردازیم تعریف کلّی دو متد پیشین، یعنی install و helloWorld و ذکر یک مقدمه خالی از فایده نیست. 

فرض کنیم که اپلت خود را تکمیل کرده ایم و قصد داریم روی کارت از آن استفاده کنیم. برای این منظور، نیاز به انجام دو مرحله داریم:

1. بارگذاری پکیج و اپلت درون آن (بله، یک یا چند اپلت، درون یک پکیج قرار می‌گیرند و روی کارت بارگذاری می‌شوند) روی کارت. 
2. نصب اپلت بارگذاری شده.

از آنجا که به انجام دو مرحله‌ی بالا در اصطلاح Install کردن اپلت گفته می‌شود، برای تمییز آن‌ها از یکدیگر، از دو عبارت Install for Load و Install for Install استفاده می‌شود. 

نکته‌ی بعدی این است که، ما می‌توانیم چند بار اپلت خود را با نام‌های مختلف(یعنی AIDهای مختلف) روی کارت نصب کنیم (مشابه این که چند بار Microsoft Office را با نام‌های مختلف در آدرس های مختلف رایانه نصب کنیم). برای این منظور، تنها یکبار عملیات Install for Load را انجام می‎‌دهیم و پس از آن عملیات Install for Install را به تعداد دلخواه تکرار می‌کنیم. 

اتفاقی که در علمیات Install for Load می‌افتد این است که فایل cap. از داخل رایانه به داخل حافظه‌ی کارت منتقل شده و آنجا Extract می‌شود. سپس AID پکیج و اپلت درون آن در جدول محتویات کارت قرار ثبت می‌شود.

و اتفاقی که در عملیات Install for Install رخ می‌دهد این است که متد install داخل اپلت (خط شماره‌ی 8) توسط Java Card Runtime Environment (با کمی اغماض می‌توانید به جای JCRE بخوانید Card Manager) فراخوانی می‌شود. نکته‌ی حائز اهمیت در مورد این متد این است که، برای هر اپلت نصب شده این متد یکبار و فقط یکبار، آن هم فقط و فقط توسط JCRE فراخوانی می‌شود. در واقع هیچ موجودیت(اپلت) دیگری روی کارت، دسترسی کافی برای فراخوانی آن را ندارد. 

در مورد پارامترهایی که جلوی متد install به عنوان ورودی این تابع معرفی شده اند، به این توصیف بسنده می‌کنیم که این پارامترها، همان AID اپلت در حال نصب می‌باشند. یعنی، وقتی قرار است اپلت بارگذاری شده را چند بار نصب کنیم، این متد را با ورودی های مختلف که همان AIDهای مختلف هستند، فراخوانی می‌کنیم. در آینده‌ی این کار را به صورت عملی خواهیم دید.

متد بعدی که نام آن باید با نام اپلت  یکی باشد، اصطلاحا Instructor یا سازنده نامیده می‌شود. کلیه‌ی برنامه‌های نوشته شده به زبان جاوا/جاواکارت نیازمند وجود این متدهای Instructor می‌باشند. متد register که درون این متد فراخوانی شده است، وظیفه‌ی ثبت AID اپلت در Registry Table کارت را دارد. (جدولی که لیست AIDهای نصب شده روی کارت را در بر دارد).

و در نهایت، نوبت به سومین متد، یعنی متد process است. تقریبا، همه‌ی آنچه ما با آن کار داریم این متد است. اما چرا؟

پاسخ:

پس از آن که اپلت ما با موفقیت هر دو مرحله‌ی Install for Load و Install for Install را پشت سر گذاشت، AID مربوط به آن، درون جدول رجیستری JCRE ثبت می‌شود. حال برای ارتباط با این اپلت نصب شده ما به این صورت عمل می‌کنیم که ابتداءََ با یک دستور(دستور SELECT)، به Card Manager اطلاع می‌دهیم که قصد ارتباط به فلان اپلت را داریم. Card Manager پس از این که وجود آن اپلت را بررسی کرد، با یک جواب مشخص، امکان ارتباط یا عدم امکان ارتباط را به ما گزارش می‌دهد. [این دستورها و این پاسخ‌ها، همانطور که پیش‌تر گفته ایم، APDU Command و  APDU Response نامیده می‌شوند و متشکل از یک سری عدد هگزادسیمال هستند].

در صورتی که جواب Card Manager به ما، حاکی از وجود امکان ارتباط با اپلت مورد نظرمان بود، شروع به ارسال دستورات دلخواهمان به کارت می‌کنیم. چیزی که در پس این ارتباط رخ می‌دهد این است که:

1. Card Manager این دستورات را از ما دریافت می‌کند و داخل یک بافر به نام APDU Buffer قرار می‌دهد.
2. بررسی می‌کند که آیا این دستور، دستور  SELECT اپلت دیگری نباشد.
3. بافر را به عنوان پارامتر، به متد process اپلتی که انتخاب شده است ارسال می‌کند و منتظر دریافت پاسخ از وی می‌ماند.
4. اپلت ما، پس از خواندن دستور دریافت شده درون بافر، پردازش های خود را انجام داده و پاسخ خود را مجدد در APDU Buffer قرار می‌دهد و آن را به Card Manager باز می‌گرداند.
5. Card Manager پاسخ دریافت کرده از متد process را به ما باز پس می‌دهد. 
6. بازگشت به مرحله‌ی 1

همانطور که مشاهده می‌کنید، ارتباط ما با اپلت نصب شده روی کارت، همواره با یک واسطه‌ی Card Manager است. ارتباط با یک اپلت، تا زمانی برقرار است که یا دستور SELECT دیگری ارسال کنیم یا این که کارت را از کارتخوان خارج کنیم. در صورتی که در مرحله‌ی 2، کارتخوان متوجه دستور SELECT شود، به جای رفتن به مرحله‌ی 3، اپلت فعلی را از انتخاب خارج می‌کند و در جدول رجیستری، به دنبال اپلت جدید می‌گردد و ...

بنابرین، کاربرد متد process نیز مشخص شد. همچنین عبارت قرمز شده در مرحله‌ی 3 بدین معناست که با ارسال هر دستور به کارت، باید انتظار یک پاسخ -هر چند کوتاه- از وی داشت و نمی‌توان چند دستور ارسال کرد و یکباره پاسخ گرفت. (چیزی مانند ارتباط یک به یک). نکته‌ی آخر این که، کارت نمی‌تواند آغازگر ارتباط باشد، بلکه تمام وقت، به عنوان Slave در یک ارتباط Master-Slave منتظر دریافت دستور است. 

و اما برنامه‌ی HelloWorld!

تا اینجای کار، نسبت به اتفاقاتی که حین ارتباط با اپلت رخ می‌دهد آشنا شدیم و اینک نوبت آن است که به کد قالبی ارائه شده توسط IDE خطوطی اضافه کنیم که در پاسخ به دستورات ارسالی ما عبارت "Hello World" را بازگردانی کند. طبق توضیحات بالا، می‌دانیم قسمت عمده ای از آنچه که باید دستخوش تغییر یا افزودن شود، تابع process است. 

ساده ترین حالت برنامه‌ی ما به صورت زیر خواهد بود:

برای آشنایی با توابعی که اضافه کرده ایم، می‌توانید به Java Card API Specification (یک سند pdf داخل JCDK) مراجعه کنید. اما به صورت اجمالی، در خطوط 15 و 16 یک آرایه از نوع بایت به نام  HELLO_WORLD تعریف کردیم و حروفی که می‌خواهیم در پاسخ به دستورات دریافتی به کاربر ارسال شود را در آن قرار دادیم. در خط 17، از تابع getbuffer روی شیء apdu استفاده کردیم تا بتوانیم به بافر APDU دست پیدا کنیم. این تابع، در واقع یک آرایه‌ی بایتی از APDU Buffer باز می‌گرداند، بنابراین با این خط ما متغیر buffer را به APDU Buffer ارجاع دادیم. 

در خط 18 با استفاده از تابع arrayCopyNonAtomic محتویات متغیر HELLO_WORLD را درون متغیر buffer کپی کردیم(که منجر به تغییر APDU Buffer می‌شود) و در آخرین خط برنامه، با استفاده از تابع setOutgoingAndSend بافر APDU را که حاوی پاسخ است، به Card Manager بازگرداندیم که به کاربر بیرون کارت بازگرداند. 

هرچند برنامه‌ی فوق به صورت صحیح به فایل cap. تبدیل می‌شود و به صورت صحیح هم بارگذاری و اجرا می‌شود، اما دارای نقاط ضعفی است که باید حتما رفع شوند. در قسمت بعدی با رفع این نقاط ضعف و اجرای اپلت نهایی در محیط Simulator آشنا خواهیم شد.

قسمت بعدی: استفاده از Simulator های جاواکارت (به زودی!)

---

شهر خالی‌ست ز عشّاق، مگر کز طرفی

دستی از غیب برون آید و کاری بکند ...

#حافظ_دوست_داشتنی

جاواکارت مقدماتی/8-برنامه نویسی جاواکارت در Eclipse

قسمت قبلی: برنامه نویسی جاواکارت در Netbeans

در قسمت قبل دیدیم که نسخه‌های جدید محیط برنامه نویسی Netbeans، به صورت پیشفرض، Pluginها و APIهای مورد نیاز برای برنامه نویسی جاواکارت را در خود دارند. متاسفانه در مورد محیط برنامه نویسی Eclipse اینگونه نیست (نویسنده از نسخه‌ی جدید این نرم افزار اطلاع ندارد). بنابراین نیاز است که برنامه نویس خودش Plugin و APIهای مورد نیاز را به آن بیفزاید.

سوال: IDE چیست؟ Plugin چیست؟ API چیست؟

پاسخ: IDE یا Integrated Development Environment یا محیط برنامه نویسی در واقع نرم افزارهایی مانند Netbeans، Eclipse یا Visual Studio هستند که فضایی را برای برنامه نویس فراهم می‌آوردند که برنامه‌های خود را به صورت راحت تر بنویسد و Compile/Interpret کند. 

API یا Application Programming Interface یا رابط برنامه نویسی نرم افزار، در واقع مجموعه ای از واسط/رابط ها بین برنامه ای که قرار است نوشته شود با کتابخانه‌های آن زبان یا سیستم عامل هستند. یکی از قابلیت‌هایی که IDE دارد این است که هنگام نوشتن برنامه و استفاده از این رابط های برنامه نویسی در کد برنامه، به صورت اتوماتیک چک می‌کند که آیا چنین رابطی وجود دارد یا خیر، و اگر موجود نبود، به برنامه نویس خطای استفاده از APIهای اشتباه می‌دهد و یا به وی کمک می‌کند آن را اصلاح کند. (بنابراین باید APIهای لازم را به محیط برنامه نویسی معرفی/اضافه کنیم).

و نهایتا Plugin مجموعه ای فایل است که برای یک نرم افزار مانند IDE نوشته شده اند که به آن قابلیتی اضافه کنند. 

به صورت روشن تر، وقتی ما JCDK را از سایت Oracle دانلود می‌کنیم، همه‌ی APIها و ابزارهای مورد نیاز برای نوشتن و ساخت یک اپلت در آن مجموعه وجود دارد. یعنی می‌توانیم بدون استفاده از هیچگونه IDE ای، اپلت خود را بنویسیم و فایل cap آن را تولید کنیم! منتهی باید با Notepad یا ابزاری مشابه آن، و یک مجموعه ابزارهای خط فرمانی دست و پنجه نرم کنیم، و هیچ گونه هشداری به ما در مورد نوشتن یک اسم API اشتباه یا خطاهای مانند آن به ما داده نمی شود، و تنها در مراحل پایانی، هنگام Compile/Interpret به واسطه ی اجرا نشدن موفق فرایند، متوجه وجود یک خطا در برنامه می‌شویم. کاری که IDE با Plugin هایش برای ما انجام می‌دهد، مکانیزه کردن کل این فرایندها و مخفی کردن ابزارهای خط فرمانی و مراحل آن ها، در پس چند کلیک ساده است. 

Eclipse:

خب، برای شروع، ابتدا Eclipse و سپس Java Card Development Kit 2.2.2 و پلاگین Eclipse-JCDE را دانلود می‌کنیم. 

نکته‌ی مهم اول: Eclipse و Java Development Kit و Java Card Development Kit 2.2.2 و Windows چهار مورد باید یا 32 بیتی باشند یا 64 بیتی. تفاوت یکی از این موارد با موارد دیگر موجب ناسازگاری مجموعه می‌شود و عدم کارکرد صحیح می‌شود.

نکته‌ی مهم دوم: همانطور که پیش‌تر گفته بودیم، پلاگین Eclipse-JCDE تنها برای JCDK2.2.2 نوشته شده است. بنابراین شما باید این نسخه از JCDK را دانلود کنید. (با ترفندی می‌توان از نسخه های پایین تر نیز استفاده کرد؛ لیکن، برای اجرای آن ترفندها، همچنان به نسخه‌ی 2.2.2 نیز نیاز است).

اما بعد؛ پس از دانلود موارد بالا:

1.  ابتدا Java Development Kit را نصب کنید. پس از آن نرم افزار وارد پوشه‌ی Eclipse شوید(این نرم افزار به صورت Portable می‌باشد، یعنی نیاز به نصب ندارد و نهایتا تنها کاری که شما باید در مورد فایل دانلود شده‌ی آن بکنید، Extract کردن آن در یک دایرکتوری است).
2. داخل پوشه‌ی Eclipse یک فولدر به نام plugins وجود دارد، محتویات Eclipse-JCDE (پلاگین دانلود شده) را در این فولدر قرار دهید.
3. JCDK را در یک فولدر Extract کنید. وارد مسیر Extract شوید. داخل این دایرکتوری، چهار فایل فشرده می‌بینید. هر چهار مورد را مجدد Extract کنید (فایل اصلی java_card_kit-2_2_2-rr-bin-windows-do.zip است).
4. حال نرم افزار Eclipse را باز کنید و از منوی Java Card (که به واسطه ی پلاگین دانلود شده به Eclipse اضافه شده است)، گزینه‌ی Preferences را انتخاب کنید. سپس روی Browse کلید کرده و مسیر پوشه ی  java_card_kit-2_2_2-rr-bin-windows-do را به آن بدهید و روی OK کلیک کنید. 

بعد از انجام مراحل بالا، محیط برنامه نویسی Eclipse برای ساخت پروژه های جاواکارت آماده است. برای ایجاد یک پروژه‌ی جاواکارت به این ترتیب عمل می‌کنیم:

1- File > New > Other

2- Java Card > Java Card Project - Next

3- Assigning a name to your project and then click on Finish.

 بعد از کلیک کردن روی دکمه‌ی Finish در منوی سمت راست Eclipse پوشه‌ای با نامی که شما در مرحله‌ی 3 به آن اختصاص دادید ظاهر می‌شود. این پوشه، پوشه‌ی خالی پروژه‌ی شماست:

4- File > New > Other > Java Card Applet

برای افزودن یک اپلت خام(:دی!) به پوشه‌ی پروژه، دو مسیر وجود دارد. راه نخست این که در حالی که پوشه‌ی پروژه انتخاب شده است، مجددا مراحل 1 و 2 را انجام دهیم، با این تفاوت که در مرحله‌ی 2، به جای Java Card Project،  گزینه‌ی Java Card Applet را انتخاب کنیم. مسیر دوم هم به این صورت است که به جای انتخاب کردن پوشه‌ی پروژه و رفتن به File > New، مستقیما روی خود پوشه‌ی پروژه کلید راست کنید و New و ... را پیش بروید. به هر حال از هر دو مسیر، پس از انتخاب Java Card Applet و کلیک روی Next، پنجره ی زیر ظاهر خواهد شد:

5- Assigning Package Name, Applet Name and Applet AID:

در مورد پنجره‌ی فوق چند نکته وجود دارد:

1- بنا بر رسم برنامه نویسی، اسم Package را با حرف کوچک و اسم Applet را با نام بزرگ شروع می‌کنند.

2- چنانچه Package Name را خالی بگذارید، Eclipse به شما هشداری نمی‌دهد، و حتی با کلیک کردن روی Finish، اپلت خام مورد نظر به پروژه اضافه می‌شود (که نام Package آن Default Package شده است)؛ اما، به هنگام ساخت فایل cap. خطایی دریافت می‌کنید که به هیچ وجه از متن آن مشخص نمی‌شود ایراد کجاست! بنابرین برای روبرو نشدن با خطا، حتما به Package یک نام اختصاص دهید.  

3- در این پنجره، تنها AID اپلت از برنامه نویس خواسته می‌شود و AID توسط IDE یک مقدار پیش‌فرض دریافت می‌کنید که در پنجره‌ی بعدی قابل تغییر است.

پس از کلیک کردن روی Finish پنجره ی نهایی که همان محیط برنامه نویسی جاواکارت است مجددا ظاهر می‌شود:

خطایی که مشاهده می‌کنید با پاک کردن override@ از متن برنامه حذف می‌شود. منوهایی که در کادر آبی مشاهده می‌کنید مواردی هستند که به کمک Plugin دانلود شده به Eclipse اضافه شده اند. JCWDE و CREF شبیه سازهای (Simulator) جاواکارت هستند که Oracle آن ها را در بسته‌ی Java Card Development Kit ارائه می‌دهد تا برنامه نویس بتواند بدون نیاز به یک کارت فیزیکی واقعی، برنامه‌ی خود را خطایابی کند. 

نهایتا پس از رفع خطا و ایجاد تغییرات مناسب در برنامه نوبت به ساخت فایل cap. می رسد. برای این کار یا از منوی Java Card در کادر آبی، یا با کلید راست کردن روی نام Package و رفتن به زیر منوی Java Card Tools، گزینه‌ی Convert را انتخاب می‌کنیم تا فایل cap ساخته شود:

6- Assigning Package AID and Generating CAP file:

از آنجا که در مراحل قبلی به Package برنامه AID اختصاص ندادیم، به صورت اتوماتیک یک پنجره باز می‌شود که از ما AID پکیج را می‌گیرد (چنانچه پیش از Convert از Set Package AID استفاده می‌کردیم، دیگر این پنجره ظاهر نمی‌شد). پس از اختصاص Package AID و کلیک روی OK، به احتمال خیلی زیاد، با خطای زیر مواجه خواهید شد:

علت این خطا، تنظیم بودن Compiler جاوا (بله جاوا، نه جاواکارت) در Eclipse روی نسخه‌هایی بالاتر از 1.3 است، برای ساخت فایل‌های cap جاواکارت نسخه‌ی 2.2.2 و قبل تر، کامپایلر جاوا حتما باید روی نسخه‌ی 1.3 (شاید 1.4 هم جوابگو باشد) تنظیم شود. برای تغییر آن، از منوی  Windows بالای پنجره‌ی Eclipse، گزینه‌ی Preferences را انتخاب کنید و سپس در پنجره‌ی باز شده مانند زیر عمل کنید:

حال، مجددا مرحله‌ی 6 را تکرار کنید تا فایل cap به صورت موفق آمیز ساخته شود:

همانطور که مشاهده می‌کنید در کادر سمت چپ، فایل cap ظاهر شده است. شما می‌توانید با کلیک راست کردن روی آن و انتخاب copy، آن را به هر کجای هارد انتقال دهید. همچنین می‌توانید با انتخاب properties، مسیر فعلی آن را مشاهده کنید.

قسمت بعدی: Hello World در جاواکارت

---

آنچه پنهان در میان سینه باشد، عشق نیست

عاشقان با رسم رسوایی به میدان می‌روند

#عارفه_نصیری

رمزنگاری/6-تقسیم‌بندی الگوریتم‌های رمزنگاری

پست قبلی: الگوریتم های سزار و اِنیگما

در پست های قبلی این مجموعه، ابتدا با الگوریتم‌های درهم‌نگاری(Hash) و الگوریتم‌های Encoding/Decoding آشنا شدیم، تفاوت آن‌ها را با الگوریتم های رمزنگاری (Encryption/Decryption) بررسی کردیم و در نهایت پس از بررسی مقدمات توسعه‌ی رمزنگاری و علل نیاز به آن، در این پست قرار است به تقسیم‌بندی های الگورتیم های رمزنگاری امروزی بپردازیم.

واژگان رمزنگاری:

پیش از آن که مشخصا به انواع تقسیم بندی بپردازیم، بد نیست که با یک مجموعه واژگان خاص این حوزه آشنا شویم.

• Plain Text: متن رمز نشده ای که قرار است برای رمزشدن به تابع Encryption وارد شود و همچنین متن رمزنشده ای از تابع Decryption بازگردانده می‌شود.
• Cipher Text: متن رمز شده ای که از تابع Encryption بازگردانده می‌شود و همچنین متن رمزشده ای که برای خارج شدن از رمز به تابع Decryption وارد می‌شود. 
• Cipher: الگوریتمی که برای Encrypt یا Decrypt استفاده می‌شود. با این تعریف، در بعضی موارد از Encipher و Decipher به ترتیب به جای Encoding و Decoding استفاده می‌شود.
• Key: یک اطلاعات محرمانه که فقط و فقط فرستنده و گیرنده‌ی پیام رمز شده از آن اطلاع دارند. Cipher از این کلید، برای انجام عملیات Encrypt و/یا Decrypt استفاده می‌کند.
•  Cryptanalysis: به مطالعات و فعالیت هایی که روی یک الگوریتم رمزنگاری یا داده‌های آن انجام می‌شود تا به واسطه‌ی آنها امکان استخراج کلید رمزنگاری از داده های در دسترس یا امکان استخراج داده‌های رمزنشده بدون داشتن کلید، بررسی شود. نام دیگر این فیلد Codebreaking می‌باشد.
• Salt, Nonce, Initial Vector: در پست‌های بعدی!

و اما تقسیم بندی:

 الگوریتم‌های رمزنگاری را می‌توان از چند بُعد تقسیم‌بندی کرد که مهمترین این ابعاد یکی تعداد کلیدهای لازم برای یکبار رمزکردن و خارج کردن از رمز و دیگری نوع پردازش شدن Plaintext در تابع Encrypt است.  

• تقسیم بر اساس تعداد کلیدهای لازم:

فرایند رمزکردن یک Plaintext و خارج کردن آن از رمز، روندی طبق شکل زیر دارد:

حال، با توجه به ماهیت الگوریتم، ممکن از مقدار  Encryption Key با مقدار Decryption Key برابر باشد یا متفاوت از همدیگر باشند. الگوریتم‌هایی که مقدار این دو کلید با همدیگر یکسان است را Secret Key Algorithm یا Symmetric Algorithm یا Single Key Algorithm یا Conventional Algorithm الگوریتم‌های متقارن می‌نامیم و الگوریتم‌هایی که در آن‌ها مقدار کلیدها از همدیگر متمایز است را Public Key Algorithm یا Asymmetric Algorithm یا Two Key Algorithm یا الگوریتم های نامتقارن می‌نامیم. (از آنجا که روند کار الگوریتم‌های نامتقارن ممکن است [به خاطر تفاوت کلیدها] در ذهن غیرممکن به نظر برسد، در پست‌های بعدی احتمالا نمونه ای از این الگوریتم‌ها را با هم به صورت جزیی‌تر بررسی خواهیم کرد).

• تقسیم‌ بر اساس نوع پردازش Plaintext:

در بعضی از الگوریتم‌های رمزنگاری، طول پیامی که قرار است رمزشود، حتما باید مضرب صحیحی از یک عدد طبیعی خاص بزرگتر از یک باشد. به عنوان مثال طول پیام ورودی باید مضربی از 16 بایت باشد. به این نوع الگوریتم‌های رمزنگاری، Block Cipher می‌گویند و آن عدد طبیعی خاص بزرگتر از یک Block Size نامیده می‌شود. مشخصا هنگامی که قرار است با استفاده از این نوع الگوریتمها پیامی را رمز کنیم که طول آن مضرب صحیحی از طول Block نیست، ناچاریم که تا رسیدن به طول لازم به آن داده اضافه کنیم. مکان و نوع داده‌ای که به پیام اضافه می‌شود می‌تواند دلخواه باشد، لیکن، برای سهولت امر و برای این که گیرنده‌ی Ciphertext بتواند به سادگی پیام را از داده‌ی اضافه شده تمییز دهد، استانداردهای مختلفی ارائه شده است که خود به خود به انتهای پیام، مقداری را اضافه می‌کنند. به عمل اضافه کردن داده‌ به پیام تا رسیدن به طول طول مجاز، Padding می‌گویند. در مقابل این نوع الگوریتم‌ها، نوع دیگری از الگورتیم‌های رمزنگاری را داریم که طول پیام هر‌ مقدار دلخواهی می‌تواند باشد، به این نوع الگوریتم‌ها که در اقلیت هستند، Stream Cipher می‌گویند.

مقایسه الگوریتم‌های متقارن و نامتقارن:

ممکن این سوال برای خواننده پیش بیاید که کاربرد هر کدام از این دو نوع الگوریتم در چه مواقعی است و آیا مزیتی از نظر امنیتی به یکدیگر دارند؟

در پاسخ به این سوال ابتدا روند استفاده از الگوریتم‌های نامتقارن را بررسی می‌کنیم. گفتیم که در الگوریتم های نامتقارن،  Encryption Key  و Decryption Key با هم متفاوتند. نام این کلیدها Public Key و Private Key است. پیامی که با یکی از این دو کلید رمزشود، فقط و فقط با کلید دیگر از رمز خارج می‌شود و استفاده از مقدار دیگری جز کلید دوم، منجر به دریافت داده‌های چرند(:دی!) می‌شود. با توجه به این ساختار، هر موجودیتی باید یک جفت کلید برای خودش تولید کند و یکی را محرمانه نزد خود نگه دارد (Private Key) و دیگری را به شخصی که قصد دارد با اون ارتباط برقرار کند ارسال کند(Public Key). 

برای روشن شدن فرآیند، تصویر زیر را مشاهده کنید:

همانطور که در تصویر فوق می‌بینید، Alice در مرحله‌ی 1، یک جفت کلید تولید می‌کند و در مرحله‌ی 2، کلید عمومی خود را به Bob می‌دهد. سپس در مرحله‌ی 3، یک پیام که با کلید خصوصی خودش رمز شده است به باب ارسال می‌کند. از آنجا که این پیام با کلید خصوصی Alice رمز شده است، فقط و فقط با کلید عمومی او قابل رمزگشایی است[کلید عمومی را هر کسی می‌تواند با درخواست از Alice دریافت کند، بنابرین هر کسی می‌تواند این پیام را رمزگشایی کند]. Bob که کلید عمومی Alice را دارد، پیام او را از رمز خارج می کند، و در جواب به او، مجدد پیام خود را در مرحله‌ی 4 با کلید عمومی Alice رمز می‌کند. بدیهتا، از آنجا که پیام Bob با کلید عمومی Alice رمز شده است، تنها با کلید خصوصی Alice از رمز خارج می‌شود[و از آنجا که Alice کلید خصوصی اش را به هیچ کسی نمی‌دهد، فقط و فقط خودش قادر به رمزگشایی پیام Bob است]. در مرحله‌ی 6 هم Alice پیام Bob را با کلید خصوصی خودش از رمز خارج می‌کند.

دو نکته ای که باید متوجه آن شده باشید:

1. برای این که یک ارتباط دو طرفه‌ی کاملا امن بین Alice و Bob برقرار باشد، Bob هم باید یک جفت کلید تولید کند و کلید عمومی خودش را به Alice بدهد تا Alice به جای استفاده از کلید خصوصی خودش در مرحله‌ی 2، از کلید عمومی Bob استفاده کند(تا هیچکسی جز Bob قادر به رمزگشایی آن نباشد).
2. برخلاف الگوریتم‌های متقارن که در آنها لازم بود گیرنده و فرستنده از قبل به صورت مخفیانه با هم یک کلید را به اشتراک بگذارند، در الگوریتم‌های نامتقارن، برای این که Alice و Bob بتوانند یک پیام محرمانه به همدیگر ارسال کنید، نیازی به اشتراک گذاشتن کلید به صورت مخفیانه نیست، بلکه به صورت کاملا واضح، کلیدهای عمومی خود را به همدیگر ارسال میکنند و کسی با استفاده از آنها نمی‌تواند به داده های رمزشده دست پیدا کند، زیرا در یک ساختار صحیح از Public Key تنها برای رمزکردن (Encrypt) و از Private Key تنها برای رمزگشایی (Decrypt) استفاده می‌شود.

تا اینجای کار، اینطور به نظر می‌رسد که الگوریتم‌های نامتقارن به سبب نکته‌ی 2، از الگوریتم‌های متقارن بهتر اند و باید استفاده از آن‌ها را ترجیح داد. اما نکته‌ی دیگری که وجود دارد بار محاسباتی و زمانی است که پردازنده باید صرف پروسه‌ی تولید کلید، رمزنگاری و رمزگشایی با الگوریتم‌های این دو مجموعه بکند. در عمل، میانگین بار محاسباتی و زمان لازم برای پروسه‌هایی با الگوریتم نامتقارن، بیشتر از پروسه‌های با الگوریتم متقارن است و از این منظر الگوریتم‌های متقارن بر نامتقارن‌ها ارجحیت دارند.

سوال: نهایتا کدام یک استفاده می‌شوند؟

جواب: هر دو! گذشته از این که ممکن است یک سیستم کلا استفاده از یکی را بر دیگری ترجیح دهد، روند متداول این است که ترکیبی از این دو استفاده می‌شود. به این صورت که در ابتدای ارتباط، از طریق الگوریتم‌های نامتقارن یک کلید متقارن(Secret Key) را یکی به دیگری ارسال می‌کند و پس از ارسال این کلید، روند رمزنگاری ارتباط به الگورتیم‌های متقارن Switch می‌کند. در واقع بعد از ارسال کلید متقارن که با رمزنگاری نامتقارن رمز شده است، مابقی ارتباط به صورت متقارن رمز می‌شود.

سوال: آیا صحیح است بگوییم الگوریتم‌های نامتقارن از الگوریتم‌های متقارن امنیت بیشتری دارند؟

جواب: خیر، امنیت یک الگوریتم رمزنگاری را ساختار الگورتیم آن (مشخص کننده ی زمان و تعداد کلیدهایی که باید امتحان شوند تا کلید رمزنگاری بدست آید)، طول کلید آن و نبود خطای منطقی(باگ) در الگوریتم آن تعیین می‌کنند. در واقع در صورتی که در ساختار یک الگوریتم متقارن و یک الگوریتم نامتقارن باگ وجود نداشته باشد، الگوریتمی امنیت بالاتری دارد که طول کلید آن بزرگتر باشد. از نگاه دیگر، همانقدر که محرمانه نگه داشتن Secret Key در الگوریتم متقارن اهمیت دارد، محرمانه نگه داشتن Private Key هم در الگوریتم نامتقارن اهمیت دارد.  در این مورد در پست های بعدی توضیحات کاملتری خواهیم داشت.

اصولی در مورد الگوریتم‌های رمزنگاری:

با گذشت زمان و پیدا شدن نقاط ضعف الگورتیم‌های اولیه، رفته رفته اصولی برای الگوریتم‌های رمزنگاری تدوین شد که در زیر به دو مورد اصلی آن‌ها اشاره می‌کنیم:

1. طول خروجی باید با طول ورودی الگوریتم برابر باشد (بر طبق اصل لانه‌ی کبوتری، خروجی نمی‌تواند از ورودی کوتاه تر باشد. بلندتر بودن خروجی هم مزیتی ندارد و لازم نیست)
2. فاش شدن الگوریتم نباید موجب شود Attacker بتواند داده‌های رمز شده را رمزگشایی کند؛ و به عبارت دیگر باید تنها مبتنی بر محرمانه نگه داشتن کلید باشد. (یکی از اصول کرکهافس).

سوال: Security via Obscurity چیست؟ 

جواب: به مخفی نگه داشتن الگوریتم رمزنگاری به منظور افزایش امنیت (مثلا با کاهش احتمال پیدا شدن ایراد منطقی در الگوریتم)، Security by Obscurity گفته می‌شود.

الگوریتم‌های رمزنگاری مشهور:

در زیر به چند مورد از الگوریتم‌های رمزنگاری متقارن و نامتقارن مشهور اشاره شده است. لازم به ذکر است که کدام از این‌ الگوریتم‌ها می‌توانند بر اساس طول کلید به زیر مجموعه‌هایی تقسیم شوند. به عنوان مثال برای الگوریتم RSA زیر مجموعه های RSA-512, RSA-1024 .... RSA-4096 مرسوم هستند و برای الگوریتم AES سه زیر مجموعه‌ی AES-192, AES-128و AES-256 را داریم (اندازه‌ی بلاک در هر سه مورد 128 بیت است). 

نامتقارن:

• RSA یا Rivest-Shamir-Adleman
• ECC یا Elliptic Curve Cryptography
• DH یا Diffie–Hellman
• ElGamal 

متقارن:

• DES یا Data Encryption Standard
• TDES یا 3DES یا Triple DES
• AES یا Advanced Encryption Standrad

 تا اینجای کار درک مطلوبی از اصطلاحات رمزنگاری و انواع الگوریتم‌ها آن کسب کرده ایم، در قسمت‌های بعدی سعی بر آن است که ابتدا با ماهیت امضای دیجیتال آشنا شویم و به صورت عملی با ابزارهای آنلاین و به صورت آفلاین با Libraryهای موجود داده ها را رمز، رمزگشایی و امضا کنیم.

قسمت بعدی: کاربرد و روند استفاده از امضای دیجیتال (به زودی)

---

بی مهری انسان معاصر در توست

تنهایی انسان نخستین در من ...

#میلاد_عرفان_پور

دنیای من برای دیدنِ دوباره‌ی یه دوست خیلی بزرگ و دست نیافتنی هست ولی برای دیدن دوباره‌ی آدم‌های نچسب، خیلی خیلی کوچیک ...

جاواکارت مقدماتی/7-برنامه نویسی جاواکارت در Netbeans

قسمت قبلی: نسخه‌های جاواکارت و اصطلاحات

در قسمت های پیشین با ساختار کلّی جاواکارت و مفاهیم ابتدایی ضروری آن آشنا شدیم و دانستیم که برای آغاز به نوشتن یک اپلت و تبدیل آن به فایل cap. (فایلی که روی کارت بارگذاری و نصب می‌شود) ابتدا به یک IDE (محیط برنامه نویسی)، یک مجموعه API (واسط‌ های از پیش نوشته شده‌ی JCDK , JDK)، یک ابزار برای بارگذاری و نصب اپلت و نهایتا یک ابزار برای ارتباط با آن نیاز داریم. در این قسمت مراحل نوشتن اپلت و تولید فایل cap. را در محیط Netbeans بررسی می‌کنیم.

Netbeans:

طبق آنچه پیش تر گفته شد، برنامه نویسی برای جاواکارت در محیط Netbeans، برای مواقعی مناسب از که کارت مورد نظر ما از نسخه ی جاواکارت 3.0.1 یا بالاتر پشتیبانی کند. البته لازم به ذکر است که به سبب Backward Compatible بودن استانداردهای جاواکارت، نوشتن اپلت هایی برای کارت های از ورژن پایین تر نیز در محیط Netbeans امکان پذیر است و حتی می‌توان از آنها فایل cap. تولید کرد و در Simulatorهای این IDE آن‌ها را بررسی کرد، لیکن، ورژن فایل نهایی 3.0.1 خواهد بود و قابلیت بارگذاری روی کارت پایین تر را نخواهد داشت. 

و اما روند نوشتن و تولید اپلت:

پس از اجرای Netbeans، از منوی File گزینه‌ی New Project را انتخاب می‌کتیم تا پنجره ی زیر ظاهر شود:

طبق تصویر بالا از سمت چپ گروه Java Card (چنانچه این گزینه را ندارید، باید نسخه‌ی جدیدتری از Netbeans را دریافت کنید یا پلاگین های مربوطه را دانلود و نصب کنید) و از سمت راست نوع پروژه را Classic Applet Project (جهت آشنایی به قبلی آموزش مراجعه کنید) انتخاب می‌کنیم و روی Next کلیک می‌کنیم تا پنجره‌ی زیر ظاهر شود:

در این پنجره و پنجره ی بعدی نام پروژه (نام کلاس اپلت)، نام پکیج اپلت، AID پکیج و AID اپلت را مشخص می‌کنیم. رسم بر این است که نام Package با حروف کوچک و نام Class با حروف بزرگ آغاز شود. همانطور که مشاهده می‌کنید Netbeans به صورت تصادفی یک AID شش بایتی به اپلت اختصاص داده است. فرمت این AID به صورت زیر است:

//aid/<First mandatory 5 bytes>/<Up to 11 bytes optional bytes>

به منظور راحت بودن در به خاطر سپردن AID می‌توانید مقدار دیگری مانند 010203040506 جایگزین آن کنید و پس از آن با کلیک مجدد روی Next به پنجره‌ی اختصاص AID به پکیج اپلت هدایت می‌شوید که فرمت آن به همان صورت AID مربوط به اپلت است. لازم به ذکر نیست که AID پکیج و اپلت باید با هم حداقل در یک "بیت" تفاوت داشته باشند. به صورت معنایی، اختصاص 5 بایت اول یکسان به AID اپلت و پکیج منطقی تر از متفاوت بودن آن‌ها است.

نکته: در میانه‌ی پنجره‌ی فوق دو گزینه‌ی Platforms و Cards به ترتیب نسخه‌های جاواکارت نصب شده روی Netbeans و نوع جاواکارتی که Simulator از آن استفاده می‌کند را مشاهده می‌کنیم. با احتمال بالایی، برای هرکدام تنها همین گزینه‌های مشخص شده را خواهید داشت، بنابرین در مورد آن‌ها بعدا صحبت خواهیم کرد.

پنجره‌ی نهایی که با اختصاص Package AID و کلیک روی Finish به صفحه‌ی نوشتن کد منتقل می‌شویم:

پس از کلیک روی دکمه‌ی Finish، نرم افزار Netbeans به صورت اتوماتیک سورس-کدِ ساده‌ترین اپلتِ ممکن را در اختیار شما قرار می‌دهد تا با ایجاد تغییر و توسعه‌ی آن، به صورت ساده تر اپلت مورد نظر خود را تولید کنید [سورس کد تولید شده توسط Netbeans تنها چهارچوب کلی است و هیچ فعالیتی انجام نمی‌دهد]. در مورد ساختار این سورس-کد و نحوه‌ی توسعه‌ی آن در پست های بعدی توضیحاتی داده خواهد شد، اما انتظار می‌رود خواننده خودش با مراجعه به سند Java Card API Specification دانش لازم را کسب کند.

پس از ایجاد تغییرات لازم، با استفاده از ابزارهای مشخص شده که معادل هر کدام از آنها در تَب  Run وجود دارد پروژه ی نوشته شده را Build می‌کنیم و در صورتی که قصد استفاده از Simulator را داشته باشیم با کلید روی مثلث سبز رنگ اپلت را اجرا می‌کنیم.

همانگونه که در تصویر بالا مشاهده می‌کنید، پس از کلید روی Build (چکش)، IDE با پیام BUILD SUCCESSFUL ما را از ساخت موفقیت آمیز فایل cap. آگاه می‌کند. چنانچه در کد برنامه خطایی وجود داشته باشد، عملیات Build با شکست مواجه می‌شود، ولی ساخت موفقیت آمیز فایل cap. نه به معنای این است که اپلت روی کارت به درستی کار خواهد کرد و نه حتی به معنای این است که اپلت روی کارت باگذاری و نصب خواهد شد! (در آینده با مثال هایی از هر دو مورد روبرو خواهیم شد).

قابل ذکر است که فایل cap. تولید شده، درون دایرکتوری ای با مسیر زیر قرار می‌گیرد:

Documents\NetBeansProjects\<YourProjectName>\dist\*.cap

قسمت بعدی: برنامه نویسی جاواکارت در Eclipse

---

آسمانی‌تر از آنی که کنارت باشم

حفظ کن فاصله را تا به تو عادت نکنم ...
#صنم_نافع