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

---

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

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

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

---

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

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

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