Formati i mesazheve të sigurta elektronike S/MIME

**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 permes disa dokumenteve, më të rëndsishmet janë RFC-të : 3370, 3850, 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
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ë:
#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.  
#SMTP mbështetet në karaktere ASCII (7 bit) , pra nuk mundëson dërgimin/pranimin e të dhënave tekstuale që kodohen me 8 bita.
#SMTP serverët mund të mos pranojnë mesazhe që kalojnë një madhësi të caktuar.
#SMTP portat hyrëse/dalëse që perkthejnë karakteret ASCII në EBCDIC karaktere nuk përdorin mapim të qëndrueshëm prandaj shfaqen probleme në përkthim.
#Disa implementime të SMTP nuk janë plotesisht të definuara në në SMTP standardet – RFC 821.
Probleme te zakonshme që shfaqen në këtë rast një: 
*Fshirja, shtimi apo rirenditja e carriage return dhe line feed.
*Kalimi në rresht të ri, për të respektuar gjtë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 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: 
#Janë definuar 5 header të ri të cilët mund të përfshihen në RFC 5322. Këto fusha përmbajnë informatat e nevojshme për brendinë e mesazhit.
#Janë definuar një numër i caktuar i formateve të përmabjtjeve (contents) duke standardizuar formën se si do të paraqitne të dhënat.
#Transfer encoding bën të mundur shnëderrimin 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 
*Content Type
*Content Transfer Encoding 
*Content ID
*Content Description
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.

### Content type
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.

*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.

*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ë shfaqën paralisht. 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 veçanta 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.

*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ë tjetër 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 njejtë 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).

*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) .

*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.

*Audio* – si nëntip të vetëm ka ‘basic’. Përdoret kur mesazhi i dërguar përmbanë zë.

*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
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ërëhet nga ASCII karakteret, ndonëse del edhe jasht tyre ndonjëherë.

## S/MIME Funksionaliteti
S / MIME mund të përdoret me qfardo sistemi që bartë MIME data , por po ashtu mund të përdoret nga MUAs (Mail User Agents) tradicional për të ofruar shërbimin e kriptogarfisë dhe sigurisë. S/MIME njësoj si PGP ofron mundësinë për të nënshkrur dhe/ose enkriptuar të dhënat.
S / MIME ofron shërbimet e mëposhtme të sigurisë dhe kriptografisë:
#Autentifikimin
#Integritetin e mesazhit
#Jo-mohueshmërinë (Non-repudiation)
#Priavtësinë dhe sigurinë 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 softëare-in e perdoruesit 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ë po ashtu të enkriptuar njihet si digital envelope (zarfi digjial).

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.

Clear-Signed Data –  procesi i formimit të nënshkrimit digjital është i njejtë 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 kombiminme të tyre. Kështu të dhënat e enkriptuara mund të nënshkruhen, po ashtu të dhënat e nënshkruara ( signed data apo clear-signed data) mund të enkriptohen.
## Algoritmet kriptografike
S/MIME përfshinë 3 algoritme për celësin publik. Algoritmi i preferuar për nënshkrim digjital është DSS( Digital Signature Security ). Për enkriptimin e celësave të sesionit (session keys) përdoret një version i Diffie-Helman i njohur si El Gamel dhe mundëson enkriptim dhe dekripim. Alternativë për të dyja këto algoritme është RSA-ja që mund të përdoret si për nënshkrim digjital ashtu edhe për enkriptim të celësit të sesionit.
Si algoritëm për llogaritjen e hash-it të mesazhit që nevojitet te nënshkrimi digjital përdoret SHA1 (dalja 160 bit) mirpo rekomandohet që pala marrëse të përkrahë edhe algoritmin tjetër MD5 (dalja 128 bit) për të arritur kompatibilitet me versionet e mëhershme të S/MIME-s.
Për enkriptim të mesazhit përdoret tripleDES-i, mirpo rekomandohet që pala marrëse të përkrahë RC2. Ndonëse RC2 është algoritëm i dobët ai është në pajtim  rregullat ligjet mbi eksportin e algoritmeve kriptogarfike në SHBA.

Algoritmet kriptografike të përdorura në S/MIME:==

Ka disa kompani që ofrojnë autoritetin e sherbimeve të certifikimit(CA). Janë një numër i Internet CA-ve, duke përfshirë VeriSign, GTE dhe Shërbimi Postar të SHBA-ve. Nga këto, më të përdorura është CA VeriSign service, e cila ofron një shërbim CA që është menduar të jetë në përputhje me S/MIME dhe një shumëllojshmëri çështjesh të tjera aplicationeve. VeriSign lëshon X. 509 certifikata me emrin e produktit VeriSign Digital ID. 
Informatat që gjinden në një Digital ID varen nga lloji i Digital ID dhe përdorimi i tij.Minimumi që, secili Digital ID përmban:
*Çelësin publik pronarit
*Emri i pronarit ose pseudonimin e tij
*Data e skadimit të Digital ID
*Numrin serik të Digital ID
*Emrin e autoritetit çertifikues që e ka lëshuar Digital ID
*Nënshkrimin digjital të autoritetit certifikues që e ka lëshuar Digital ID
*Digital ID mund të përmbajnë gjithashtu të dhëna të tjera të përdoruesit, si:
*Adresa
*E-mail
*Informata themelore të regjistrimit (vendi, kodi zip, mosha dhe gjinia)

## Referimet