جاواکارت مقدماتی/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-نسخه‌های جاواکارت و اصطلاحات

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

در پست قبلی اشاره کردیم که انتخاب ابزار کار مورد نیاز (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-من یک جاواکار نیستم!

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

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

 

زبان‌های برنامه نویسی Cross Platform:

چنانچه از قبل آشنایی اندکی با یک زبان برنامه نویسی Cross-Platform (همان Multi Platform - همان Platform Independent) داشته باشید، باید عرض کنیم که زبان های جاوا و جاواکارت هم مانند پایتون سیاست تقریبا مشابهی را دنبال می‌کنند و جزو زبان های کراس پلتفرم به حساب می‌آیند. "کراس پلتفرم" بدین معناست که برنامه نویس فقط یکبار و برای همیشه برنامه‌ی خود را می‌نویسد و همان برنامه را بدون تغییر روی سیستم عامل‌ها و دستگاه های مختلف اجرا می‌کند. به صورت ملموس تر، برنامه نویس برنامه خود را به عنوان مثال روی سیستم عامل لینوکس می‌نویسد و یک فایل از آن می سازد، آنگاه همان فایل بدون تغییر کد، در لینوکس، ویندوز و سیستم عامل MAC اجرا می‌شود.

اما چگونه؟

در پاسخ به این سوال، ابتدا علّت این که برنامه های زبان هایی مانند C و ++C و سایر زبان های Native Platform(نقطه ی مقابل Cross Platform) باید برای هر سیستم عامل به صورت جداگانه Compile شوند را بیان می‌کنیم. علت این امر به صورت ساده این است که برنامه های نوشته شده به این زبان ها برای اجرا  روی سیستم عامل یک مرحله را طی می‌کنند و بعد به صورت مستقیم با سیستم عاملی که روی آن در حال اجرا می باشند تعامل می‌کنند و از آنجا که سیستم عامل های مختلف واسط های تعاملی و به بیان ساده تر زبان گویش تعاملی متفاوتی دارند، برنامه ای که برای گفتگو با یک سیستم عامل Compile(بخوانید "ساخته") شده است، قادر به صحبت با یک سیستم عامل دیگر نیست و باید مجددا به گونه ای که زبان سیستم عامل جدید را بفهمد Compile شوند. 

خب، در مقابل برنامه های زبان های Cross Platfrom چگونه اند؟ 

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

تصاویر زیر به روشنی نقش Virtual Machineرا در اجرای یک برنامه مشخص می‌کند: 

 

با توجه به تصاویر بالا، برنامه نویس‌های زبان های Cross Platform و Platform Dependent هر دو، برنامه های خود را یک بار می‌نویسند، ولیکن برنامه نویس زبان های Platform Dependent چند بار از آن فایل اجرایی می‌سازد. (در مواقع فراخوانی بعضی توابع سیستمی، هر دو گروه ناگزیر از ایجاد تغییراتی در کد برنامه ی خود نیز می باشند؛ هرچند با در نظر گرفتن بعضی نکات حین نوشتن برنامه می‌توانند، برنامه را از تغییر بی نیاز کنند.)

حال که با سیستم زبان های Cross Platform آشنا شدیم می‌توانیم علت انتخاب یک عضو از خانواده ی جاوا به عنوان زبان برنامه نویسی کارت های هوشند را بیان کنیم.

تاثیرات انتخاب جاواکارت به عنوان زبان برنامه نویسی کارت های هوشمند:

پیش از ارائه‌ی جاواکارت توسط شرکت Sun، تولیدکنندگان مختلف کارت های هوشمند هر کدام به صورت سلیقه ای استانداردی ارائه کرده بودند که منحصرا در اختیار افراد خاصی قرار می‌گرفت و برای یک برنامه نویس عادی، اولا در دسترسی نبود، و ثانیا به خاطر تعدد استانداردها یادگرفتن آن ها قابل پذیرش نبود. علاوه بر آن برنامه هایی که برای یک نوع کارت نوشته می‌شد، در صورت تمایل به ارتقای کارت یا تعویض کارت، دیگر قابل استفاده نبود و در اصطلاح Portability کافی نداشتند. با ظهور جاواکارت و پذیرش سازندگان مختلف به استفاده از این استاندارد و قرار دادن ماشین مجازی جاواکارت در کارت های خود، همه ی مشکلات فوق از بین رفتند و راه برای توسعه دهندگان نرم افزارهای کارت های جاواکارت یا همان توسعه دهندگان Appletها هموار شد. 

و اما:

قسمت 4: من یک جاواکار نیستم!

به عنوان یک مقدمه، روند نوشتن یک برنامه‌ی جاوا و سپس روند نوشتن یک برنامه‌ی جاواکارت را توضیح می‌دهیم، و از آن پس از شما انتظار می‌رود در خلال این مجموعه آموزش ها، به صورت Self-Study جاوا را بیاموزید.

برای نوشتن یک برنامه ی جاوا شما به یک IDE (= محیط برنامه نویسی =  Integrated Development Environment) مانند Eclipse یا Netbeans یا IntelliJ یا ... و همچنین به Java Development Kit نیاز دارید. 

سوال: Java Development Kit یا JDK چیست؟

جواب: گفتیم در زبان های برنامه نویسی Cross Platform یک ماشین مجازی وجود دارد که برنامه را از کاربر دریافت می کند و برای سیستم عامل ترجمه می‌کند. به صورت پیشفرض روی یک سیستم عامل نه آن Virtual Machine وجود دارد و نه ابزارهای لازم برای ساخت فایل ورودی آن ماشین مجازی. پس برنامه نویس باید هر دو دسته ابزار را به کامپیوتر خود اضافه کند. مجموعه ی ابزارهای مورد نیاز برای ساخت فایل و همچنین اجرای فایل های زبان جاوا، در یک مجموعه جمع آوری شده اند و نام آن مجموعه Java Development Kit است. شما می توانید با مراجعه به سایت Oracle این بسته را دانلود کنید(نیاز به فــــــــــیل‌ترشکن :دی). هنگام مراجعه به این سایت در کنار نسخه های مختلف JDK به بسته هایی با نام JRE نیز بر‌خواهید خورد. JRE یا Java Runtime Environment در واقع تنها قسمت دوم ماجرا می باشند! یعنی ابزارهای مورد نیاز برای اجرای فایل های جاوا! به بیان ساده تر JRE شامل JVM و یک سری ابزارهای خردِ دیگر است و به کاربران تنها اجازه ی اجرای فایل های جاوا را می‌دهد. برای درک نسبت JVM و JRE و JDK تصویر زیر را مشاهده کنید:

خیلی خب، پس از دانلود JDK و افزودن آن به IDE خود (IDEهای جدید به صورت خودکار این کار را برای شما انجام می‌دهند) شروع به برنامه نویسی می‌کنید. برنامه ای که نوشتید توسط IDE در ابتدا درون یک فایل با پسوند java. قرار می‌گیرد، و سپس با کلیک کردن روی یک دکمه، به صورت اتوماتیک به فایل class. و سپس به jar. تبدیل می‌شود و این فایل jar. فایلی است که هنگام کلیک شدن روی آن توسط کاربر، سیستم عامل آن را  به عنوان ورودی به JVM ارسال می‌کند.

سوال: روند نوشتن یک برنامه ی "جاواکارت" چگونه است؟

جواب: روند تقریبا مشابهی برای نوشتن برنامه های جاواکارت (یا همان اپلت ها) طی می‌شود. همانگونه که برای نوشتن یک برنامه ی جاوا به JDK نیاز داشتیم، برای نوشتن یه برنامه‌ی جاواکارت هم به JCDK یا همان Java Card Development Kit نیاز داریم (علاوه بر JDK). پس با مراجعه ی مجدد به سایت Oracle یک نسخه از JCDK را دانلود می‌کنیم. در حین انتخاب نسخه ی دلخواهمان باید این را در نظر داشته باشیم که برنامه های ساخته شده با یک ورژن، تنها روی کارت هایی که آن نسخه را پشتیبانی می‌کنند یا کارت هایی که نسخه های بالاتر را پشتیبانی می‌کنند قابل اجرا است.(جمله دوم معادل کلمه ی Backward Compatible می باشد. یعنی یک نسخه، برنامه های نسخه های قبلی را نیز اجرا می کند). پس از دانلود باید محتویات فایل فشرده را Extract کنیم و مسیر آن ها را به IDE  خود بدهیم. بعدتر خواهیم دید که Eclipse به صورت پیشفرض جایی برای دریافت آدرس JCDK ندارد. و بعدتر-تر خواهیم دید که با افزودن یک پلاگین به آن می‌توانیم این قابلیت را به آن اضافه کنیم. بعدتر ها باز خواهیم دید که:

• پلاگین مذکور به صورت عادی فقط برای JCDK 2.2.2 طراحی شده است.
• می‌توانیم با یک ترفند نسخه های قدیمی تر یعنی JCDK 2.2.1، JCDK 2.1.2 و JCDK 2.1.1 را نیز به کمک این Plugin استفاده کنیم.
• نسخه های جدید نرم افزار Netbeans به صورت پیشفرض به JCDK 3.0.1 مجهز شده اند.

خب، بعد از مجهز شدن IDE دلخواه خود به نسخه ی JCDK مورد نظرمان، نوبت به برنامه نویسی می‌رسد. پس از نوشتن یک اپلت (که در پست های بعدی قدم به قدم آن را توضیح می‌دهیم) IDE مشابه قبل یک فایل java. تولید می‌کند که با چند کلیک این فایل ابتدا به class. و سپس به cap. (به جای jar.)  تبدیل می‌شود. تبدیل فایل java. به فایل class. را ابزارهای جاوا و تبدیل فایل class. به cap. را یکی از ابزارهای جاواکارت به نام Converter انجام می‌دهند. فایل cap. تولید شده، فایلی است که ما روی کارت بارگذاری و نصب می‌کنیم. در آینده به صورت جزئی تر با نقش Converter و سایر ابزارها آشنا خواهیم شد.

قسمت بعدی: سخت افزارها و نرم افزارهای مورد نیاز

---

کوچ تا چند؟ مگر می‌شود از خویش گریخت؟

بال تنها غم غربت به پرستوها داد ....

جاواکارت-مقدماتی/2-استانداردها + ساده سازی

قسمت قبلی: مقدمه

استانداردها:

اما بعد! :دی 

معرفی استانداردها!

ما به صورت نا متناهی استاندارد داریم توی حوزه ی کارت های هوشمند و خصوصا سیمکارت ها. این استانداردها به سه دسته تقسیم میشن با اغماض:

1. استانداردهایی که میان کانال ارتباطی رو از لحاظ فیزیکی بررسی میکنند که مثلا ولتاژ پایه ها باید اینقدر باشه و کلاک باید فرکانسش این باشه و .... یا فرکانس امواج الکترومغاطیسی برای کارت های غیرتماسی و .... ---> مهمترینش : ISO 7816 Part 3  برای کارت های تماسی و ISO 14443 برای کارت های غیرتماسی
2. استانداردهایی که میگن مدیریت داخلی کارت باید به چه صورت باشه، مثلا حذف و نصب و تغییر کلیدرمزنگاری و ... به چه صورت هستش. ---> مهم ترینش : Global Platform برای هر دو نوع کارت های تماسی و غیر تماسی
3.  استانداردهایی که (در واقع Specificationهایی که) APIهای جاواکارت، ویژگی های ویرچوآل ماشین جاواکارت و ویژگی های ران-تایم اِنویرومنت جاواکارت رو ارائه میدن. --> JCAPI Spec / JCRE Spec / JCVM Spec

سوال: جاواکارت با جاوا کارت فرق داره؟ :دی 

جواب: بله! جاواکارت زبون برنامه نویسی کارت هایی هستش که زبان "جاواکارت" رو ساپورت میکنند! و "جاوا کارت" همون کارت ها هستند. البته این نکته ای نیست که کسی رعایتش کنه، چیزی که باید مد نظرت باشه اینه که جاواکارت یه زبونه. :)

