رمزنگاری-مقدمه/3-حل مشکلات مرتبط با Encoding

قسمت قبلی: انکدینگ و دیکدینگ

طبق قرار پیشین، به عنوانِ ادامه‌ی مبحث اِنکدینگ و دیکدینگ (پیش زمینه ای بر مباحث رمزنگاری)، در این پست دو مشکلی را بررسی می‌کنیم که با احتمال زیاد تابحال حداقل یکبار با آن‌ها مواجه شده اید و با Encoding ارتباط مستقیم دارند:

مشکل اول: زیرنویس های خرچنگ قورباغه و ناخوانا

 گاها، بعد از دانلود کردن زیرنویس فارسی یک فیلم و افزودن آن به Player، به جای حروف فارسی، با تصویری مشابه زیر مواجه می‌شویم:

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

راهکار اول: (موقتی)

نرم افزار Microsoft Office Word را باز کنید و از منوی File و سپس Open فایل زیرنویس دانلود شده را داخل آن Import کنید. بلافاصله بعد از کلیک کردن روی دکمه ی Open برای باز شدن فایل در نرم افزار Word پنجره ای مشابه زیر باز خواهد شد که باید از منوی سمت راست گزینه ی Unicode  UTF-8 را انتخاب کنید (معمولا به صورت اتوماتیک این کار انجام شده است و شما در کادر بزرگ پایین، متن فارسی را به صورت درست مشاهده می‌کنید؛ در ایصورت حتی اگر Encoding چیزی مغایر با آنچه که گفتیم بود، به آن دست نزنید) و کلید OK را بزنید:

پس از کلیک روی OK محتوای زیرنویس به صورت خوانا داخل Microsoft Word باز می‌شود. کاری که لازم است در این مرحله انجام دهید این است که از منوی File گزینه‌ی Save As را انتخاب کنید و سپس این محتوا را به صورت یک فایل با پسوند txt. ذخیره کنید. در نهایت، فایل جدید را با موس به داخل Player بکشید تا تصویری مشابه زیر داشته باشید:

راهکار دوم: (موقتی)

در این روش که مشابه روش پیشین است، به جای استفاده از نرم افزار Microsoft Word از نرم افزاری به نام ++Notepad [دانلود کنید] استفاده میکنیم.

برای این منظور، ابتدا زیرنویس را در این محیط باز می‌کنیم. در این مرحله محتویات آن را به همان صورت ناخوانا می‌بینیم. از منوی Encoding به صورت زیر، Windows-256 را انتخاب می‌کنیم تا متن فارسی به صورت خوانا ظاهر شود:

و سپس، باز از منوی File گزینه‌س Save As را انتخاب کرده و محتویات را به صورت یک فایل txt. ذخیره می‌کنیم و فایل جدید را به عنوان زیرنویس استفاده می‌کنیم.

راهکار سوم: (دائمی)

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

از منوی Start روی Control Panel کلیک کنید و سپس در پنجره ی باز شده روی  Clock, Language and Region (در ویندوز XP روی Region and Language) انتخاب کنید. در پنجره ی باز شده، ابتدا در تَبِ Format، از قسمت کشویی، Persian را انتخاب کنید و سپس به تَبِ Administrative رفته و با کلیک روی Change System Locale مجددا مشابه تصویر زیر Persian را انتخاب کرده و با زدن OK سیستم خود را Restart کنید:

از این به بعد، زیرنویس های دانلود شده، بدون مشکل ناخوانا شدن داخل Player باز می‌شوند. 

مشکل دوم: صفحات وب و ایمیل های خرچنگ قورباغه و ناخوانا

