سلام.
به پیشنهاد یکی از دوستان، گروهی در زمینه ی جاواکارت و سیمکارت با هدف اشتراک دانش، ابزارها و مستندات تشکیل دادیم. چنانچه تمایل به عضویت در گروه داشتید شماره خودتون رو به بنده ارسال کنید.
09397269578
سلام.
به پیشنهاد یکی از دوستان، گروهی در زمینه ی جاواکارت و سیمکارت با هدف اشتراک دانش، ابزارها و مستندات تشکیل دادیم. چنانچه تمایل به عضویت در گروه داشتید شماره خودتون رو به بنده ارسال کنید.
09397269578
قسمت قبلی: برنامه نویسی جاواکارت در Netbeans
در قسمت قبل دیدیم که نسخههای جدید محیط برنامه نویسی Netbeans، به صورت پیشفرض، Pluginها و APIهای مورد نیاز برای برنامه نویسی جاواکارت را در خود دارند. متاسفانه در مورد محیط برنامه نویسی Eclipse اینگونه نیست (نویسنده از نسخهی جدید این نرم افزار اطلاع ندارد). بنابراین نیاز است که برنامه نویس خودش Plugin و APIهای مورد نیاز را به آن بیفزاید.
سوال: IDE چیست؟ Plugin چیست؟ API چیست؟
پاسخ: IDE یا Integrated Development Environment یا محیط برنامه نویسی در واقع نرم افزارهایی مانند Netbeans، Eclipse یا Visual Studio هستند که فضایی را برای برنامه نویس فراهم میآوردند که برنامههای خود را به صورت راحت تر بنویسد و Compile/Interpret کند.
API یا Application Programming Interface یا رابط برنامه نویسی نرم افزار، در واقع مجموعه ای از واسط/رابط ها بین برنامه ای که قرار است نوشته شود با کتابخانههای آن زبان یا سیستم عامل هستند. یکی از قابلیتهایی که IDE دارد این است که هنگام نوشتن برنامه و استفاده از این رابط های برنامه نویسی در کد برنامه، به صورت اتوماتیک چک میکند که آیا چنین رابطی وجود دارد یا خیر، و اگر موجود نبود، به برنامه نویس خطای استفاده از APIهای اشتباه میدهد و یا به وی کمک میکند آن را اصلاح کند. (بنابراین باید APIهای لازم را به محیط برنامه نویسی معرفی/اضافه کنیم).
و نهایتا Plugin مجموعه ای فایل است که برای یک نرم افزار مانند IDE نوشته شده اند که به آن قابلیتی اضافه کنند.
به صورت روشن تر، وقتی ما JCDK را از سایت Oracle دانلود میکنیم، همهی APIها و ابزارهای مورد نیاز برای نوشتن و ساخت یک اپلت در آن مجموعه وجود دارد. یعنی میتوانیم بدون استفاده از هیچگونه IDE ای، اپلت خود را بنویسیم و فایل cap آن را تولید کنیم! منتهی باید با Notepad یا ابزاری مشابه آن، و یک مجموعه ابزارهای خط فرمانی دست و پنجه نرم کنیم، و هیچ گونه هشداری به ما در مورد نوشتن یک اسم API اشتباه یا خطاهای مانند آن به ما داده نمی شود، و تنها در مراحل پایانی، هنگام Compile/Interpret به واسطه ی اجرا نشدن موفق فرایند، متوجه وجود یک خطا در برنامه میشویم. کاری که IDE با Plugin هایش برای ما انجام میدهد، مکانیزه کردن کل این فرایندها و مخفی کردن ابزارهای خط فرمانی و مراحل آن ها، در پس چند کلیک ساده است.
Eclipse:
خب، برای شروع، ابتدا Eclipse و سپس Java Card Development Kit 2.2.2 و پلاگین Eclipse-JCDE را دانلود میکنیم.
نکتهی مهم اول: Eclipse و Java Development Kit و Java Card Development Kit 2.2.2 و Windows چهار مورد باید یا 32 بیتی باشند یا 64 بیتی. تفاوت یکی از این موارد با موارد دیگر موجب ناسازگاری مجموعه میشود و عدم کارکرد صحیح میشود.
نکتهی مهم دوم: همانطور که پیشتر گفته بودیم، پلاگین Eclipse-JCDE تنها برای JCDK2.2.2 نوشته شده است. بنابراین شما باید این نسخه از JCDK را دانلود کنید. (با ترفندی میتوان از نسخه های پایین تر نیز استفاده کرد؛ لیکن، برای اجرای آن ترفندها، همچنان به نسخهی 2.2.2 نیز نیاز است).
اما بعد؛ پس از دانلود موارد بالا:
پست قبلی: الگوریتم های سزار و اِنیگما
در پست های قبلی این مجموعه، ابتدا با الگوریتمهای درهمنگاری(Hash) و الگوریتمهای Encoding/Decoding آشنا شدیم، تفاوت آنها را با الگوریتم های رمزنگاری (Encryption/Decryption) بررسی کردیم و در نهایت پس از بررسی مقدمات توسعهی رمزنگاری و علل نیاز به آن، در این پست قرار است به تقسیمبندی های الگورتیم های رمزنگاری امروزی بپردازیم.
قسمت قبلی: نسخههای جاواکارت و اصطلاحات
در قسمت های پیشین با ساختار کلّی جاواکارت و مفاهیم ابتدایی ضروری آن آشنا شدیم و دانستیم که برای آغاز به نوشتن یک اپلت و تبدیل آن به فایل cap. (فایلی که روی کارت بارگذاری و نصب میشود) ابتدا به یک IDE (محیط برنامه نویسی)، یک مجموعه API (واسط های از پیش نوشته شدهی JCDK , JDK)، یک ابزار برای بارگذاری و نصب اپلت و نهایتا یک ابزار برای ارتباط با آن نیاز داریم. در این قسمت مراحل نوشتن اپلت و تولید فایل cap. را در محیط Netbeans بررسی میکنیم.
Netbeans:
طبق آنچه پیش تر گفته شد، برنامه نویسی برای جاواکارت در محیط Netbeans، برای مواقعی مناسب از که کارت مورد نظر ما از نسخه ی جاواکارت 3.0.1 یا بالاتر پشتیبانی کند. البته لازم به ذکر است که به سبب Backward Compatible بودن استانداردهای جاواکارت، نوشتن اپلت هایی برای کارت های از ورژن پایین تر نیز در محیط Netbeans امکان پذیر است و حتی میتوان از آنها فایل cap. تولید کرد و در Simulatorهای این IDE آنها را بررسی کرد، لیکن، ورژن فایل نهایی 3.0.1 خواهد بود و قابلیت بارگذاری روی کارت پایین تر را نخواهد داشت.
و اما روند نوشتن و تولید اپلت:
پس از اجرای Netbeans، از منوی File گزینهی New Project را انتخاب میکتیم تا پنجره ی زیر ظاهر شود:
طبق تصویر بالا از سمت چپ گروه Java Card (چنانچه این گزینه را ندارید، باید نسخهی جدیدتری از Netbeans را دریافت کنید یا پلاگین های مربوطه را دانلود و نصب کنید) و از سمت راست نوع پروژه را Classic Applet Project (جهت آشنایی به قبلی آموزش مراجعه کنید) انتخاب میکنیم و روی Next کلیک میکنیم تا پنجرهی زیر ظاهر شود:
حالا که قدرتِ درک و تحلیلِ درخواستهای HTTP را به دست آوردیم، میخواهیم با این تواناییِ جدید، به سایتِ دیوار سر بزنیم و چند درخواست را با همدیگر تحلیل کنیم.
برای شروعِ کار، ابتدا همهی کوکیهای خود را که روی دیوار هستند پاک میکنیم.
در پست قبل یک سناریو تعریف کردیم که در آن "باب" و "آلیس"، پادشاه و فرماندهی زبده اش، در شرایطی قرار گرفته اند که باید مدام از طریق نامه تصیمات مهم جنگی خود را مبادله کنند؛ آنگاه آمدیم و معیارهایی را که از نظر ما، باید در مورد نامههای خود در نظر میگرفتند را بیان کردیم. حال میپردازیم به آنچه که واقعا گذشت ...
الگوریتم سزار:
"باب" جلسه ای دو نفره و محرمانه با "آلیس" تشکیل داد و با او در مورد نحوهی ارسال نامه ها مشورت کرد. چیزی که در ابتدا باب میخواست این بود که هیچ کسی جز آلیس قادر به فهمیدن محتوای نامه و دستورات نباشد. در این جلسه تصمیم باب و آلیس بر این شد که در متن نامه به جای هر حرف، حرف سه جایگاه قبل تر را جایگزین کنند. به این صورت که به جای A حرف X، به جای B حرف Y و ...
با روند فوق که در اصل یک نوع انکدینگ به حساب میآید (زیرا به نوعی فرمت حروف عوض شده است، و در صورتی که الگوریتم فاش شود، چیزی به عنوان کلید لازم نداریم و هر کسی میتواند داده ها را به حالت اولیه بازگرداند) به ظاهر محرمانگی نامههای تبادلی تضمین میشود، اما چیزی که بعدها باب و آلیس کشف کردند این بود که در نامه هایی نهایی درصد تکرار حروف میتواند باعث فاش شدن متن اصلی شود. یعنی از آنجا که پر تکرار ترین حرف انگلیسی E است، در نامه های رمز شده، پرتکرارترین حرف را اگر با E جایگزین کنیم، به متن اصلی نزدیک میشویم. به همین ترتیب تک حروف های منفرد، به احتمال زیاد یا I هستند یا A. این قبیل نتیجه گیری ها که همگی به علت یکسان نبودن احتمال ظاهر شدن حروف مختلف در خروجی نهایی نامه هاست، به سادگی میتوانست موجب رمزگشایی نامهها شود و بنابرین آلیس و باب باید به دنبال راهکار دیگری میبودند ...
[پایان داستان باب و آلیس!!!/به علت زیاد بودن مطالب]
شکل: نسبت تکرار حروف مختلف در یک متن انگلیسی
نکته: در دنیای رمزنگاری، الگوریتم فوق به نام الگوریتم سزار معروف است، زیرا برای اولین بار ژولیوس سزار پادشاه رومی برای ارتباط با فرماندهانش استفاده شد. از نام های دیگر آن میتوان به Shift Cipher، Caesar Code و Caesar shift اشاره کرد.
ماشین Enigma:
پس از الگوریتم سزار، دومین روش مشهوری که در روند توسعهی رمزنگاری وجود دارد، ماشین انیگما است. این وسیلهی سخت افزاری توسط آلمانها در جنگ جهانی دوم ابداع و استفاده شد.
جهت اطلاع دقیق از نحوه ی عملکرد این دستگاه میتوانید به این بخش از ویکیپدیا مراجعه کنید. ولی در نهایت خروجی های این دستگاه نیز توسط دانشمندان وابسته به متفقین رمزشکنی شد و رفته رفته گامهایی به سوی الگوریتم هایی مبتنی بر عملیات های ریاضی قویتر برداشته شد.
قسمت بعدی: بررسی تقسیم بندی الگوریتمهای رمزنگاری
قسمت قبلی: ابزارهای مورد نیازقسمت قبلی: ابزارهای مورد نیاز
در پست قبلی اشاره کردیم که انتخاب ابزار کار مورد نیاز (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
قسمت قبلی: مشکلات مربوط به 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 گرفته شده است. دو حرف دیگر هم از نام دو طرِاح دیگر الگوریتم آمده اند.
دکتر ریوست (نفر وسط)
خب، تصمیم باب بر این شده است که در یک نامه، دستورات خود را به آلیس عزیزش در میدان نبرد ابلاغ کند.
اما بیایید پیش از آنکه اتفاقات و راهکارهایی که "باب" و "آلیس" استفاده کردند را بیان کنیم، خودمان بررسی کنیم و ببینیم که چه مسائلی باید در نظر میگرفتند؟ [بعدها خواهیم دید این مسائل مبنای امنیت یک خط ارتباطی را تشکیل میدهند]:
قسمت قبلی: من یک جاواکار نیستم!
در این قسمت، به عنوان ادامهای بر مباحث پیشین، ابزارهایی که از آغاز به نوشتن یک اپلت تا نصب آن روی کارت و ارتباط با آن نیاز است را معرفی میکنیم. در یک دید کلّی، ابزارهای مورد نیاز به دو دسته تقسیم میشوند: