جاواکارت مقدماتی/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 های جاواکارت (به زودی!)

---

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

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

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

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

---

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

جاواکارت-مقدماتی/5-ابزارهای مورد نیاز

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

در این قسمت، به عنوان ادامه‌ای بر مباحث پیشین، ابزارهایی که از آغاز به نوشتن یک اپلت تا نصب آن روی کارت و ارتباط با آن نیاز است را معرفی می‌کنیم. در یک دید کلّی، ابزارهای مورد نیاز به دو دسته تقسیم می‌شوند:

1- سخت افزار: 

طبیعتا برای این که کارت بتواند داده ای از سمت رایانه دریافت کند یا داده ای به آن ارسال کند، نیازمند سخت افزاری است که "کارت خوان" (Card Reader) نامیده می‌شود. نکته‌ی جالب توجه اینجاست که دستگاهی به نام "کارت نویس" (Card Writer) نداریم و همان کارتخوان هر دو عمل نوشتن و خواندن را انجام می‌دهد. بدیهتا، کارتخوان کارت‌های تماسی با کارتخوان کارت‌های غیر تماسی متفاوت است و هنگام خرید باید این را مد نظر قرار دهیم که قرار است با چه نوع کارتی کار کنیم. ACR38 و ACR122U دو نمونه کارتخوان به ترتیب برای کارت های تماسی و کارت‌های غیرتماسی اند. همچنین ممکن است هنگام خرید کارتخوان، دستگاه هایی به نام Encoder و Decoder نیز به شما پیشنهاد شوند، که هیچ نیازی به آن ندارید. در واقع، این دو دستگاه برای ارتباط با کارت‌های مغناطیسی (کارت‌های با نوار مشکی- مانند کارت‌های بانکی) استفاده می‌شوند. کارت های مغناطیسی بر خلاف کارت‌های الکترونیکی تراشه دار، برای خواندن و نوشتن به دو دستگاه متفاوت نیاز دارند. دستگاهی که برای خواندن محتویات کارت‌های مغناطیسی استفاده می‌شود Decoder و دستگاهی که برای نوشتن روی این کارت‌ها استفاده می‌شود، Encoder نام دارد. 

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

2- نرم افزار:

بحث در مورد نرم افزارهای مورد نیاز در زمینه‌ی کارت‌های هوشمند را با دو مثال متفاوت آغاز می‌کنیم:

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

1. نرم افزاری که در آن برنامه‌ی مورد نظر را بنویسید (مانند Code vision، Bascom یا AVR Studio برای میکروهای AVR).
2. نرم افزاری که به وسیله‌ی آن فایل ساخته شده را به میکرو منتقل کنید (مانند ProgISP یا Pony Prog).
3. نرم افزاری که به وسیله‌ی آن داده های میکرو را از پورت سریال دریافت کنید (مانند Terminal یا Hyper Terminal یا Termite).

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

1. نرم افزاری که در آن کد برنامه‌/صفحه ی خود را می‌نویسید (مانند PHP Storm یا PyCharm).
2. نرم افزاری که به وسیله ی آن برنامه/صفحه ی نوشته شده را به Host(فضای روی اینترنت) منتقل می‌کنید (مانند Git، FileZila یا Free FTP).
3. نرم افزاری که با صفحه وب نوشته شده ارتباط برقرار می‌کنید (مانند Chrome, FireFox)

خب، در مورد کارت هوشمند هم [که در واقع یک میکرو کنترلر است] روال به همین صورت بالاست. یعنی شما به سه مجموعه نرم افزار مختلف برای نوشتن اپلت، بارگذاری و نصب اپلت و ارتباط با اپلت نیاز دارید. و مجددا همانطور که در مثال های بالا، نرم افزارهای چند گروه می‌توانند به صورت یک Package در یک ابزار ارائه شوند، در کارت هوشمند هم این سه دسته ابزار می‌توانند در یک بسته ارائه گردند. در زیر به صورت خلاصه نرم افزارهای موجود برای هر گروه را نام می‌بریم و در خلال پست های بعدی به صورت عملی با هر کدام آشنا خواهیم شد:

نوشتن اپلت:

• Eclipse + JDK + Eclipse-JCDE + JCDK
• Netbeans + JDK
• JCIDE + JDK + JCDK

بارگذاری و نصب اپلت:

• GlobalPlatformPro (This is a tool! Don't confuse it with the Global Platform Standard that I mentioned in previous posts)
• JCManager
• PyAPDUTool
• GPShell

ارتباط با اپلت ها:

• OpenSCTool
• PyAPDUTool
• Your Reader SDK Tools
• Python library that is named "PySCard"
• Java package that is named "javax.smartcardio" (I think it is deprecated and is not available in JDK 1.7 and newer versions)
• C/C++ library that is named "winscard" (:-?)

نکته: شما در هر کدام از مجموعه های بالا تنها به یک ابزار نیاز دارید و بسته به این که با کدام یک ارتباط بهتری برقرار می‌کنید، در آینده یکی را انتخاب خواهید کرد. لازم به ذکر است که همانگونه که پیشتر بیان شد ابزارهایی نیز ارائه شده اند که نرم افزارهای هر سه مجموعه را در یک Package گرد آورده اند، لکن از آنجا که غالب آنها یا به خاطر تحریم یا بنا به دلایلی از قبیل داشتن مشتری های حقوقی (و نه حقیقی) و انحصاری در دسترس نیستند یا به صورت رایگان نمی‌باشند، در این مجموعه در مورد آن ها صحبتی نخواهیم کرد (احتمالا). به عنوان مثال JCOP Tools و Gemalto Developer Suite دو نرم افزاری هستند که به ترتیب توسط شرکت NXP (یکی از بزرگترین تولیدکنندگان تراشه های کارت هوشمند) و شرکت Gemalto (یکی از بزرگترین تولیدکنندگان سیم کارت‌ها) ارائه شده اند و متشکل از تعداد زیادی پلاگین اند که روی هسته ی Eclipse سوار شده اند. 

سوال: Netbeans یا Eclipse؟

جواب: هر دو! پاسخ به این سوال ارتباط زیادی با نسخه‌ی جاواکارتی که قرار است با آن کار کنید دارد. از آنجا که Eclipse به صورت پیشفرض قابلیتی برای افزودن JCDK به آن ندارد، ما ناگریز باید از یک پلاگین استفاده کنیم (Eclipse-JCDE)  و از آنجا که این پلاگین به صورت عادی تنها با نسخه‌ی JCDK 2.2.2 و با کمی ترفند با نسخه های پایین تر از این ورژن کار می‌کند، پس برای کار با کارت‌های نسخه‌ی 2.2.2 و قبل از آن، Eclipse را انتخاب می‌کنیم. در مقابل، نرم افزار Netbeans به صورت پیشفرض با نسخه‌ی JCDK 3.0.1 Classic & Connected ارائه می‌شود و چنانچه ما برنامه ی برای نوشتن روی کارت‌های نسخه‌ی 3 و  بالاتر داریم، از این محیط برنامه نویسی استفاده خواهیم کرد.

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

---

"A ship is safe in harbor, but that’s not what ships are for." | William G.T. Shedd

جاواکارت-مقدماتی/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 و سایر ابزارها آشنا خواهیم شد.

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

---

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

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

جاواکارت-مقدماتی/3-احراز هویت

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

بخش احراز هویت و امنیت:

خب، گفتیم داخل کارت از زمان ساخت کارت یه اپلیکیشن به اسم Card Manager وجود داره که کار های مدیریتی کارت به عهده ی اونه. اما یه سوال پیش میاد، آیا هر کسی میتونه روی کارت یه اپلت نصب کنه یا حذف کنه؟ جوابش مشخصه و مسلما منفیه. 

حالا سوال بعدی اینه که کارت به کی جواب میده؟

جواب: همون لحظه ای که Card Manager داخل کارت نصب میشه، سه تا کلید رمزنگاری هم همراهش داخل کارت ذخیره میشه که یه مقدار پیشفرضی دارند و کسی که کارت رو میخره، با داشتن اونها میتونه این دستورات رو به کارت بده و کلید ها رو هم عوض کنه. 

خب، اول ببینیم احراز هویت کلا به چه صورت هایی میتونه باشه و بعد بگیم کارت از چه روشی استفاده میکنه:

احراز هویت:

1. یک طرفه یا One Point Authentication
2. دو طرفه یا Mutual Authentication

با یه مثال هر دو رو توضیح میدم. فرض کن من باید یه دستوری رو به شما بدم که اجراش کنی و فقط هم باید به شما بدم و نباید به هیچ کس دیگه ای بگم، شما هم باید یه دستور از من بگیری و اجرا کنی و نباید از هیچ کس دیگه ای دستور بگیری.

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

روش دوم اینه که من و شما از قبل یه رمزی و یه الگوریتمی رو با هم به اشتراک گذاشتیم (همون کلید[های] امنیتی پیش فرض که داخل کارخونه نوشته شده و بعد توسط کاربر قابل عوض شدنه). وقتی به هم میرسیم، من یه عدد تصادفی میدم به شما، شما هم یه عدد تصادفی میدی به من. هر دو با اون الگوریتم و اون کلیدهای پیشفرض عدد رندوم طرف مقابل رو رمز میکنیم و بهش پس میدیم. بعد هر کدوممون عدد رندوم خودمون رو هم با اون کلید و الگورتیم رمز کردیم به صورت داخلی. نتیجه ای که خودمون بهش رسیدیم رو با نتیجه ای که طرف مقابل بهمون داده مقایسه میکنیم، اگه با هم برابر بودند، نتیجه میگیریم که طرف مقابلمون کلید رو داره و بنابرین کسی هست که باید بهش دستور بدیم یا دستورش رو اجرا کنیم :)