خوشبختانه منشاء این مشکل نیز همان مسئله‌ی انکدینگ است. برای رفع این مسئله چنانچه با یک ایمیل فارسی ناخانوا مواجه هستیم، می‌توانیم با Copy & Paste کردن محتوای آن در یک فایل متنی و انجام مراحل ذکر شده در راهکار اول و راهکار دوم برای زیرنویس ها، متن آن را بخوانیم؛ و چنانچه یا با یک صفحه ی وب فارسی مواجه هستیم، یا تمایلی به Copy & Paste کردن محتوای ایمیل نداریم، می‌توانیم تنظیمات Encoding مرورگر وب خود را به صورت زیر تغییر دهیم (هر بار یکی از گزینه های مشخص شده انتخاب می‌کنیم) تا نتیجه‌ی مطلوب را مشاهده کنیم:

برای مرورگر Google Chrome:

برای مرورگر Fire Fox:

Sorry, I don't like it :D use dear Google Chrome, or Google "How to change encoding in fire fox?" and follow the above steps!

قسمت بعدی: معیارهای امنیت

---

Well you only need the light when it's burning low

Only miss the sun when it starts to snow

Only know you love her when you let her go ...

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

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

---

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

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

درخواست‌های HTTP

در این مطلب تا جایی که دانشم کفاف می‌دهد درباره‌ی درخواست‌های HTTP صحبت می‌کنم.

در قسمتِ «شروع سریع» از پستِ «هدف‌گذاری و یک شروع در حوزه‌ی بات‌ها!»، راه‌اندازیِ پراکسی‌سرورِ واسطِ BurpSuite را شرح دادم؛ در نتیجه برای شروعِ کار با شنودگرِ BurpSuite، شاید لازم باشد آن قسمت را مطالعه کنید.

هدف‌گذاری و یک شروع در حوزه‌ی بات‌ها!

برای ادامه‌ی کار ترجیح می‌دهم ابتدا مشخص کنیم که قرار است چه کنیم؛ زیرا معتقدم اگر هدف از ابتدا مشخص باشد، حاشیه‌پردازی و یادگیریِ اضافات رخ نخواهد داد و ما صرفاً مواردی را خواهیم آموخت که برای انجامِ آن هدف نیاز است.

ما در این سلسله‌مطالب، از سایتِ «دیوار»، که یک پایگاه برای ارسالِ آگهی‌های آنلاین است استفاده خواهیم کرد.
دلیلِ این‌که از دیوار استفاده می‌کنیم؛ پتانسیلِ بالای این سایت است؛ این پتانسیلِ بالا به سببِ آن تولید شده است که APIهای مورد استفاده برای ارسالِ درخواست‌ها به خوبی طراحی شده‌اند و از قالبِ خوبی تبعیت می‌کنند.
همچنین وسعتِ زیادِ عملکردهای در دسترس که در این سایت قرار دارند، به ما این امکان را می‌دهد که چیزهای بیشتری یاد بگیریم.
و دلیلِ استفاده از یک سایتِ معروف، اضافه کردنِ کمی هیجان و لذت به کار است تا بازدهِ یادگیری را افزایش دهد.

این‌نیز جالب به ذکر است که حتی اگر دیواری‌ها از این مطالب خوششان نیاید هم من قادر به انجامِ کاری برایشان نخواهم بود و چاره‌شان در تغییرِ ساختارِ درخواست‌ها و اذیت کردنِ بات‌نویس‌ها نهفته است!

شروعی در موردِ روبات‌ها

«روبات» واژه‌ایست که به گروهِ عظیمی از «چیز»ها اطلاق می‌شود؛ «چیز»های نرم و چیزهای سخت؛ سخت مثلِ BigDog و نرم مثلِ روبات‌هایی که با تکثیرِ سریعشان باعثِ تولیدِ مفهومی به نامِ Captcha شدند!

بعضی مواقع به روبات‌های نرم، «بات» هم گفته می‌شود. اما من در پست‌های آتی، ممکن است در مواقعی از هر دو واژه به مفهومِ روبات‌های نرم استفاده کنم.

و البته باید ذکر کنم که مطالبِ این دسته در موردِ بات‌ها، یا روبات‌های نرم خواهد بود.

رمزنگاری-مقدمه/2-اِنکُدینگ و دیکُدینگ

قسمت قبلی: هشینگ!

خیلی خب! در قسمت قبل (یعنی این پست) با "Hash" کردن یا دَرهم نگاری آشنا شدیم و فهمیدیم که هَش کردن یعنی اختصاص یک رشته ی با طول ثابت به یک ورودی دلخواه، با این شروط که:

1. از روی مقدار هش مقدار ورودی قابل تولید نباشد.
2. احتمال این که به ازای دو ورودی مختلف، یک خروجی تولید شود به قدری کم باشد که قابل چشم پوشی باشد.

همچنین فهمیدیم که الگوریتم های Hash کردن، کلید یا رمز ندارند و همه چیز صرفا یک الگوریتم است که تنها ورودی آن داده ی مورد نیاز برای Hash شدن است. برای عملی تر شدن توضیحات، می توانید با مراجعه به این سایت یا این سایت عبارت های مورد نظر خود را با چند الگوریتم مشهور دَرهم نگاری هش کنید. به هر حال من قبلا این کار را برای عبارت "This is a sample plain text" انجام داده ام و نتیجه را برای شما داخل عکس زیر آماده کرده ام:

و اما:

قسمت 2: Encoding/Decoding

معرفی فرایند:

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

اما اگر بخواهیم به زبان ساده تر بیان کنیم، Encode کردن و Decode کردن مشابه فرایند ترجمه ی یک متن از یک زبان به زبان دیگر است. یعنی همانطور که در دنیای واقعی می‌توان یک متن فارسی را به راحتی به زبان های مختلف دیگر ترجمه کرد و بعد دوباره به متن اصلی بازگرداند، در دنیای رایانه‌ها هم می‌توان یک داده را به فرمت های مختلف ترجمه یا در اصطلاح Encode کرد و بعد دوباره به فرمت اولیه بازگرداند یا اصطلاحا Decode کرد و باز همانطور که در دنیای واقعی اگر زبان مقصد معادلی برای قسمتی از متن اصلی نداشته باشد، ترجمه ی آن قسمت امکان پذیر نیست، در دنیای رایانه هم گاها، Encode کردن یک داده از یک فرمت به فرمت دیگر، به خاطر پشتیبانی نکردن فرمت مقصد از قسمتی از داده ی ورودی، با شکست مواجه می‌شود. (یا به داده هایی غیر قابل بازگشت تبدیل می شوند.)

بنابراین، با توجه به مثال ارائه شده، Encode و Decode کردن تغییر فرمت(نحوه‌ی نمایش) یک متن/داده است به گونه ای که:

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

از آنجا که با ارائه شدن هر محصول یا تکنولوژی ای، معمولا یک فرمت بهینه برای آن سیستم ارائه می‌شد، گستردگی توابع Encoding/Decoding به گستردگی توابع هش کننده و یا حتی بیشتر از آن است. به عنوان مثال ASCII،  Bas64، UTF16، UTF32 و ... همگی نمونه هایی از Encodingهای مختلف می‌باشند.

کاربردها:

اولین سوالی که ذهن با آن مواجه می‌شود این است که چرا باید Encodingهای مختلفی وجود داشته باشد؟

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

به عنوان مثال در ابتدا وقتی سیستم عامل‌ها توسعه داده شدند، هر تولیدکننده ای بدون توجه به آنچه که تولیدکننده ی دیگر ارائه می‌دهد یک Encoding برای خود به وجود آورد! همچنین کسی در نظر نگرفته بود که حروف فارسی یا چینی یا زبان های دیگر و همچنین کاراکترهای خاص عبارت های ریاضی نیز قرار است در آن محصول استفاده شود و بنابرین بسنده کرده بودند به حروف انگلیسی کوچک و بزرگ و چند علامت ساده‌ی ریاضی. از آنجا که تعداد این کاراکترها از تعداد حالت هایی که با 8 بیت می‌توان تولید کرد افزون نبود، بنابرین 1 بایت را به آن اختصاص دادند و نام آن انکدینگ را ASCII گذاشتند. بعدها با گذر زمان وقتی نیاز به کاراکترهای بیشتر احساس شد، انکدینگ دیگری ارائه کردند که طول آن بیشتر از یک بایت باشد و بتواند کاراکترهای بیشتری در خود جای دهد. این روال در گذر زمان منجر شد که Encodingهای مختلفی بوجود آید. (مانند Unicode, UTF-32 و ...).

