صد رازِ نهان

یک شمع، با روشن کردن شمعی دیگر چیزی از دست نمی‌دهد!

۲ مطلب با کلمه‌ی کلیدی «APDU» ثبت شده است

جاواکارت-مقدماتی/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 در یک ابزار ارائه شوند، در کارت هوشمند هم این سه دسته ابزار می‌توانند در یک بسته ارائه گردند. در زیر به صورت خلاصه نرم افزارهای موجود برای هر گروه را نام می‌بریم و در خلال پست های بعدی به صورت عملی با هر کدام آشنا خواهیم شد:

نوشتن اپلت:
بارگذاری و نصب اپلت:
ارتباط با اپلت ها:
  • 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

۲۰ مهر ۹۴ ، ۲۲:۲۸ ۰ نظر موافقین ۱ مخالفین ۰
ابراهیم قاسمی