Back

ⓘ SMIME - RFC 5322 Starndardi. SMIME eshte plotesim i MIME ne aspektin e sigurise, mbeshtetet kryesisht ne teknologjine qe perdoret edhe nga RSA Data Security. SM ..




                                     

ⓘ S/MIME - RFC 5322 Starndardi

S/MIME eshte plotesim i MIME ne aspektin e sigurise, mbeshtetet kryesisht ne teknologjine qe perdoret edhe nga RSA Data Security. S/MIME njesoj si PGP bejne pjese ne IETF standardet. Perderisa PGP-ja kryesisht perdoret per sigurine e e-mail-ave personal te shume shfrytezuesve, S/MIME paraqitet si standard industrial per perdorim komercial. S/MIME definohet permes disa dokumenteve, me te rendsishmet jane RFC-te: 3370, 3850, 3850, 3852, 3852. Para se te sqarohet S/MIME duhet kuptuar formati i e-mail-ve mbi te cilet mbeshtetet ajo – MIME. Formati tradicional i electronic mail mesazhve pershkruhet permes standarteve RFC 822 dhe versionit RFC 5322.

                                     

1. MIME – Multipurpose Internet Message Extensions

MIME eshte vazhdim i RFC 5322 dhe si ka si per qellim adresimin e disa problemeve dhe kufizimeve qe shfaqen si pasoje e SMTP e definuar ne RFC 821 dhe specifikacioneve qe vinje nga RFC 5322.

Kufizimet qe sjellin skemat SMTP/RFC 5322 jane:

  • Pamundesia qe permes SMTP te barten fajllat ekzekutiv.exe apo objekte tjera te dhena vetem ne forme binare. Ekzistojne disa skema te konvertimit te fajllave binare ne tekstual, te cilet pastaj mund te barten permes SMTP sistemit tone. Nder skemat me te njohura eshte UNIX Uencode/Udecode, megjithate asnjera nga modelet e perdorura nuk eshte e standardizuar,mbeshtetet ne karaktere ASCII 7 bit, pra nuk mundeson dergimin/pranimin te dhenave tekstuale qe kodohen me 8 bita.
  • SMTP portat hyrese/dalese qe perkthejne karakteret ASCII ne EBCDIC karaktere nuk perdorin mapim te qendrueshem prandaj shfaqen probleme ne perkthim.
  • Disa implementime te SMTP nuk jane plotesisht te definuara ne SMTP standardet – RFC 821. Probleme te zakonshme qe shfaqen ne kete rast jane
  • SMTP serveret mund te mos pranojne mesazhe qe kalojne nje madhesi te caktuar.
  • Paddingu i rreshtave ashtu qe rreshtat te kene numer te njejte te karaktereve.
  • Kalimi ne rresht te ri, per te respektuar gjatesine maksimale te rreshitit qe eshte 76 karaktere.
  • Heqja e hapeirave te zbrazeta ne fund tab dhe space karaktereve
  • Fshirja, shtimi apo rirenditja e carriage returns dhe line feeds.
  • Shnderrimi i tab karaktereve ne disa space karaktere.
                                     

1.1. MIME – Multipurpose Internet Message Extensions MIME

MIME mundeson zgjidhjen e ketyre problemeve ashtu qe zgjidhjet e ofruara te jene kompatibile me implmentimet e RFC 5322.

MIME specifikacionet permbajne keto elemente:

  • Transfer encoding ben te mundur shnederrimin e permabjtjes se mesazhit ne nje forme e cila nuk do te ndryshohet nga mail sistemi.
  • Jane definuar 5 fusha te reja headeri te cilat mund te perfshihen ne RFC 5322. Keto fusha permbajne informatat e nevojshme per brendine e mesazhit.
  • Jane definuar nje numer i caktuar i formateve te permabjtjeve contents duke standardizuar formen se si do te paraqiten te dhenat.

5 fushat e header-it te definuara ne MIME jane:

  • Content Transfer Encoding – tregon se qfare forme eshte perdorur per enkodimin e tekstit.
  • Content Type – definon tipin te dhenave qe perdoren ne body. Tipi edhe nentipi shkruhet ne formen tipi/nentipi.
  • MIME Version – definon versionin e MIME-se qe perdoret
  • Content ID – identifikon ne menyre unike mesazhin.
  • Content Description – pershkruan te dhenen qe gjendet ne trupin e mesazhit.

Keto fusha mund te gjenden ne nje header te mesazhit te shkruar sipas RFC 5322. Nje implementim i mirefillt i ketij standardi duhet te perkrahe fushat MIME Version, Content Type si dhe Content Transfer Encoding; fushat Content ID dhe Content Description jane opcionale. Per shkak te shume llojshmerise se permbajtjeve ka lind nevoja per nje klasifikim te ketyre formave. Permes RFC 2046 jane percaktuar 7 tipe kryesore te permajtjes te ndara ne gjithsej 15 nentipe, ku Content Type pershkruan tipin te dhenave kurse Content Subtype formatin e atyre te dhenave.

  • Text – ky eshte tipi me i thjeshte i te dhenave,dallohen dy nentipe: plain dhe enriched,perderisa text/plain paraqet tekst te paformatizuar, karakteret jane konform standardit ASCII apo ISO 8857, text/enriched mundeson fleksibilitet me te madh duke ofruar mundesi per formatizim te tekstit.
  • Multipart – tregon se trupi i mesazhit perbehet nga pjese te pavarura mes veti,kur vlera e Content Type eshte multipart ajo fushe permbane edhe nje parameter tjeter te quajtur boundary qe tregon kurfirin mes pjeseve te pavarura,ky kufi nuk paraqitet ne asnjeren nga pjeset e mesazhit,secili boudery fillon me nje rresht te ri, dy vija lidhese pastaj shkruhet vlera e boudery-t emri i tij i definuar ne header,boudery i fundit qe tregon perfundimin e pjeses se fundit dallon nga boudery-t e zakonshem sepse perfundon me dy vija lidhese,brenda seciles pjese se pavarur mund te perfshihet nje MIME header i zakonshem, por kjo nuk eshte e domosdoshme.
  • Multipart/Mixed – perdoret per lidhjen me shume pjeseve te pavarura mes veti te cilat duhet te shfaqen ne nje renditje te caktuar.
  • Multipart/Parallel – renditja e pjeseeve te lidhura nuk eshte me rendesi, ato mund te shfaqen paralelisht, p.sh. nje fotografi apo nje tekst mund te shoqerohet nga nje audio e cila degjohet ne kohen kur per shfrytezuesin shfaqet fotografia apo teksti.
  • Multipart/digest – perdoret kur pjeset e veqanta ne trupin e mesazheve interpretohen si mesazhe konform RFC 5322 standardit. Kjo muneson ndertimin e mesazheve qe ne vete permbajne mesazhe tjera.
  • Multipart/Alternative – pjeset e lidhura jane reprezentim i te njejtit informacion. Renditja e tyre behet ne baze te performansave, ku me larte vendoste pjesa qe ofron performansa me te larta, p.sh ne qofte se eshte e mundur shfaqja e tekstit ne formatin text/enriched behet kjo gje, ne te kunderten teksti shfaqet ne formatin text/plain.
  • Message – pjesa qe gjendet ne trupin e mesazhitbody eshte vet nje mesazh i plote sipas RFC 822 qe ka header-in e vet me Content-type tjeter.
  • Message/partial – perdoret kur mesazhi origjinal duhet te fragmentohet per arsye te madhesise, kurse kjo eshte vetem njera nga pjeset e mesazhit. Te gjitha fragmentet e mesazhit origjinal duhet te rigrupuhen ne destinacion nga MIME, per kete arsye nevojiten tre parametra shtese qe jane: ID – eshte e njejte per te gjitha pjeset e fragmentuara, sequence number – unike per secilen pjese dhe total – numri i pergjithshem i fragmenteve.
  • Message/external-body – perdoret sidomos ne rastet kur trupi i mesazhit behet shume i madh, atehere ne trup body vendoset vetem pointeri qe na dergon te objekti i cili ekziston diku tjeter. Trupi i mesazht ne kete rast permabane vetem informatat e nevojshme per qasje ne te dhena. Ky nentip ka nje header te jashtem dhe mesazhin e enkapsuluar qe permbane header-in e vet brendshem. Fusha e jashtme e header-ti Content-Type duhet te permbaje nje parameter te qasjes qe tergon metoden e qasjes, p.sh FTPFile Transfer Protocol.
  • Message/rfc822 – eshte nentipi kryesor qe tregon se trupi i mesazhit eshte nje tjeter mesazh i enkapsulur qe ka header-in dhe turpin e vet. Mesazhi i enkapsuluar ne kete rast mund te jete qfardo MIME mesazhi.
  • Application – perfshine te dhenat e tipeve tjera qe nuk u takojn tipeve te permendura me larte. Jane dy nentipe qe definohen per kete tip: octet stream dhe PostScript. Octet stream jane te dhena qe paraqiten ne formen binare, 8 bita per nje byte. Kurse PostScript perdoret kur te dhenat jane ne formtin Adobe PostScript qe do te shfrytezohen nga printer qe perkrahin PostScript formatin.
  • Audio – si nentip te vetem ka basic’. Perdoret kur mesazhi i derguar permbane ze.
  • Video – mesazhi paraqet animacion. Nentipi i vetem i ofruar eshte MPEG Motion Picture Experts Group. Ne qofte se imazhi i animuar permbane edhe ze, ai dergohet ndaras duke shfrytezuar tipin Audio.
  • Image – mesazhi origjinal permbane nje imazh statik,nuk ka animacione. Dy nentipe qe perdoren jane: JPEG Joint Photographic Experts Group dhe GIF Graphics Interchange Format.

Ne rastin kur fusha e header-it Content Type nuk eshte definuar ne menyre eksplicite per asrye te ndonje gabimi apo per shkak te versionit te MIME se pales derguese user agent, merret vlera e nenkuptuar: "Content-type: text/plain; charset=us-ascii".

                                     

1.2. MIME – Multipurpose Internet Message Extensions MIME Transfer Encodings

Fusha e header-it Content Transfer Encoding mund te pranoj gjashte vlera te ndryshme, ndonese vetem dy prej tyre paraqesin metoda per enkodimin te dhenave. Specifikacionet mbi enkodimin e mesazhit per te siguruar dergim te besushem te dhenave neper mjedise te ndryshme gjenden ne RFC 2045. Shumica te dhenave multimediale qe barten permes email-it jane te formatit binary, perkatesisht mund te parqaiten si karaktere 8 bitshe. Mirpo te dhena ne kete forme nuk mund te transmetohen permes disa protokoleve te caktuara; p.sh permes SMTP mund te transmetohen vetem ASCII karaktere si dhe gjatesia e rreshtave nuk duhet te jete me e madhe se 1000 karaktere. Prandaj eshte paraqitur nevoja per te per enkodimin te dhenave ashtu qe ato te plotesojne krtiteret e caktuara. Vlerat qe mund te marr fusha Content Transfer Encoding jane:

  • X-token – tregon se enkodimi eshte bere duke shfrytezuar nje skeme tjeter nga ato qe u permenden, ne kete rast jepet emri i asaj skeme.
  • 8 bit – rreshtat po ashtu jane te shkurterderi ne 1000 karaktere mirpo mund te paraqiten edhe karaktere qe nuk jane ASCII. Me qe shtresat e SMTP-se jane ne gjendje te bartin te dhenat ne kete format MIME nuk kryen fare enkodim ne kete rast.
  • 7 bit – te dhenat jane ASCII karaktere, vlera decmale e secilit karakter nuk e kalon 127, rreshtat duhet te kene maksimumi 1000 karaktere perfshire ketu edhe Carrige Return 13-vlera decimale dhe Line Feed 10-vlera decimale.
  • Quoted-Printable – njesoj si Base64 sherben per enkodimin e sekuencave binare, e dobishme sidomos kur te dhenat paraqesin numer te madh te okteteve qe korespondojne ne ASCII karaktere te printueshme. Eshte e dizajnuar qe te jete e lexueshme per njerezit per shkak se kryesisht perbehet nga ASCII karakteret, ndonese del edhe jasht tyre ndonjehere.
  • Base64 – perdoret per te enkoduar sekuenca arbitrare te okteteve binare ashtu qe te plotesojne rregullen e 7 bitave. Eshte mjaft e dobishme per te enkoduar te dhena binare dhe karaktere 8-biteshe, nganjehere perdoret per te enkoduar edhe te dhena tekstuale qe shpesh perdorin karaktere jo ASCII.
  • Binary – te dhenat e kesaj forme jo vetem qe permbajne karaktere jo ASCII por rreshta nuk jane domosdoshmerisht te shkurter si ne rastet e mesiperme. Me qe SMTP-ja eshte ne gjendje te dergoj/pranoj te dhena binare, MIME nuk kryen kurfar enkodimi as ne kete rast, megjithate kjo forme e shkembimit te dhenave nuk eshte e rekomandueshme.Perderisa format e permendura me lart nuk paraqesin enkodim, ato vetem i tregojne per natyren te dhenave. Permes Base64 dhe Quoted Printable behet transformi i te dhenave ne hyrje nga nje domen i qfardoshem ne karaktere 7 bitshe, duke i bere keshtu te sigurta’ per transport sidomos ndaj protokoleve me kufizime te larta.


                                     

2. S/MIME Funksionaliteti

S / MIME mund te perdoret me qfardo sistemi qe barte te dhena MIME, por poashtu mund te perdoret nga MUAs Mail User Agents tradicional per te ofruar sherbime kriptogarfike dhe te sigurise. S/MIME njesoj si PGP ofron mundesine per te nenshkruar dhe/ose enkriptuar te dhenat.

  • Sherbimet kriptogarfike dhe te sigurise qe ofron S/MIME jane
  • Autentifikimi
  • Priavtesia dhe siguria te dhenave
  • Jo-mohueshmeria Non-repudiation
  • Integritetin i mesazhit

Tri sherbimet e para arrihen permes nenshkrimit digjital kurse e fundit permes enkriptimit.

S/MIME bazohet ne Cryptographic Message Syntax CMS. S/MIME agjenti paraqet software-in e perdoruesit qe mund te jete ne rolin e derguesit te dhenave, pranuesit apo te dyja. Para se te perdoret celqsi publik permes te cilit arrihet komunikimi i sigurt palet duhet te vertetojne valditetin e tij, kjo arrihet duke perdorur PKIX X.509 Public-Key Infrastructure certifikatat. S/MIME punon me keto tipe te dhenave Content Type: Enveloped Data, Sign Data, Clear-Sign Data dhe Signed and Enveloped Data.

Enveloped Data – perdoret per tu ofruar privatesi mesazheve tona. Ky tip perbehet nga te dhena te enkriptuara apo celesa te enkriptuar qe do te perdoren per enkriptim nga nje apo me shume shfrytezues. Kombinimi i permbajtjes se enkripuar dhe celesave per enkriptim qejane poashtu te enkriptuar njihet si digital envelope zarfi digjial.Procesi permes se cilit arrihet perfitimi i enveloped data perfshine:
  • Informata e enkriptuar ju shtohet te dhenave specifike per marresin dhe se bashku japin vleren e EnvelopedData. Ky informacion pastaj enkodohet ne Base64.
  • Behet enkriptimi i permabjtjes me celesin e gjeneruar.
  • Gjenerimin e nje celesi per enkriptim pseudo-random session key.