یکی دیگر از دلایل، ناسازگاری استانداردهای موجود برای انتقال بعضی داده ها و انجام بعضی کارها بود. به عنوان مثال استاندارد شده بود که برای جداسازی قسمت های مختلف یک URL (آدرس وب) از کاراکتر "/" استفاده شود. همچنین برنامه نویس می‌توانست به گونه ای برنامه ی وب خود را بنویسد که پس از پر کردن یک فرم در صفحه توسط کاربر،محتویات آن فرم را از طریق Address-bar از وی دریافت کند.مشکلی که وجود داشت این بود که چنانچه کاربر در فرم خود از کاراکتر "/" استفاده می‌کرد، آنگاه حین ارسال این کاراکتر به سرور، به خاطد تداخل داده ی کاربر با کاراکتر جداکننده، با مشکل مواجه می‌شد. برای رفع این مسئله و چند مورد مشابه یک Encoding جدید به نام URL Encoding برای محتویات خط آدرس ارائه شد. در این سیستم جدید، کاراکترهای خاص نظیر / و فاصله و ' و " و ... پیش از ارسال به مقادیر دیگری تبدیل می‌شود (به ترتیب به 2F% و 20% و 27%  و 22%) که با استاندارد آدرس دهی تداخلی نداشته باشند و آنگاه در سرور Decode شده و تفسیر می‌شوند. 

انکدینگ‌های مشهور:

همانطور که در خلال متن اشاره شد، برای انکدینگ های مشهور می‌توان به سری UTF اشاره کرد که شامل کاراکترهای زبان فارسی و ... می‌باشد ؛ ASCII که تنها شامل کاراکترهای زبان انگلیسی و یک سری کاراکتر خاص است و همچنین Base64 که معمولا برای نمایش خروجی توابع رمزنگاری استفاده می شود. برای تبدیل داده های خود از یک انکدینگ به انکدینگ دیگر می‌توانید از ابزارهای آنلاین مانند این سایت استفاده کنید، یا این که با دانلود کردن نرم افزارهایی مثل ++Notepad از امکانات آنها برای تغییر Encoding  بهره ببرید.

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

قسمت بعدی: مشکلاتی که با تغییر Encoding حل می‌شوند!

---

خوشا آنانکه الله یارشان بی

بحمد و قل هو الله کارشان بی

خوشا آنانکه دایم در نمازند

بهشت جاودان بازارشان بی

جاواکارت-مقدماتی/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-هَشینگ

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

1. هش کردن (Hashing)
2. کد کردن / از کد خارج کردن (Encoding & Decoding)
3. رمز کردن / از رمز خارج کردن (Encrypting & Decrypting)

قسمت 1: "هش کردن یا دَرهم نگاری"

معرفی فرایند:

هش کردن، تولید یه متن از یه ورودی هست به نحوی که غیر قابل بازگشت باشه. یعنی از روی مقدار هَش، کسی نتونه داده ی اولیه رو بدست بیاره. چیزی که در مورد توابع درهم نگار (توابع هش کننده) باید بدونیم این هست که معمولا طول خروجی این توابع، مقدار ثابتی هست و این طول ثابت فارغ از طول ورودی است. سوال اولی که یه ذهن باهوش متوجه ش میشه این هست که بر این اساس، تابع های هش، توابع یک به یک نیستند. چرا که داشتن طول ثابت برای یه داده، به این معناست که تعداد حالت های محدودی میتونه داشته باشه (مثلا یه خروجی 4 بیتی، تعداد حالت هایی که میتونه داشته باشه 2⁴ عدد است و ...)؛ در حالی که ورودی چون طول نامتناهی می تونه  داشته باشه، پس تعداد حالت هاش هم نا متناهی میشه، و بنابر این، اختصاص مقادیر هش به مقادیر ورودی نمیتونه یک به یک باشه. 

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

