S/MIME - RFC 5322 Starndardi

Shtoni lidhje
Nga Wikipedia, enciklopedia e lirë

S/MIME[Redakto | Redakto nëpërmjet kodit]

S/MIME është plotësim i MIME (Multipurpose Internet Mail Extensions) në aspektin e sigurisë, mbështetet kryesisht në në teknologjinë që përdoret edhe nga RSA Data Security. S/MIME njësoj si PGP bëjnë pjesë në IETF standardet. Përderisa PGP-ja kryesisht përdoret për sigurinë e e-mail-ave personal të shumë shfrytëzuesve, S/MIME paraqitet si standard industrial për përdorim komercial. S/MIME definohet përmes disa dokumenteve, më të rëndsishmet janë RFC-të : 3370, 3850, 3850, 3852, 3852. Para se te sqarohet S/MIME duhet kuptuar formati i e-mail-ve mbi te cilet mbështetet ajo – MIME. Formati tradicional i electronic mail mesazhve pershkruhet përmes standarteve RFC 822 dhe versionit RFC 5322 ( Internet Message Format).

MIME – Multipurpose Internet Message Extensions[Redakto | Redakto nëpërmjet kodit]

MIME është vazhdim i RFC 5322 dhe si ka si për qëllim adresimin e disa problemeve dhe kufizimeve që shfaqen si pasojë e SMTP e definuar në RFC 821 dhe specifikacioneve që vinjë nga RFC 5322.

Kufizimet që sjellin skemat SMTP/RFC 5322 janë:

  1. Pamundësia që përmes SMTP të barten fajllat ekzekutiv (.exe ) apo objekte tjera të dhëna vetëm në formë binare. Ekzistojnë disa disa skema të konvertimit te fajllave binarë në tekstual, të cilët pastaj mund të barten përmes SMTP sistemit tonë. Ndër skemat më të njohura është UNIX Uencode/Udecode, megjithatë asnjëra nga modelet e përdorura nuk është e standardizuar,mbështetet në karaktere ASCII (7 bit), pra nuk mundëson dërgimin/pranimin e të dhënave tekstuale që kodohen me 8 bita.
  2. SMTP serverët mund të mos pranojnë mesazhe që kalojnë një madhësi të caktuar.
  3. SMTP portat hyrëse/dalëse që përkthejnë karakteret ASCII në EBCDIC karaktere nuk përdorin mapim të qëndrueshëm prandaj shfaqen probleme në përkthim.
  4. Disa' implementime të SMTP nuk janë plotesisht të definuara në në SMTP standardet – RFC 821. Probleme te zakonshme që shfaqen në këtë rast janë:
  • Fshirja, shtimi apo rirenditja e carriage returns dhe line feeds.
  • Kalimi në rresht të ri, për të respektuar gjatësinë maksimale të rreshitit që është 76 karaktere.
  • Heqja e hapëirave të zbrazëta në fund ( tab dhe space karaktereve)
  • Paddingu i rreshtave ashtu që rreshtat të kenë numër të njejtë të karaktereve.
  • Shndërrimi i tab karaktereve ne disa space karaktere.

MIME[Redakto | Redakto nëpërmjet kodit]

MIME mundëson zgjidhjen e këtyre problemeve ashtu që zgjidhjet e ofruara të jenë kompatibile me implmentimet e RFC 5322.

MIME specifikacionet përmbajnë këto elemente:

  1. Jane definuar 5 fusha te reja headeri të cilat mund të përfshihen në RFC 5322. Këto fusha përmbajnë informatat e nevojshme për brendinë e mesazhit.
  2. Janë definuar një numër i caktuar i formateve të përmabjtjeve (contents) duke standardizuar formën se si do të paraqiten të dhënat.
  3. Transfer encoding bën të mundur shnëdërrimin e përmabjtjes së mesazhit në një formë e cila nuk do të ndryshohet nga mail sistemi.

