رمزنگاری/5-الگوریتم های Caesar و Enigma (سِزار و اِنیگما)

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

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

الگوریتم سزار:

"باب" جلسه ای دو نفره و محرمانه با "آلیس" تشکیل داد و با او در مورد نحوه‌ی ارسال نامه ها مشورت کرد. چیزی که در ابتدا باب می‌خواست این بود که هیچ کسی جز آلیس قادر به فهمیدن محتوای نامه و دستورات نباشد. در این جلسه تصمیم باب و آلیس بر این شد که در متن نامه به جای هر حرف، حرف سه جایگاه قبل تر را جایگزین کنند. به این صورت که به جای A حرف X، به جای B حرف Y و ... 

با روند فوق که در اصل یک نوع انکدینگ به حساب می‌آید (زیرا به نوعی فرمت حروف عوض شده است، و در صورتی که الگوریتم فاش شود، چیزی به عنوان کلید لازم نداریم و هر کسی می‌تواند داده ها را به حالت اولیه بازگرداند) به ظاهر محرمانگی نامه‌های تبادلی تضمین می‌شود، اما چیزی که بعدها باب و آلیس کشف کردند این بود که در نامه هایی نهایی درصد تکرار حروف می‌تواند باعث فاش شدن متن اصلی شود. یعنی از آنجا که پر تکرار ترین حرف انگلیسی E است، در نامه های رمز شده، پرتکرارترین حرف را اگر با E جایگزین کنیم، به متن اصلی نزدیک می‌شویم. به همین ترتیب تک حروف های منفرد، به احتمال زیاد یا I هستند یا A.  این قبیل نتیجه گیری ها که همگی به علت یکسان نبودن احتمال ظاهر شدن حروف مختلف در خروجی نهایی نامه هاست، به سادگی می‌توانست موجب رمزگشایی نامه‌ها شود و بنابرین آلیس و باب باید به دنبال راهکار دیگری می‌بودند ...

[پایان داستان باب و آلیس!!!/به علت زیاد بودن مطالب]

شکل: نسبت تکرار حروف مختلف در یک متن انگلیسی

نکته: در دنیای رمزنگاری، الگوریتم فوق به نام الگوریتم سزار معروف است، زیرا برای اولین بار ژولیوس سزار پادشاه رومی برای ارتباط با فرماندهانش استفاده شد. از نام های دیگر آن می‌توان به Shift Cipher، Caesar Code و Caesar shift اشاره کرد.

ماشین Enigma:

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

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

قسمت بعدی: بررسی تقسیم بندی الگوریتم‌های رمزنگاری

---

دیدار تو گر صبح ابد هم دَهَدَم دست

من سرخوشم از لذتِِ این چشم به راهی ...

#فریدون_مشیری

رمزنگاری/4-معیارهای امنیت

قسمت قبلی: مشکلات مربوط به Encoding

تا پیش از این با Hash کردن و Encoding و Decoding آشنا شدیم و دانستیم که Hashing استفاده از تابعی است که یک طرفه می‌باشد و پس از Hash کردن داده ها قابلیت بازیابی مجدد آن‌ها را نداریم، و در مقابل دانستیم که Encoding و Decoding تابع هایی دو طرفه برای تغییر Form داده ها هستند؛ که برای استفاده از آن‌ها نیاز به چیزی تحت عنوان کلید یا رمز نیست و هر فردی که از الگوریتم مطلع باشد می‌تواند داده های Encode شده را با استفاده از تابع Decode به داده های اصلی تبدیل کند.(لازم به ذکر است که ماهیت Public بودن قریب به اتفاق الگوریتم های Encoding/Decoding باعث می‌شود همه بتوانند از آن‌ها استفاده کنند).

معیارهای امنیت:

 در این قسمت ابتدا یک سناریو تعریف می‌کنیم و سپس بر اساس آن، علت نیاز به الگوریتم‌هایی فراتر از الگوریتم‌های Hash و Encoding/Decoding را متوجه خواهیم شد و در خلال قسمت های بعدی روند توسعه‌ی این الگوریتم‌های مورد نیاز را توضیح می‌دهیم.

در این سناریو شما فرمانده ی یک سپاه جنگی هستید و به سبب لزوم نظارت بر اتفاقات خط نبردِ نیروهایتان و نیز مدیریت کارهای مملکتی، ناچارید که مدام بین میدان کارزار و مقرّ فرماندهی آمد و شد کنید(بگذارید حداقل در این داستان سناریو را طوری تعریف کنیم که گویا نعلین فرماندهان نیز گَرد خطوط نبرد را به شیارهای خود دیده است!). بنابرین شما نیاز دارید که گاهی از این مقر، به یکی از سربازان عالی‌رتبه‌ی خود که وِی را به عنوان جانشین بر مسند فرماندهی گمارده‌اید نامه ای ارسال کنید و او را در جریان کارهایی که باید انجام دهد قرار دهید. همچنین، فرمانده ی مذکور، باید گزارشاتی از عملکرد خودش و اوضاع به شما ارسال کند. پیش از این که ادامه‌ی داستان را تعریف کنیم، یک نام برای شما، و یک نام برای آن افسر عالی‌رتبه انتخاب می‌کنیم. نام شما Bob است، و نام آن افسر Alice (چرا تعجب کردید؟ یک افسر عالی‌رتبه نمی‌تواند خانم باشد؟).

