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

بنام خدا

سلام.

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

خوشحال می شیم.

کاظم و بات‌ها

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

جاواکارت مقدماتی/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

---

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

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

اولین حرکتِ جدی روی دیوار

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

برای شروعِ کار، ابتدا همه‌ی کوکی‌های خود را که روی دیوار هستند پاک می‌کنیم.

رمزنگاری/5-الگوریتم های Caesar و Enigma (سِزار و اِنیگما)

قسمت قبلی: معیارهای امنیت

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

الگوریتم سزار:

"باب" جلسه ای دو نفره و محرمانه با "آلیس" تشکیل داد و با او در مورد نحوه‌ی ارسال نامه ها مشورت کرد. چیزی که در ابتدا باب می‌خواست این بود که هیچ کسی جز آلیس قادر به فهمیدن محتوای نامه و دستورات نباشد. در این جلسه تصمیم باب و آلیس بر این شد که در متن نامه به جای هر حرف، حرف سه جایگاه قبل تر را جایگزین کنند. به این صورت که به جای A حرف X، به جای B حرف Y و ... 

با روند فوق که در اصل یک نوع انکدینگ به حساب می‌آید (زیرا به نوعی فرمت حروف عوض شده است، و در صورتی که الگوریتم فاش شود، چیزی به عنوان کلید لازم نداریم و هر کسی می‌تواند داده ها را به حالت اولیه بازگرداند) به ظاهر محرمانگی نامه‌های تبادلی تضمین می‌شود، اما چیزی که بعدها باب و آلیس کشف کردند این بود که در نامه هایی نهایی درصد تکرار حروف می‌تواند باعث فاش شدن متن اصلی شود. یعنی از آنجا که پر تکرار ترین حرف انگلیسی E است، در نامه های رمز شده، پرتکرارترین حرف را اگر با E جایگزین کنیم، به متن اصلی نزدیک می‌شویم. به همین ترتیب تک حروف های منفرد، به احتمال زیاد یا I هستند یا A.  این قبیل نتیجه گیری ها که همگی به علت یکسان نبودن احتمال ظاهر شدن حروف مختلف در خروجی نهایی نامه هاست، به سادگی می‌توانست موجب رمزگشایی نامه‌ها شود و بنابرین آلیس و باب باید به دنبال راهکار دیگری می‌بودند ...

[پایان داستان باب و آلیس!!!/به علت زیاد بودن مطالب]

شکل: نسبت تکرار حروف مختلف در یک متن انگلیسی

نکته: در دنیای رمزنگاری، الگوریتم فوق به نام الگوریتم سزار معروف است، زیرا برای اولین بار ژولیوس سزار پادشاه رومی برای ارتباط با فرماندهانش استفاده شد. از نام های دیگر آن می‌توان به Shift Cipher، Caesar Code و Caesar shift اشاره کرد.

ماشین Enigma:

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

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

قسمت بعدی: بررسی تقسیم بندی الگوریتم‌های رمزنگاری

---

دیدار تو گر صبح ابد هم دَهَدَم دست

من سرخوشم از لذتِِ این چشم به راهی ...

#فریدون_مشیری

جاواکارت-مقدماتی/6-نسخه‌های جاواکارت و اصطلاحات

قسمت قبلی:  ابزارهای مورد نیازقسمت قبلی:  ابزارهای مورد نیاز

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

نسخه‌های جاواکارت:

همانطور که پیش‌تر اشاره شد، مستندات استاندارد JavaCard در دهه‌ی 1990 میلادی توسط موسسه‌ی Sun [که بعدها به Oracle واگذار شد] برای سهولت برنامه‌نویسی کارت های هوشمند و همچنین ایجاد قابلیت Portability (نصب اپلت نوشت شده برای کارت های تولید سازنده‌ی A، روی کارت‌های تولید شده توسط سازنده‌ی B، بدون ایجاد تغییر و مواجه شدن با خطا) ارائه شد. در آن زمان، موسسه‌ی Sun/Oracle برای این که بتوانند یک استاندارد قابل پیاده‌سازی ارائه دهند، باید توانایی مدارات الکترونیکی آن زمان را در نظر می‌گرفتند و با توجه به آن، قابلیت های ضروری را در استاندارد خود قرار می‌دادند. پس از گذشت چند سال از ارائه‌ی نسخه‌ی اولیه‌ی استاندارد JavaCard، با پیشرفت علم الکترونیک، توانایی بردهای الکترونیکی از قبیل ظرفیت حافظه‌های مختلف مانا و گذرا در همان مقیاس قبلی، و توانایی پردازنده برای انجام پردازش در همان زمان قبلی، افزایش چشم گیری یافت و با توجه به آن، استانداردهای Javacard 2.1.1، Javacard 2.1.2، Javacard 2.2.1 و در نهایت  Javacard 2.2.2 در پی یکدیگر با حفظ کلیّت استاندارد نسخه‌ی قبلی و صرفا با افزودن یک سری قابلیت و توانایی جدید نسبت به نسخه‌ی پیشین خود، ارائه شدند (مثلا الگوریتم‌‎های رمزنگاری قوی‌تر اضافه شدند). تا اینجای کار، نفس ارتباط بین کارت و کارتخوان در تمام نسخه‌ها یکسان بود، یعنی دستورات در رشته‌هایی از اعداد هگزادسیمال به نام APDU Command به یک اپلت روی کارت ارسال می‌شدند و در پاسخ هم یک رشته از اعداد هگزادسیمال تحت عنوان APDU Response از اپلت به کاربر باز می‌گشت.