5 fushat e header-it të definuara në MIME janë:

  • MIME Version – definon versionin e MIME-së që përdoret
  • Content Type – definon tipin e të dhënave që përdoren në body. Tipi edhe nëntipi shkruhet në formën tipi/nëntipi.
  • Content Transfer Encoding – tregon se qfarë forme është përdorur për enkodimin e tekstit.
  • Content ID – identifikon në mënyrë unike mesazhin.
  • Content Description – përshkruan të dhënën që gjendet në trupin e mesazhit.

Këto fusha mund të gjenden në një header të mesazhit të shkruar sipas RFC 5322. Një implementim i mirëfillt i këtij standardi duhet të përkrahë fushat MIME Version, Content Type si dhe Content Transfer Encoding; fushat Content ID dhe Content Description janë opcionale. Për shkak të shumë llojshmërisë së përmbajtjeve ka lind nevoja për një klasifikim të këtyre formave. Përmes RFC 2046 janë përcaktuar 7 tipe kryesore të përmajtjes të ndara në gjithsej 15 nëntipe, ku Content Type përshkruan tipin e të dhënave kurse Content Subtype formatin e atyre të dhënave.

  1. Text – ky është tipi më i thjeshtë i të dhënave,dallohen dy nëntipe: plain dhe enriched,përderisa text/plain paraqet tekst të paformatizuar, karakteret janë konform standardit ASCII apo ISO 8857, text/enriched mundëson fleksibilitet më të madh duke ofruar mundësi për formatizim të tekstit.
  2. Multipart – tregon se trupi i mesazhit përbëhet nga pjesë të pavarura mes veti,kur vlera e Content Type është multipart ajo fushë përmbanë edhe një parametër tjetër të quajtur boundary që tregon kurfirin mes pjesëve të pavarura,ky kufi nuk paraqitet në asnjërën nga pjesët e mesazhit,secili boudery fillon me me një rresht të ri, dy vija lidhëse pastaj shkruhet vlera e boudery-t (emri i tij i definuar ne header),boudery i fundit që tregon përfundimin e pjesës së fundit dallon nga boudery-t e zakonshëm sepse perfundon me dy vija lidhëse,brenda secilës pjesë se pavarur mund të përfshihet një MIME header i zakonshem, por kjo nuk është e domosdoshme.
  • Multipart/Mixed – përdoret për lidhjen e më shumë pjesëve të pavarura mes veti të cilat duhet të shfaqen në një renditje të caktuar.
  • Multipart/Parallel – renditja e pjesëeve të lidhura nuk është me rëndësi, ato mund të shfaqen paralelisht, p.sh. një fotografi apo një tekst mund të shoqërohet nga një audio e cila dëgjohet në kohën kur për shfrytëzuesin shfaqet fotografia apo teksti.
  • Multipart/Alternative – pjesët e lidhura janë reprezentim i të njëjtit informacion. Renditja e tyre bëhet në bazë të performansave, ku më lartë vendoste pjesa që ofron performansa më të larta, p.sh në qoftë se është e mundur shfaqja e tekstit në formatin text/enriched bëhet kjo gjë, në të kundërtën teksti shfaqet në formatin text/plain.
  • Multipart/digest – përdoret kur pjesët e veqanta në trupin e mesazheve interpretohen si mesazhe konform RFC 5322 standardit. Kjo munëson ndërtimin e mesazheve që në vete përmbajnë mesazhe tjera.
  1. Message – pjesa që gjendet në trupin e mesazhit(body) është vet një mesazh i plotë sipas RFC 822 që ka header-in e vet me Content-type tjetër.
  • Message/rfc822 – është nëntipi kryesor që tregon se trupi i mesazhit është një tjeter mesazh i enkapsulur që ka header-in dhe turpin e vet. Mesazhi i enkapsuluar në këtë rast mund të jetë qfardo MIME mesazhi.
  • Message/partial – përdoret kur mesazhi origjinal duhet të fragmentohet për arsye të madhësisë, kurse kjo është vetëm njëra nga pjesët e mesazhit. Të gjitha fragmentet e mesazhit origjinal duhet të rigrupuhen në destinacion nga MIME, për këtë arsye nevojiten tre parametra shtesë që janë: ID – është e njëjtë për të gjitha pjesët e fragmentuara, sequence number – unike për secilën pjesë dhe total – numri i përgjithshëm i fragmenteve.
  • Message/external-body – përdoret sidomos në rastet kur trupi i mesazhit bëhet shumë i madh, atëherë në trup (body) vendoset vetëm pointeri që na dërgon te objekti i cili ekziston diku tjetër. Trupi i mesazht në këtë rast përmabanë vetëm informatat e nevojshme për qasje në të dhëna. Ky nëntip ka një header të jashtëm dhe mesazhin e enkapsuluar që përmbanë header-in e vet (brendshëm). Fusha e jashtme e header-ti Content-Type duhet të përmbajë një parametër të qasjes që tergon metodën e qasjes, p.sh FTP(File Transfer Protocol).
  1. Image – mesazhi origjinal përmbanë një imazh statik,nuk ka animacione. Dy nëntipe që përdoren janë: JPEG (Joint Photographic Experts Group) dhe GIF (Graphics Interchange Format).
  2. Video – mesazhi paraqet animacion. Nëntipi i vetëm i ofruar është MPEG (Motion Picture Experts Group). Në qoftë se imazhi i animuar përmbanë edhe zë, ai dërgohet ndaras duke shfrytëzuar tipin Audio.
  3. Audio – si nëntip të vetëm ka ‘basic’. Përdoret kur mesazhi i dërguar përmbanë zë.
  4. Application – përfshinë të dhënat e tipeve tjera që nuk u takojn tipeve të përmendura më lartë. Janë dy nëntipe që definohen për këtë tip: octet stream dhe PostScript. Octet stream janë të dhëna që paraqiten në formen binare, 8 bita për një byte. Kurse PostScript përdoret kur të dhënat janë në formtin Adobe PostScript që do të shfrytëzohen nga printer që përkrahin PostScript formatin.

Në rastin kur fusha e header-it Content Type nuk është definuar në mënyrë eksplicite për asrye të ndonjë gabimi apo për shkak të versionit të MIME së palës dërguese (user agent), merret vlera e nënkuptuar : "Content-type: text/plain; charset=us-ascii".

MIME Transfer Encodings[Redakto | Redakto nëpërmjet kodit]

Fusha e header-it Content Transfer Encoding mund të pranoj gjashtë vlera të ndryshme, ndonëse vetëm dy prej tyre paraqesin metoda për enkodimin e të dhënave. Specifikacionet mbi enkodimin e mesazhit për të siguruar dërgim të besushëm të të dhënave nëpër mjedise të ndryshme gjenden në RFC 2045. Shumica e të dhënave multimediale që barten përmes email-it janë të formatit binary, përkatësisht mund të parqaiten si karaktere 8 bitshe. Mirpo të dhëna në këtë formë nuk mund të transmetohen përmes disa protokoleve të caktuara; p.sh përmes SMTP mund të transmetohen vetëm ASCII karaktere si dhe gjatësia e rreshtave nuk duhet të jetë më e madhe se 1000 karaktere. Prandaj është paraqitur nevoja për të për enkodimin e të dhënave ashtu që ato të plotësojnë krtiteret e caktuara. Vlerat që mund të marr fusha Content Transfer Encoding janë:

  • 7 bit – të dhënat janë ASCII karaktere, vlera decmale e secilit karakter nuk e kalon 127, rreshtat duhet te kenë maksimumi 1000 karaktere përfshirë këtu edhe Carrige Return (13-vlera decimale) dhe Line Feed (10-vlera decimale).
  • 8 bit – rreshtat po ashtu janë të shkurtër(deri në 1000 karaktere) mirpo mund të paraqiten edhe karaktere që nuk janë ASCII. Me që shtresat e SMTP-së janë në gjendje të bartin të dhënat në këtë format MIME nuk kryen fare enkodim në këtë rast.
  • Binary – të dhënat e kësaj forme jo vetëm që përmbajnë karaktere jo ASCII por rreshta nuk janë domosdoshmërisht të shkurtër si në rastet e mësipërme. Me që SMTP-ja është ne gjendje të dërgoj/pranoj të dhëna binare, MIME nuk kryen kurfar enkodimi as në këtë rast, megjithatë kjo formë e shkëmbimit të të dhënave nuk është e rekomandueshme.Përderisa format e përmendura më lart nuk paraqesin enkodim, ato vetëm i tregojnë për natyrën e të dhënave. Përmes Base64 dhe Quoted Printable bëhet transformi i të dhenave në hyrje nga një domen i qfardoshëm në karaktere 7 bitshe, duke i bërë kështu të ‘sigurta’ për transport sidomos ndaj protokoleve me kufizime të larta.
  • Base64 – përdoret për të enkoduar sekuenca arbitrare të okteteve binare ashtu që të plotësojnë rregullën e 7 bitave. Është mjaft e dobishme për të enkoduar të dhëna binare dhe karaktere 8-bitëshe , nganjëherë përdoret për të enkoduar edhe të dhëna tekstuale që shpesh përdorin karaktere jo ASCII.
  • Quoted-Printable – njësoj si Base64 shërben për enkodimin e sekuencave binare, e dobishme sidomos kur të dhënat paraqesin numër të madh të okteteve që korespondojnë ne ASCII karaktere të printueshme. Është e dizajnuar që të jetë e lexueshme për njerëzit për shkak se kryesisht përbëhet nga ASCII karakteret, ndonëse del edhe jasht tyre ndonjëherë.
  • X-token – tregon se enkodimi është bërë duke shfrytëzuar një skemë tjeter nga ato që u përmendën, në këtë rast jepet emri i asaj skeme.

S/MIME Funksionaliteti[Redakto | Redakto nëpërmjet kodit]

S / MIME mund të përdoret me qfardo sistemi që bartë të dhëna MIME, por poashtu mund të përdoret nga MUAs (Mail User Agents) tradicional për të ofruar shërbime kriptogarfike dhe të sigurisë. S/MIME njësoj si PGP ofron mundësinë për të nënshkruar dhe/ose enkriptuar të dhënat.

  • Shërbimet kriptogarfike dhe të sigurisë që ofron S/MIME janë:
  1. Autentifikimi
  2. Integritetin i mesazhit
  3. Jo-mohueshmëria (Non-repudiation)
  4. Priavtësia dhe siguria e të dhënave

Tri shërbimet e para arrihen përmes nënshkrimit digjital kurse e fundit përmes enkriptimit.

S/MIME bazohet në Cryptographic Message Syntax (CMS). S/MIME agjenti paraqet software-in e përdoruesit që mund të jetë në rolin e dërguesit të të dhënave, pranuesit apo të dyja. Para se të përdoret celqsi publik përmes të cilit arrihet komunikimi i sigurt palët duhet të vërtetojnë valditetin e tij, kjo arrihet duke përdorur PKIX (X.509 Public-Key Infrastructure) certifikatat. S/MIME punon me këto tipe të të dhënave (Content Type): Enveloped Data, Sign Data, Clear-Sign Data dhe Signed and Enveloped Data.

Enveloped Data – përdoret për tu ofruar privatësi mesazheve tona. Ky tip përbëhet nga të dhëna të enkriptuara apo celësa të enkriptuar që do të përdoren për enkriptim nga një apo më shumë shfrytëzues. Kombinimi i përmbajtjes së enkripuar dhe celësave për enkriptim qëjanë poashtu të enkriptuar njihet si digital envelope (zarfi digjial).Procesi përmes së cilit arrihet përfitimi i enveloped data përfshinë:
  • Gjenerimin e një celësi për enkriptim (pseudo-random session key).
  • Bëhet enkriptimi i përmabjtjes me celësin e gjeneruar.
  • Informata e enkriptuar ju shtohet të dhënave specifike për marrësin dhe së bashku japin vlerën e EnvelopedData. Ky informacion pastaj enkodohet në Base64.

Pranuesi fillimisht bën dekodimin nga Base64, pastaj nga një pjesë e mesazhit dekripton celësin e sesionit përmes celësit të vet privat. Këtë celës të sesionit pastaj e shfrytëzon për të dekriptuar mesazhin që e ka pranuar. Kjo ndonëse siguron privatësi, nuk siguron autentifikim.