سوال: زبان های جاوا با جاواکارت خیلی تفاوت دارند؟ 

 جواب: هم بله هم خیر! خیر از این لحاظ که بالاخره ساختار زبان ها با هم یکی هستش و کسی که جاوا بلده، با یکم تقلا برنامه های زبان جاواکارت رو هم میفهمه. بله از این لحاظ که زبان جاواکارت به دو دلیل با جاوا تفاوت داره. دلیل اول این که قدرت سخت افزاری کارت ها با قدرت سخت افزار سیستم های معمولی قابل مقایسه نیست و بنابرین یه سری قابلیت ها از زبان جاوا حذف شده. مثلا جاواکارت ها فقط متغیر های نوع Byte و Short دارند (و int به صورت آپشنال)، در حالی که جاوا مغیرهای با سایز بزرگتر هم پشتیبانی میکنه. یا مثلا Clone کردن و ... از جاوا داخل جاواکارت نیستند. دلیل دوم هم این که به خاطر این که داخل کارت ما با حافظه ی  EEPROM و RAM به صورت غیر مستقیم سر و کار داریم و سرعت عملیات ها برامون مهمه، باید بتونیم حالت efficient بین تعریف کردن یه متغیر داخل یکی از این دو حافظه رو تشخیص بدیم.  (حافظه ی RAM موقتی هست،مقدار حجمش کمتره ولی سریع تره، حافظه ی EEPROM مقدار بزرگتری داره، کندتره و تعداد دفعات نوشتن و خوندن محدودی داره و تا پاک نکنیمش محتواش ماندگاره.)

 

 