اما، در سال‌های اخیر با توجه به رشد بیشتر توانایی‌های قطعات الکترونیکی، Oracle تصمیم گرفت که این روندِ استانداردهای اپلت محورِ خود را ]که ارتباط با آن‌ها مستلزم فهمیدن عناصری به نام APDU Command و APDU Response  است[ به گونه ای جدید تغییر دهد که قابل فهم تر و مرسوم تر باشد. جایگزینی که برای شیوه‌ی ارتباطی قبلی ارائه شد، پَکِت‌های HTTP/HTTPS بودند؛ یعنی Oracle تصمیم گرفت استانداردی معرفی کند که کارت‌های منطبق با آن، عملا به یک WebServer  تبدیل شوند و از طریق پکت‌های HTTP/HTTPS با دنیای خارج ارتباط برقرار کنند. از آنجا که این نسخه از استانداردها با نسخه‌های پیشین تفاوت چشم‌گیری داشتند، شماره گذاری آنها را از 3.0.1 آغاز کرد و اولین نسخه‌ی آن را Javacard Platform 3.0.1 Connected Edition  نامید.

اما Connected Edition  به چه معناست؟

پاسخ: از آنجا قرار بر این نبود که با ظهور این نوع کارت‌های جدید، Oracle روند توسعه‌ی استاندارد کارت‌های قبلی را تعطیل کند، پس تصمیم گرفت که برای هر دو نوع کارت استانداردهای جداگانه‌ای به صورت موازی توسعه دهد و ارائه کند؛ و برای این که بتوان آن‌ها را از هم تشخیص داد، دو واژه ی Connected Edition و Classic Edition را استفاده کرد. Connected Edition  استاندارد مربوط به کارت‌هایی است که قابلیت تبدیل شدن به Web Server  و ارتباط HTTP/HTTPS را دارند و Classic Edition  استاندارد کارت‌هایی است که در ادامه‌ی روند توسعه ی  استاندارد Javacard 2.2.2 ارائه شده اند.

لازم به ذکر است که استانداردهای مختلف جاواکارت Backward Compatible  هستند. بدین معنا که، اپلت هایی که برای یک نسخه نوشته شده اند، روی کارت‌های همان نسخه و نسخه‌های بالاتر نصب می‌شوند.

اصطلاحات این حوزه:

ATR یا Answer To Reset:

در بخش استانداردها گفتیم که ویژگی‌های الکتریکی خط ارتباطی کارت‌های تماسی و کارتخوان مربوطه در جلد سومِ استاندارد ISO/IEC 7816 تعریف شده اند. این استاندارد برای تولیدکنندگان کارت‌های هوشمند آزادی عمل زیادی در نظر گرفته است. به عنوان مثال، سه سطح ولتاژ مختلف 1.8 ولت، 3 ولت و 5 ولت را به عنوان ولتاژهای معتبر کارکردی کارت در نظر گرفته است و به تولید کننده اجازه داده است که یکی از این موارد یا یک زیرمجموعه از آن را برای کارت خود استفاده کند. همچنین به سازنده اجازه داده است که پروتکل ارتباطی را T=0 یا T=1 یا هر دو انتخاب کند و قسّ علی هذا! در مقابل هنگام آغاز ارتباط کارتخوان و کارت، کارت باید به نحوی کارتخوان را از این انتخاب‌های خود آگاه کند. آنچه که این اطلاعات را در بر دارد ATR نامیده می‌شود. و عملکرد آن به این صورت است که بلافاصله پس از اتصال کارت به کارتخوان (به عبارت دیگر، بلافاصله پس از اتصال خطوط تغذیه‌ی کارت) یک رشته از اعداد که حاوی این اطلاعات است، از کارت به کارتخوان ارسال می‌شود. لازم به ذکر است که ارسال ATR از کارت به کارتخوان می‌تواند با خروج و ورود کارت از/به کارتخوان انجام شود که در این صورت Cold Reset ATR نامیده می‌شود و یا می‌تواند با ارسال دستور RESET از رایانه به کارت‌خوان انجام شود که در این صورت Warm Reset ATR نامیده می‌شود. مقادیر این دو ATR می‌تواند یکسان و یا متفاوت از باشد. هر چند که ATR یک جزء اجباری برای کارت است که باید حتما توسط سازنده به فرمت خاصی پیاده سازی شود، اما یک بخش Optional در آن وجود دارد که Historical Bytes نامیده می‌شود. سازنده می‌تواند در این بخش اطلاعاتی از خود یا کارت به صورت دلخواه قرار دهد. 

ATS یا Answer To Reset:

تقریبا مشابه ATR است، با این تفاوت که خاصِ کارت‌های غیر تماسی است و در استاندارد ISO/IEC 14443 فرمت و مقادیر آن تعریف شده است.

SD یا Security Domain و CM یا Card Manager:

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

AID یا Application Identifier:

همانطور که فایل‌ها و دایرکتوری های روی کامپیوتر دارای یک نام هستند که متشکل از حروف و اعداد و کاراکترهای خاص است، اپلت‌ها و پکیج‌های روی کارت هم دارای یک نام می‌باشند که تنها شامل اعداد است. طول این عدد باید بین 5 تا 16 بایت باشد. یعنی این که ما برای پکیج یک AID پنج تا شانزده بایتی و برای هرکدام از اپلت یا اپلت‌های درون آن نیز یک AID پنج تا شانزده بایتی خواهیم داشت. (همه‎ی اپلت‌هایی که می‌نویسیم و روی کارت بارگذاری و نصب می‌کنیم، درون یک پکیج خاص آن اپلت قرار می‌گیرند- بعدها این موضوع روشن تر خواهد شد). لازم به ذکر است که نام همه‌ی پکیج‌ها و اپلت‌های روی یک کارت باید منحصر به فرد باشد. همچنین بد نیست بدانیم که چنانچه یک برنامه نویس/شرکت بخواهد اپلت‌هایی بنویسد که به صورت بین المللی استفاده شوند، باید در مورد AID پکیج‌ها و اپلت‌هایش قوانینی را رعایت کند که با پکیج‌ها و اپلت‌های دیگر شرکت‌ها تداخل نداشت باشند (دارای AID یکسان نباشند). قوانین مزبور به این صورت است که توسط سازمان ISO یک رشته‌ی 5 بایتی منحصربفرد به آن شرکت اختصاص داده می‌شود و این شرکت موظف است که AID پکیج‌ها و اپلت‌های خود را با این 5 بایت آغاز کند.

RID یا Registered application provider Identifier و PIX یا  Proprietary Identifier eXtention:

گفتیم که هر اپلت یا پکیج روی کارت دارای یک شناسه‌ی حداقل 5 بایتی و حداکثر 16 بایتی منحصربفرد است. و گفتیم چنانچه شرکتی بخواهد یک اپلت با استفاده‌ی بین المللی بنویسد، باید از سازمان ISO یک رشته‌ی 5 بایتی منحصر به خود درخواست کند. آن حداقل 5 بایت ابتدای AID که همین 5 بایت دریافتی از ISO است را RID و آن 11 بایت Optional را PIX می‌نامند. بنابراین:

AID = RID [+ PIX ] 

* از آنجا که ما [فعلا] برنامه‌ای برای نوشتن اپلت‌های جهانی نداریم، در اپلت‌های خود، AID را کاملا دلخواه انتخاب خواهیم کرد.

APDU یا Application Protocol Data Unit:

در یک شبکه‌ی کامپیوتر، داده ها برای انتقال از یک رایانه به یک رایانه‌ی دیگر، با فرمت خاصی، در بسته هایی با نام Packet و سپس Frame قرار می‌گیرند و ارسال می‌شوند. در ارتباط بین یک کارت و کارتخوان هم دستوراتی/داده‌هایی که از کارتخوان به کارت ارسال می‌شوند و همچنین پاسخ‌ها/داده‌هایی که از کارت به کارتخوان ارسال می‌شوند، با فرمت مخصوصی در بسته‌هایی با عنوان APDU تبادل می‌شوند. آنچه از کارتخوان به کارت ارسال می‌شود APDU Command و آنچه از کارت به کارتخوان ارسال می‌شود APDU Response نامیده می‌شود. APDU Command با توجه به آنچه که قرار است در بر داشته باشد به چهار نوع مختلف تقسیم بندی می‌شود که Case 1 تا  Case 4 نامگذاری شده اند. APDU Response هم شامل یک بخش اجباری دو بایتی به نام Status Word و یک بخش Data با طول نامحدود است. در پست‌های بعدی به صورت جزئی تر با این ساختار آشنا خواهیم شد.

قسمت بعدی: کدنویسی JavaCard در محیط Netbeans

---

داره بارون میاد ...

رمزنگاری/4-معیارهای امنیت

قسمت قبلی: مشکلات مربوط به Encoding

تا پیش از این با Hash کردن و Encoding و Decoding آشنا شدیم و دانستیم که Hashing استفاده از تابعی است که یک طرفه می‌باشد و پس از Hash کردن داده ها قابلیت بازیابی مجدد آن‌ها را نداریم، و در مقابل دانستیم که Encoding و Decoding تابع هایی دو طرفه برای تغییر Form داده ها هستند؛ که برای استفاده از آن‌ها نیاز به چیزی تحت عنوان کلید یا رمز نیست و هر فردی که از الگوریتم مطلع باشد می‌تواند داده های Encode شده را با استفاده از تابع Decode به داده های اصلی تبدیل کند.(لازم به ذکر است که ماهیت Public بودن قریب به اتفاق الگوریتم های Encoding/Decoding باعث می‌شود همه بتوانند از آن‌ها استفاده کنند).

معیارهای امنیت:

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

در این سناریو شما فرمانده ی یک سپاه جنگی هستید و به سبب لزوم نظارت بر اتفاقات خط نبردِ نیروهایتان و نیز مدیریت کارهای مملکتی، ناچارید که مدام بین میدان کارزار و مقرّ فرماندهی آمد و شد کنید(بگذارید حداقل در این داستان سناریو را طوری تعریف کنیم که گویا نعلین فرماندهان نیز گَرد خطوط نبرد را به شیارهای خود دیده است!). بنابرین شما نیاز دارید که گاهی از این مقر، به یکی از سربازان عالی‌رتبه‌ی خود که وِی را به عنوان جانشین بر مسند فرماندهی گمارده‌اید نامه ای ارسال کنید و او را در جریان کارهایی که باید انجام دهد قرار دهید. همچنین، فرمانده ی مذکور، باید گزارشاتی از عملکرد خودش و اوضاع به شما ارسال کند. پیش از این که ادامه‌ی داستان را تعریف کنیم، یک نام برای شما، و یک نام برای آن افسر عالی‌رتبه انتخاب می‌کنیم. نام شما Bob است، و نام آن افسر Alice (چرا تعجب کردید؟ یک افسر عالی‌رتبه نمی‌تواند خانم باشد؟).

سوال: چرا Bob و چرا Alice؟ 

پاسخ: آلیس و باب در واقع دو عضو از یک خانواده‌ی بزرگ هستند تحت عنوان خانواده‌ی کاراکترهای رمزنگاری! به صورت واضح تر، در سال 1978 یکی از اساتید دانشگاه MIT به نام رونالد ریوست، در مقاله ای که برای ارائه‌ی الگوریتم رمزنگاری RSA آماده کرده بود، از این اسامی برای مثال‌های خود به عنوان فرستنده و گیرنده‌ی پیام استفاده کرد. بعدها در دیگر سناریوهایی که طراحی شد، این اسامی شهرت یافتند و کم کم کاراکترهای دیگری هم به جمع آن‌ها پیوستند. برای رعایت این رسم، ما نیز در سناریوی خود همین کاراکترها را به کار می‌بریم. به عنوان یک مطلب اضافه، حرف R در الگوریتم RSA، از فامیل آقای Rivest گرفته شده است. دو حرف دیگر هم از نام دو طرِاح دیگر الگوریتم آمده اند.

دکتر ریوست (نفر وسط)

خب، تصمیم باب بر این شده است که در یک نامه، دستورات خود را به آلیس عزیزش در میدان نبرد ابلاغ کند.

اما بیایید پیش از آنکه اتفاقات و راهکارهایی که "باب" و "آلیس" استفاده کردند را بیان کنیم، خودمان بررسی کنیم و ببینیم که چه مسائلی باید در نظر می‌گرفتند؟ [بعدها خواهیم دید این مسائل مبنای امنیت یک خط ارتباطی را تشکیل می‌دهند]:

1. "باب" و "آلیس" باید به نحوی در نامه هایشان، خود را به گونه‌ای به یکدیگر معرفی کنند که هر کدام هنگام دریافت نامه‌ی دیگری بتواند مطمئن شود که نامه از جانب همان شخصی آمده است که باید بیاید. حتی در صورتی که نیروهای دشمن رونوشتی را که هفته‌ی پیش در کاروان‌سرای بین راه از نامه‌ی قاصد تهیه کردند جایگزین نامه‌ی امروز قاصد کنند، دریافت کننده باید متوجه معتبر نبودن آن بشود. [بعد ها این بند را با نام Authenticity خواهید شناخت]
2. در صورتی که نیروهای دشمن در میانه‌ی مسیر قاصد را تطمیع کردند یا به قتل رساندند و به دستوراتِ "باب" یا گزارشِ "آلیس" دست یافتند، نباید از آن چیزی متوجه شوند! [بعد ها این بند را با نام Confidentiality خواهید شناخت]
3. در صورتی که نیروهای دشمن در کاروان سراهای میان راه کمین کردند و نامه‌ اصلیِ قاصد را دزدیدند و محتوای آن را عوض کردند یا نامه‌ی جدیدی که خودشان نوشته اند جایگزین آن کردند، دریافت کننده‌ی نامه‌ی جدید باید متوجه جعلی بودن آن بشود. [بعد ها این بند را با نام Integrity خواهید شناخت]
4. چنانچه "باب" دستوری به آلیس فرستاد و مثلا به وی فرمانِ "حمله" داد و آلیس بعد از خواندن دستور، به خاطر ترس یا ... به آن عمل نکرد، بعدها نباید بتواند ادعا کند که نامه را دریافت نکرده است! همینطور اگر "باب" در موقیعت مشابهی، مثلا در حالت مستی، تصمیم اشتباهی گرفت و فرمانی صادر کرد و به آلیس فرستاد و اجرای آن تصمیمِ اشتباه منجر به اتفاق بدی شد که آبروی "باب" را به خطر می‌انداخت، وی نباید قادر به این باشد که ارسال آن دستور را انکار کند. [بعد ها این بند را با نام Non-Repdiation خواهید شناخت]
5. قاصد و اسب پر انرژی اش همیشه باید در دسترس "باب" و آلیس باشد. [بعد ها این بند را با نام Availability خواهید شناخت]

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

قسمت بعدی: الگوریتم‌های سزار/Caesar و اِنیگما/Enigma

---

To be yourself in a world that is constantly trying to make you something else is the greatest accomplishment.

Ralph Waldo Emerson