Signed Data – paraqet të dhënat e nënshkruara nga dërguesi. Qfardo tipi i të dhënave mund të nenshkruhet nga një apo më shumë nënshkrues paralelisht. Procesi i konstruktimit të të dhënave të nënshkruara është si më poshtë:
  • Gjendet hash-i i mesazhit duke përdorur një Hash algoritëm
  • Enkriptohet hashi i mesazhit me celësin privat të dërguesit – fitohet nënshkrimi digjital
  • Mesazhi bashkë me nënshkrimin digjital enkodohen në Base64
Signed Data - S/MIME


Pranuesi dekripton nënshkrimin digjital me celësin publik të dërguesit pastaj hashin e fituar e krahason me hashin që e ka llogaritur nga mesazhi i pranuar. Në qofte se këto dy vlera janë të njëjta pranuesi sigurohet se mesazhi është dërguar nga pala që pretendon se ka dërguar atë dhe mesazhi nuk është ndryshuar gjatë rrugës.



Clear-Signed Data – procesi i formimit të nënshkrimit digjital është i njëjtë si në rastin për Signed Data, i vetmi dallim është se në procesin e enkodimit në Base64 hyn vetëm nënshkrimi digjital jo edhe mesazhi.
Signed and Enveloped Data – nënshkrimi dhe enkriptimi i të dhënave mund te bëhet ndaras pastaj hasen kombiinime të tyre. Kështu të dhënat e enkriptuara mund të nënshkruhen, poashtu të dhënat e nënshkruara ( signed data apo clear-signed data) mund të enkriptohen.

RFC 5322[Redakto | Redakto nëpërmjet kodit]

RFC 5322 definon sintaksën e mesazheve që dërgohen nga shfrytëzuesit fundor (computer users) si electronik mail. Kjo rfc është rishikim i rfc 2882 që është zëvendësim i rfc 822 (“Standard for the Format of ARPA Internet Text Messages”).
Ky standard mesazhet i sheh të përbëra nga dy pjesë: envelope (zarfi) dhe content (përmbajtja). Envelope përmbanë informatat e nevojshme që mundësojnë bartjen dhe dërgimin e mesazhit te marrësi, kurse content paraqet të dhënat që do ti dërgohen marrësit.
Standardi RFC 5322 përshkruan vetëm formatin e përmbajtjes (content) së mesazhit megjithatë edhe ajo përmbanë disa fusha header që mund të përdoren nga mail sistemi për të krijuar zarfin (envelope). Ky dokument nuk përcakton mënyrën e bartjes së të dhënave tekstuale, imazheve, audiove apo të dhënave tjera të strukturuara përmes e-mail –it. Këto specifikacione gjenden në MIME serinë e RFC-ve : 2045,2046 dhe 2049.
Struktura e një mesazhi të definuar sipas RFC


Struktura e një mesazhi sipas konditave të RFC 5322 është mjaft e thjeshtë. Një mesazh tipik përbehet nga header-i dhe body. Header-i mund të përmbajë disa rreshta, kurse trupi i mesazhit (body) përmabanë qfardo teksti të pakufizuar. Një rresht i header-it përbëhet nga një fjalë kyqe e shoqëruar nga dy pika “:” si dhe argmenti përkatës i fjalës kyqe. Nëse rreshti ëshë shumë i gjatë ai mund të ndahet në disa rreshta . Si fjalë kyqe zakonisht hasen: Message ID – kjo fushë identifikon ë mënyrë unike secilin mesazh, From, To, Subject, Date etj.









Referimet[Redakto | Redakto nëpërmjet kodit]

[1] [2]

  1. ^ http://www.w3.org/Protocols/rfc1341/4_Content-Type.html} S/MIME
  2. ^ http://tools.ietf.org/html/rfc5322#appendix-A }RFC 5322 Standardi
Marrë nga "https://sq.wikipedia.org/w/index.php?title=S/MIME_-_RFC_5322_Starndardi&oldid=2030416"