بخش ساده سازی!

ببین عزیزم، جاواکارت رو به عنوان یه ساختمون n طبقه در نظر بگیر که پشت درب ورودیش یه سرایه دار نشسته و این سرایه دار از روزی که ساختمون ساخته میشه، تا روزی که ساختمون خراب میشه اونجاست و دو تا وظیفه داره! یکی این که هرکسی که میخواد بره توی ساختمون ساکن بشه یا کسی که ساکنه و میخواد از ساختمون بره بیرون، از این باید اجازه بگیره و کلا این کارای حمل و نقلش و خونه دادن بهش رو انجام میده. دوم این که اگه یه نفر از بیرون خواست چیزی بده به کسی که داخل ساختمونه و یا برعکس (ساکنین خواستند چیزی بدن به کسی که بیرون ساختمونه) این سرایه دار میشه واسطه!

حالا یعنی چی؟ 

کارت وقتی توی کارخونه ساخته میشه، یه اپلیکیشنی داخلش نصب میشه به اسم Card Manager یا Security Domain. این اپلیکیشن تا همیشه دیگه داخل کارت هست و از این به بعد اگه کسی خواست اپلِتی(به اپلیکیشن های روی کارت میگیم Applet) روی کارت نصب کنه، بایت-کدهاش رو به این میده و این براش نصب میکنه (همچنین واسه ی حذف یه روال مشابه طی میشه). همچنین اگه کسی خواست  دستوری/پیامی به یه اپلت روی کارت بفرسته، اول به این Card Managerمیگه من میخوام با فلان اپلت حرف بزنم، اگه Card Manager اجازه داد (اون اپلت وجود داشت، قفل نشده بود، رمز نمیخواست و...) اونوقت پیام رو میده باز به این کارت منیجر و کارت منیجر میده تش به اپلت و جواب رو میگیره و میده به کاربر بیرونی.

قسمت بعدی: احراز هویت

---

چه غم که عشق به جایی رسید یا نرسید؟

که آنچه زنده و زیباست، نفسِ این سفر است ...

#حسین منزوی

جاواکارت-مقدماتی/1- مقدمه

به نام خدا

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

مقدمه:

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

واسط ارتباطی(Interface):

1. کارتهای تماسی (Contact-Card) --> مانند کارت تلفن و سیم کارت ها
   
2. کارتهای غیرتماسی (Contactless-Card) --> مانند کارت های مترو
3. کارتهای دو واسطی (Dual-Interface Cards) --> کارتهای هوشمند ملی که بنا است جایگزین کارت ملی شوند، از این نوع خواهند بود.

سوال: کارت های غیرتماسی چگونه کار میکنند و با کارتخوان ارتباط برقرار میکنند؟ 

جواب : دور تا دور داخل این بدنه ی لاستیکی کارت یک سیم پیچ قرار گرفته است و  هنگامی که کارت به محدوده ای از فضای اطراف کارت خوان نزدیک می‌شود به واسطه ی میدان مغناطیسی کارتخوان، درون این سیم پیچ ولتاژی القاء شده و انرژی لازم برای تراشه ی کارت را فراهم می‌کند. داده هایی که قرار است تبادل شوند، سوار بر یک سیگنال شده و به کارت/کارتخوان ارسال می‌شوند. البته ناگفته نماند که کارتهایی نیز وجود دارند که به صورت داخلی نیز دارای یک باتری می‌باشند، ولی در حال حاضر هیچ نمونه ی داخلی ای از این کارت‌ها نداریم و کاربردی هم ندارند. کارت های غیرتماسی از لحاظ فرکانس کاری و بُرد به انواع مختلفی تقسیم می‌شوند ولی از آنجا که اطلاع از این جزئیات در بحث‌های آتی ما تاثیرات چندانی ندارد، صحبت در این زمینه را به آینده موکول می‌کنیم.