Pranuesi fillimisht ben dekodimin nga Base64, pastaj nga nje pjese e mesazhit dekripton celesin e sesionit permes celesit te vet privat. Kete celes te sesionit pastaj e shfrytezon per te dekriptuar mesazhin qe e ka pranuar. Kjo ndonese siguron privatesi, nuk siguron autentifikim.

Signed Data – paraqet te dhenat e nenshkruara nga derguesi. Qfardo tipi i te dhenave mund te nenshkruhet nga nje apo me shume nenshkrues paralelisht. Procesi i konstruktimit te dhenave te nenshkruara eshte si me poshte:
  • Gjendet hash-i mesazhit duke perdorur nje Hash algoritem
  • Mesazhi bashke me nenshkrimin digjital enkodohen ne Base64
  • Enkriptohet hashi i mesazhit me celesin privat te derguesit – fitohet nenshkrimi digjital

Pranuesi dekripton nenshkrimin digjital me celesin publik te derguesit pastaj hashin e fituar e krahason me hashin qe e ka llogaritur nga mesazhi i pranuar. Ne qofte se keto dy vlera jane te njejta pranuesi sigurohet se mesazhi eshte derguar nga pala qe pretendon se ka derguar ate dhe mesazhi nuk eshte ndryshuar gjate rruges.

Clear-Signed Data – procesi i formimit te nenshkrimit digjital eshte i njejte si ne rastin per Signed Data, i vetmi dallim eshte se ne procesin e enkodimit ne Base64 hyn vetem nenshkrimi digjital jo edhe mesazhi. Signed and Enveloped Data – nenshkrimi dhe enkriptimi i te dhenave mund te behet ndaras pastaj hasen kombiinime te tyre. Keshtu te dhenat e enkriptuara mund te nenshkruhen, poashtu te dhenat e nenshkruara signed data apo clear-signed data mund te enkriptohen.
                                     

3. RFC 5322

RFC 5322 definon sintaksen e mesazheve qe dergohen nga shfrytezuesit fundor computer users si electronik mail. Kjo rfc eshte rishikim i rfc 2882 qe eshte zevendesim i rfc 822" Standard for the Format of ARPA Internet Text Messages”. Ky standard mesazhet i sheh te perbera nga dy pjese: envelope zarfi dhe content permbajtja. Envelope permbane informatat e nevojshme qe mundesojne bartjen dhe dergimin e mesazhit te marresi, kurse content paraqet te dhenat qe do ti dergohen marresit. Standardi RFC 5322 pershkruan vetem formatin e permbajtjes content se mesazhit megjithate edhe ajo permbane disa fusha header qe mund te perdoren nga mail sistemi per te krijuar zarfin envelope. Ky dokument nuk percakton menyren e bartjes se te dhenave tekstuale, imazheve, audiove apo te dhenave tjera te strukturuara permes e-mail –it. Keto specifikacione gjenden ne MIME serine e RFC-ve: 2045.2046 dhe 2049. Struktura e nje mesazhi sipas konditave te RFC 5322 eshte mjaft e thjeshte. Nje mesazh tipik perbehet nga header-i dhe body. Header-i mund te permbaje disa rreshta, kurse trupi i mesazhit body permabane qfardo teksti te pakufizuar. Nje rresht i header-it perbehet nga nje fjale kyqe e shoqeruar nga dy pika":” si dhe argmenti perkates i fjales kyqe. Nese rreshti eshe shume i gjate ai mund te ndahet ne disa rreshta. Si fjale kyqe zakonisht hasen: Message ID – kjo fushe identifikon e menyre unike secilin mesazh, From, To, Subject, Date etj.