سوال: چرا Bob و چرا Alice؟ 

پاسخ: آلیس و باب در واقع دو عضو از یک خانواده‌ی بزرگ هستند تحت عنوان خانواده‌ی کاراکترهای رمزنگاری! به صورت واضح تر، در سال 1978 یکی از اساتید دانشگاه MIT به نام رونالد ریوست، در مقاله ای که برای ارائه‌ی الگوریتم رمزنگاری RSA آماده کرده بود، از این اسامی برای مثال‌های خود به عنوان فرستنده و گیرنده‌ی پیام استفاده کرد. بعدها در دیگر سناریوهایی که طراحی شد، این اسامی شهرت یافتند و کم کم کاراکترهای دیگری هم به جمع آن‌ها پیوستند. برای رعایت این رسم، ما نیز در سناریوی خود همین کاراکترها را به کار می‌بریم. به عنوان یک مطلب اضافه، حرف R در الگوریتم RSA، از فامیل آقای Rivest گرفته شده است. دو حرف دیگر هم از نام دو طرِاح دیگر الگوریتم آمده اند.

دکتر ریوست (نفر وسط)

خب، تصمیم باب بر این شده است که در یک نامه، دستورات خود را به آلیس عزیزش در میدان نبرد ابلاغ کند.

اما بیایید پیش از آنکه اتفاقات و راهکارهایی که "باب" و "آلیس" استفاده کردند را بیان کنیم، خودمان بررسی کنیم و ببینیم که چه مسائلی باید در نظر می‌گرفتند؟ [بعدها خواهیم دید این مسائل مبنای امنیت یک خط ارتباطی را تشکیل می‌دهند]:

1. "باب" و "آلیس" باید به نحوی در نامه هایشان، خود را به گونه‌ای به یکدیگر معرفی کنند که هر کدام هنگام دریافت نامه‌ی دیگری بتواند مطمئن شود که نامه از جانب همان شخصی آمده است که باید بیاید. حتی در صورتی که نیروهای دشمن رونوشتی را که هفته‌ی پیش در کاروان‌سرای بین راه از نامه‌ی قاصد تهیه کردند جایگزین نامه‌ی امروز قاصد کنند، دریافت کننده باید متوجه معتبر نبودن آن بشود. [بعد ها این بند را با نام Authenticity خواهید شناخت]
2. در صورتی که نیروهای دشمن در میانه‌ی مسیر قاصد را تطمیع کردند یا به قتل رساندند و به دستوراتِ "باب" یا گزارشِ "آلیس" دست یافتند، نباید از آن چیزی متوجه شوند! [بعد ها این بند را با نام Confidentiality خواهید شناخت]
3. در صورتی که نیروهای دشمن در کاروان سراهای میان راه کمین کردند و نامه‌ اصلیِ قاصد را دزدیدند و محتوای آن را عوض کردند یا نامه‌ی جدیدی که خودشان نوشته اند جایگزین آن کردند، دریافت کننده‌ی نامه‌ی جدید باید متوجه جعلی بودن آن بشود. [بعد ها این بند را با نام Integrity خواهید شناخت]
4. چنانچه "باب" دستوری به آلیس فرستاد و مثلا به وی فرمانِ "حمله" داد و آلیس بعد از خواندن دستور، به خاطر ترس یا ... به آن عمل نکرد، بعدها نباید بتواند ادعا کند که نامه را دریافت نکرده است! همینطور اگر "باب" در موقیعت مشابهی، مثلا در حالت مستی، تصمیم اشتباهی گرفت و فرمانی صادر کرد و به آلیس فرستاد و اجرای آن تصمیمِ اشتباه منجر به اتفاق بدی شد که آبروی "باب" را به خطر می‌انداخت، وی نباید قادر به این باشد که ارسال آن دستور را انکار کند. [بعد ها این بند را با نام Non-Repdiation خواهید شناخت]
5. قاصد و اسب پر انرژی اش همیشه باید در دسترس "باب" و آلیس باشد. [بعد ها این بند را با نام Availability خواهید شناخت]

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

قسمت بعدی: الگوریتم‌های سزار/Caesar و اِنیگما/Enigma

---

To be yourself in a world that is constantly trying to make you something else is the greatest accomplishment.

Ralph Waldo Emerson

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

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

---

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

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

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

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

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

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

---

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

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

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