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

---

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

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

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

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

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

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

---

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

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

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