وقتی که قراره قدرت یه تابع/الگوریتم هَش کننده رو بررسی کنند، باید دو تا مسئله در نظر گرفته بشه:

1. آیا با داشتن مقدار هَش یه داده، میتونیم داده رو بدست بیاریم؟
2. آیا با داشتن یه مقدار هَش، میتونیم داده یا داده هایی تولید کنیم که با اون الگوریتم همین مقدار رو به ما بدهند؟

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

Input 1:  HelloMyDearFriend

Input 2:  WhereDoYouWantToGO?

Step1 Of Hash(Input 1):  -e-l-M-D-a-F-i-n- 

Step1 Of Hash(Input 2):  -h-r-D-Y-u-a-t-o-o

Final Hash(Input 1): elMDa

Final Hash(Input 2): hrDYu

خب، همونطور که میبینیم، ما از ورودی های مختلف، خروجی های مختلفی به عنوان مقدار هَش شده بدست آوردیم که دیگه نمیتونیم مقدار اولیه رو از روی اون ها بدست بیاریم. ولی نکته ای که این الگوریتم داره اینه که، با داشتن مقدارهای هَش، خیلی ساده میتونیم داده ای بسازیم که بعد از پیاده سازی الگورتیم روی اون، همین خروجی تولید بشه. ضمنا بد نیست بدونیم که خروجی یک تابع هش رو Message Digest میگن.

کاربردها:

توابع هَش، دو تا کاربرد اصلی دارند:

1. جایگزین پسورد برای ذخیره کردن در دیتابیس
2. به عنوان Check Sum

اما هر کدوم از این ها چی هستند؟

جواب:

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

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

خب کاربرد اول تابع های هَش اینجا خودش رو نشون میده. ما به عنوان برنامه نویس سایت، میایم به جای ذخیره کردن کلمه ی عبور، مقدار هَش شده ی اون رو داخل دیتا بیس ذخیره می‌کنیم. و از این به بعد هر بار که کاربر نام کاربری و کلمه ی عبور خودش رو وارد کرد، اول از کلمه ی عبور مقدار هَش رو بدست میاریم و بعد با مقدار داخل دیتابیس مقایسه میکنیم و الی آخر. با این مکانیزم، اگه سایت ما هک شد و کسی به نحوی به دیتابیس دست پیدا کرد، دیگه نمی تونه کلمه های عبور رو بدست بیاره. 

و اما در مورد Checksum: فرض کنید شما قصد دارید فایلی رو روی سایت خودتون بذارید که کاربرهای شما دانلود کنند و میخواید اطمینان داشته باشید که فایلی که دانلود میکنند، داخل مسیر، به صورت اتفاقی(به خاطر Noise)و یا به صورت تعمدی(توسط یه هکر) دستکاری نشده باشه؛ خب چه راهکاری به ذهنتون میرسه؟

ساده ترین راهکار اینه که از محتویات فایل یه مقدار هش شده تولید کنید و این مقدار هش شده رو روی سایت قرار بدید. حالا کاربرهای شما وقتی فایل رو دانلود کردند، قبل از این که اجراش کنند، با همون تابع هش شما، از محتویات مقدار هَش رو تولید می کنند و با مقدار روی سایت مقایسه می کنند. در صورتی که هر دو مقدار با هم برابر بودند، نتیجه می گیرند فایل داخل مسیر عوض نشده.

الگوریتم های مشهور:

SHA - MD5 - NT - LM  ....

توجه: بین hash و checksum و CRC  علیرغم شباهت های زیاد، تفاوت هایی هم هست که برای اطلاع از اونها به ویکی پدیا مراجعه کنید. (:

قسمت بعدی: اِندینگ و دیکدینگ

---

احسان هنری نیست به امید تلافی

نیکی به کسی کن که به کار تو نیاید ...

#صائب

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

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

---

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

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

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