برای روشن تر شدن، با یه مثال ملموس تر بیانش میکنم. فرض کن من و شما، شب قبلش هم دیگه رو میبینیم، بعد به هم میگیم، کلید رمز ما "12345" باشه و الگوریتم هم به این صورت باشه که هر داده ای دریافت کردیم،  با کلید جمعش کنیم و پسش بدیم. حالا فردا که هم دیگه رو میبینیم، من یه عدد تصادفی میدم به شما (مثلا 124) و شما هم یه عدد تصادفی به من میدی (مثلا 892). بعد من شما عدد من رو با 12345 جمع میکنی و نتیجه رو به من میدی، من هم عدد شما رو با 12345 جمع میکنم و نتیجه رو به شما میدم. هر دو میدونیم باید منتظر چه عددی باشیم، و اگه عددی جز اون رو دریافت کردیم متوجه میشیم که طرف مقابلمون، کسی که باید باشه نیست. ...

داخل کارت های هوشمند جدید (جاواکارت ها) این روش دوم استفاده میشه. در اصل این یه بند از استاندارد Global Platform هستش که پیشتر گفتیم از استانداردهای مدیریتی کارته. و تقریبا همه ی جاواکارت ها الزامات این استاندارد رو meet میکنند.

سوال: گفتی که سه تا کلید رمزنگاری به صورت پیش فرض روی کارت نوشته میشه، ولی الان برای احراز هویت فقط یه کلید کافی بود، پس بقیه واسه ی چیه؟ 

جواب: خب، وقتی صحبت از امنیت بین دو تا موجودیت فعال و/یا غیرفعال میشه (توی استاندارد با اسم Subject و Object شناخته میشند) دو تا مسئله ی اساسی وجود داره. یکی این که هر طرف مطمئن باشه که طرف مقابلش دقیقا همون کسی هست که فکر میکنه و بعد شروع کنه حرف بزنه یا جواب بده، دو این که حین حرف زدن/جواب دادن، کس دیگه ای نتونه محتوای صحبت هاشون رو بدست بیاره. اون سه تا کلید یکیش همون احراز هویت بالا استفاده میشه، یکیش برای رمزکردن داده های تبادلی بعد احراز هویت استفاده میشه و یکی دیگه اش وقتی استفاده میشه که ما میخوایم کلیدهای جدیدی جایگزین کلیدهای قبلی کنیم. یعنی کلیدهای جدید رو با اون کلید رمز میکنیم و ارسال میکنیم (برای بالاتر رفتن امنیت-محض احتیاط). 

هر کدوم از این کلیدها یه اسم هم دارند، به ترتیب ENC Key یا Encryption Key، و MAC Key یا Message Authentication Key و KEK یا Key Encryption Key.

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

---

آیین برادری و شرط یاری

آن نیست که عیب من هنر پنداری

آن است که گر خلاف شایسته روم

از غایت دوستیَم دشمن داری

جاواکارت-مقدماتی/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 (سایر کارت های هوشمند بدون سیستم عامل).

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

---

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

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

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