سوال: Combo Card و Hybrid Cards؟ 

 جواب: کارت هایی که دارای دو واسط اند (= Dual Interface) به دو صورت می‌توانند ساخته شده باشند. حالت اول این که داخل کارت تنها یک تراشه وجود داشته باشد و هر دو واسط با آن ارتباط برقرار کنند، و حالت دوم این که داخل کارت دو تراشه ی مجزا وجود داشته باشد و هر واسط مستقلا تنها با یکی از آن‌ها دو تا مرتبط باشد (مشابه این که دو کارت که یکی تماسی و یکی غیرتماسی است را در یک پکیج قرار داده باشیم). 

 به یکی از این حالات Combo و به حالت دیگر Hybrid می‌گویند.

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

 جواب: کارت های بانکی یا مغناطیسی یا Magnetic Stripe یا اصطلاحا MagStripe و کارت های بارکدی اصولا نباید جزو کارت های الکترونیکی حساب شوند، ولی از آنجا که برای ارتباط با آنها سنسور کارتخوان مربوطه باید به صورت مستقیم و بدون واسطه با نوار مغناطیسی/خطوط بارکد ارتباط برقرار کند تا بتواند محتویات کارت رو قرائت کند، گروهی آن ها را جزو کارت های تماسی به حساب می‌آورند.

تراشه ی داخلی (Chip):

1. کارت های حافظه یا Memory Cards یا Dump Cards --> مانند کارت تلفن و کارت مترو
2. کارت های هوشند یا Smart Cards یا Cards with uProcessor --> مانند کارت هوشمند ملی یا سیمکارت ها.

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

جواب: چرا! کارت های حافظه، به چهار دسته تقسیم می‌شوند، گروه اول تنها یک EEPROM ساده بدون هیچ مکانیزم امنیتی است (این نوع کارت ها دیگر تولید نمی‌شوند و تنها به صورت یک تراشه‌ی حافظه از آن ها بعضا روی مدارهای الکتریکی استفاده می‌شود). گروه دوم متشکل از یک حافظه و یه قسمت منطقی امنیتی است که به عنوان مثال اجازه نمی‌دهد محتویات حافظه از صفر به یک تغییر کنند و تنها اجازه ی تبدیل مقادیر یک به صفر می‌دهند، و یا این که به صورت یه شمارنده تنها امکان تعداد خاصی فرایند را برای کاربر فراهم می‌کنند (کارت های تلفن قدیم به احتمال زیاد از این مدل بوده اند). گروه سوم از یک حافظه و  یه قسمت منطقی امنیتی پیشرفته تر است که تنها با داشتن یه رمز سه الی پنج رقمی اجازه ی تغییر محتویات حافظه را فراهم می‌کنند (مانند کارت های تلفن فعلی- SLE4442/52). و در نهایت گروه چهارم به صورت یه حافظه و مکانیزم امنیتی پیشرفته است که هم ارتباط بین کارت و کارت خوان را رمز می‌کنند و هم اجازه ی تغییر یا خواندن محتویات حافظه تنها در گرو داشتن یه سری کلید احراز هویت به کاربر می‌دهند(مانند کارت های مترو).  

 

سیستم عامل (OS): 

* این تقسیم بندی همان طور که از اسمش مشخص است، خاص کارت های هوشمند می باشد.

1. Java Cards (هدف این مجموعه پست ها)
2. MultOS (نسبت به جاواکارت قیمت بالاتر و امنیت بالاتری دارد، دانش توسعه‌ی آن خیلی انحصاری است، دارای Community فعالی نیست، زبان برنامه نویسی اصلی آن C و Assembly است ولی کامپایلر بیسیک و جاوا هم  برای آن ساخته شده است و نمونه‌ی داخلی از آن نداریم).
3. Windows Cards (مرسوم نیست).
4. Native Cards (سایر کارت های هوشمند بدون سیستم عامل).

قسمت بعدی: استانداردها + توضیح ساده در مورد ساختار درونی عمکرد کارت.

---

هرکه دلارام دید

از دلش آرام رفت ..

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