HAL Id: inria-00084795
https://hal.inria.fr/inria-00084795v2
Submitted on 18 Jul 2006
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of
sci-entific research documents, whether they are
pub-L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
Release 4 Platform
Pierre Parrend, Stéphane Frénot
To cite this version:
Pierre Parrend, Stéphane Frénot. Secure Component Deployment in the OSGi(tm) Release 4 Platform.
[Technical Report] RT-0323, INRIA. 2006, pp.46. �inria-00084795v2�
inria-00084795, version 2 - 18 Jul 2006
a p p o r t
t e c h n i q u e
9
-0
8
0
3
IS
R
N
IN
R
IA
/R
T
--0
3
2
3
--F
R
+
E
N
G
Thème COM
Secure Component Deployment in the OSGi
tm
Release 4 Platform
Pierre Parrend — Stéphane Frénot
N° 0323
Platform
Pierre Parrend,Stéphane Frénot
∗ ∗
ThèmeCOMSystèmes ommuni ants ProjetARES
Rapportte hniquen° 0323June200646pages
Abstra t: Lastyearshaveseenadramati in reaseintheuseof omponentplatforms,not only in lassi alappli ation servers,but also more and morein the domain of Embedded Systems. TheOSGi
tm
platformisoneoftheseplatformsdedi atedtolightweightexe ution environments, and one of the most prominent. However, new platforms also imply new se urity aws,andala kofbothknowledgeandtoolsforprote tingtheexposedsystems.
This te hni al report aims at fostering the understanding of se urity me hanisms in omponentdeployment. It fo uses onse uring thedeploymentof omponents. It presents the ryptographi me hanismsne essaryforsigningOSGi
tm
bundles,aswellasthedetailed pro essofbundlesignatureandvalidation.
WealsopresenttheSFelixplatform,whi hisase ureextensiontoFelixOSGi
tm
frame-work implementation. It in ludes our implementation of thebundle signature pro ess, as spe i edbyOSGi
tm
Release4Se urityLayer. Moreover,atoolfor signingand publishing bundles,SFelixJarSigner,hasbeendevelopedto onvenientlyintegratebundlesignaturein thebundledeploymentpro ess.
Key-words: OSGi
tm
,Se urity,Integrity,Authenti ation,JarSignature,DigitalSignature, Felix.
∗
Résumé : L'utilisation de plates-formes à omposants a onnu es dernières années une forte roissan e, en parti ulierdans le domainedes Systèmes Embarqués. La plate-forme OSGi
tm
estunede esplates-formesdédiéesauxenvironnementslégers. Cependant,lamise enoeuvre denouvellesplates-formes impliquelaprésen ede nouveaux risquesdesé urité, ainsiqu'unmanqueàlafoisde onnaissan eetd'outils pourpalierà esnouveauxrisques. Ce rapport te hnique apourobje tif d'améliorer la ompréhensiondes mé anismesde sé uritédansle adre dudéploiementde omposants. Ilse on entresur laproblématique delasé urisationdudéploiement. Ilprésentelesmé anismesde ryptographiené essairesà lasignaturedes omposantsOSGi
tm
(appelésbundles),etlepro essusdétaillédesignature etdevalidationde es bundles.
Nous présentonségalement la plate-formeSFelix, qui est une implémentation sûre du frameworkOSGi
tm
baséesurleprojetApa heFelix. SFelix omprendnotreimplémentation du pro essus de validation de bundles, onformeà la spé i ation OSGi
tm
release 4. De plus,unoutildesignatureetdepubli ationdebundleSFelixJarSigner,aétédéveloppéde manièreàintégrerlasé urisationdesbundlesdanslepro essusdedéploiement.
Mots- lés : OSGi
tm
, Sé urité, Intégrité, Authenti ation, Signature de Jar, Signature Numérique,Felix.
Contents
1 Introdu tion 7
1.1 ContextofthisReport . . . 7
1.2 ComponentDeployment . . . 7
1.3 Threatsduring Deployment . . . 8
1.4 Mali iousBundles . . . 9
2 Cryptographi Con epts and Standards 11 2.1 Integrity . . . 11
2.1.1 DigitalSignature . . . 11
2.1.2 Cryptographi MessageSyntax . . . 13
2.1.3 Asymmetri En ryptionandHashingAlgorithms . . . 14
2.2 Authenti ation . . . 16 2.2.1 Certi ate Validation . . . 16 2.2.2 X.509Certi ate . . . 18 2.2.3 Certi ate Store . . . 19 2.3 Con dentiality . . . 20 2.3.1 De nition . . . 20
2.3.2 Howto a hieveCon dentiality? . . . 20
2.4 Con lusions . . . 20
3 Se ureDeployment 22 3.1 Overview . . . 22
3.1.1 Bundle Deployment . . . 22
3.1.2 RequirementsforAuthenti ation . . . 23
3.2 Stru tureofaSignedBundle . . . 24
3.2.1 TheManifestFile . . . 26
3.2.2 TheSignatureFile . . . 27
3.2.3 TheSignatureBlo kFile . . . 27
3.3 ThePro essofSignature andValidation . . . 28
3.3.1 Signature . . . 28
3.3.2 Validation . . . 29
3.4 Con lusions . . . 30
4 Implementation: SFelix 31 4.1 Overview . . . 31
4.1.1 Role ofSFelixplatformandSFelixJarSigner . . . 31
4.1.2 Stru tureoftheProgram . . . 32
4.1.3 TheAPI. . . 32
4.2 FelixModi ationsforBundleValidation . . . 33
4.2.1 TheCode . . . 33
4.2.3 RuntimeoftheSFelixPlatform . . . 34
4.3 Tool: SFelixJarSigner . . . 36
4.3.1 Fun tionsofJarSigner . . . 36
4.3.2 Bundles ofJarSigner . . . 36
4.4 Con lusions . . . 38
5 Con lusions 40 6 Annexes 41 6.1 ExistingToolsforSe ure JavaAppli ations . . . 41
6.2 JavaCryptographi Libraries . . . 42
List of Figures
1 TheComponentDeploymentPro ess . . . 7
2 TheSe urityThreatsduring theComponentDeploymentPro ess. . . 8
3 DigitalSignatureofaDo umentusingasymmetri Cryptography . . . 11
4 DigitalSignatureGeneration . . . 12
5 DigitalSignatureValidation . . . 12
6 The ontentofaCryptographi MessageStandard(CMS) ompliantFile. . . 14
7 TheCerti ationDistributionrequiredforCerti ateChe king . . . 17
8 Certi ateValidation(Case1): theCerti ateisknowntothe he ker . . . . 17
9 Certi ateValidation(Case2): theCerti ateisunknownto the he ker . . 17
10 ContentofaX.509Certi ate. . . 19
11 ContentofaCerti ateStore . . . 20
12 En ryptionofado umentfor on dentiality. . . 21
13 Therequirementsfortheauthenti ationpro ess. . . 24
14 ExampleofasignedHelloWorldbundle,signedbyPIERREP. . . 24
15 TheManifestFilefortheHelloWorldExampleBundle.. . . 26
16 TheSignature FilefortheHelloWorldExampleBundle. . . 27
17 TheAlgorithmforsigningaBundle. . . 28
18 TheAlgorithmforValidatingasignedBundle. . . 29
19 ThegeneralAr hite tureoftheSe ureFelix(SFelix)Platform. . . 32
20 Thepubli APIoftheSe ureFelix(SFelix)Platform. . . 33
21 S reen-shotofSFelixshellwhenlaun hinganewSFelixPro le . . . 35
22 S reen-shotofSFelixshellwhentryingtoinstallanunsigned bundle . . . 35
23 TheGraphi alUserInterfa eoftheSFelixJarSignerTool.. . . 37
24 S reen-shotofSFelixshellwhenlaun hingtheSFelixJarSignerTool . . . 39
25 TheSequen e DiagramoftheAlgorithmforsigningaBundle.. . . 43
List of Tables
1 MainHashalgorithms . . . 15 2 MainEn ryptionalgorithms . . . 15 3 Meta-datainvolvedinBundleSignature . . . 26
1 Introdu tion
1.1 Context of this Report
TheOSGi
tm
platformisanexe utionlayerovertheJavaVirtualMa hinethatsupportslife y le management of omponents (introdu tion, update, removal) during runtime. These omponentsprovideJavapa kagesorlo allypublishedservi es(asJavainterfa es)toother omponents.
Thiste hni alreportaimsatfosteringtheunderstandingofse urityme hanismsinthe OSGi
tm
platform. It fo uses on se uring the deployment of omponents. It presentsthe ryptographi me hanismsne essaryforsigningOSGi
tm
omponents(alsonamedbundles), aswellas thedetailedpro essofbundlesignatureandvalidation.
WepresenttheSFelixplatform 1
,whi h isase ureextension toApa heFelix 2
OSGi
tm
frameworkimplementation. Itin ludesourimplementationofthebundlevalidationpro ess in OSGi
tm
Release4Se urity Layer. Moreover,atoolforsigning andpublishing bundles, SFelixJarSigner,hasbeendevelopedto onvenientlyintegratebundlesignatureinthebundle deploymentpro ess.
1.2 Component Deployment
Thedeploymentofbundlesisnotde ned bytheOSGi
tm
spe i ations. IntheFelix imple-mentation,it isrealizedbythepubli ationof thebundlesonaserverontheInternet,and theinstallation of these bundlesfrom the serverby the lientplatforms. Thesteps ofthe deploymentpro ess arethefollowing: publi ation (1),bundle dis overy(2), download(3), installation(4) andupdate (4.b),exe ution(5). The gure1showsthispro ess ofbundle deployment.
Figure1: TheComponentDeploymentPro ess
1
http://sfelix.gforge.inria.fr 2
1.3 Threats during Deployment
Majorse uritythreatsduring deploymentareofthreetypes. The rsttypeisthepresen e ofmali iousbundlepubli ation servers. These ondtypeof deploymentthreatsis man-in-the-middleatta k. Su h anatta ker anmodify thebundle, orfullysubstitute theloaded bundleby anotherone. Inboth asesthe lientplatform installsthen exe utessome ode withoutbeing ableto do anyassumption about the ode quality orreliability. The third type of threats is the possibility that exists for an atta ker to a ess and modify (=to tamper) thestoreddata usedbythe omponentplatform. A tually, all on gurationdata and installed omponents are available on the lesystem of the host, and a ess to this lesystemis su ientto fully ontrolthebehavioroftheplatformandof the omponents. So as to prote tthe omponent platform from the rst twothreats, it is ne essary to ontrolthat thebundlepublishersaretrustworthy,andthat loadedbundleshavenotbeen tampered with during the transfer over an untrusted network, su h asthe Internet. Jar spe i ations(bundlesarespe i Jarar hives)propose tosignar hivesoasto guarantee su h properties. OSGi
tm
spe i ations propose additional restri tionsto signing, notably byforbiddingun ompletear hivesigning,whi hallowsathirdpartytoaddresour estoan ar hivewithoutinvalidatingthesignature.
Theprote tionoftheplatformresour esrequirestointegratease ure lesystemwiththe omponentplatform. Bundlesubstitutionor on gurationtamperingbetweendownloadand startingisthenprevented. Asfarasitdoesnotdealdire tlywiththeproblem ofse uring thedeploymentpro ess,thisextensionoftheplatformwillnotbe onsideredfurtherinthis report.
Figure 2showsthese uritythreatsthatexist during thedeploymentpro ess ofa om-ponent.
1.4 Mali ious Bundles
The mali ious bundles an be ategorized a ording to the target of their atta ks, and a ordingtotheatta kparadigmtheyuse,thatistosaythetypeofeventthattriggersthe atta k.
Atta k Targets Mali ious bundles anbe lassi edin fourmain typesa ordingtothe targetoftheatta ktheyperform:
1. Threat to the System, for instan e, a bundle an ontain JNI alls whi h makes it possibletoa esstheunderlyingOperatingSystem;orit anhaveextremelyresour e intensiveservi eswhi h onsumemostoftheavailableCPUormemoryofthesystem,
2. Threat tothe Platform, abundle antryand a ess the Javaplatform(through the Systemor Runtime lasses),ortheOSGi
tm
platform,
3. Threat tothe Bundles, abundle anmisuse available servi es(depending ofthe ser-vi e API), orprovide false servi es, that provides agivenservi e with an improper implementation,
4. Undue Monitoring, a bundle angather data related to aplatform withoutmaking immediateuseofthem,andsend themtoaremoteatta kerforlatterintrusion.
Atta kparadigms Threemainatta kparadigms anbeusedbymali iousbundles. They are hara terizedbytheeventthattriggerstheatta k:
1. Ba k doors. Those bundlesmakeit possiblefor a remoteatta kerto gain a ess to theexe utionplatform.
2. Mali ious servi es. those bundles provide fake servi es or lasses that an be used insteadofvalidones.
3. Autonomousbundles. thosebundlesperformmali iousa tionsautonomously,without remote ontrolandwithoutrequiringservi e allsfromotherservi es. Theirbehavior is losetotheoneofviruses.
It is of ourse possible that amali ious bundle uses several of these atta k paradigms simultaneously.
Thisbriefpresentationoftheatta ksthatmayo urthroughmali iousOSGi
tm
bundles highlightstheneedforse uringthelife y leofthebundles,andparti ularlyforprote ting thedeploymentphasefrommali iousBundleRepositories,frombundlesubstitutionduring transferorfrom lo altamperingduringtheinstallationphase.
Thiste hni alreportpresentstheme hanismsthatarene essarytoimplementthe bun-dlesignatureandvalidationpro ess. First,underlying ryptographi on eptsarepresented. Then,thealgorithmsforsigningandvalidatinganOSGi
tm
ourimplementationof bundlesignaturepro essispresented. Itis madeoftheSFelix plat-form-anextensionofApa heFelixOSGi
tm
implementation-onthe rsthand,andofSFelix JarSignertool-thatsupportssigningandpubli ationofbundles-ontheotherhand.
2 Cryptographi Con epts and Standards
Se urity of systemsis the ability of these systems to withstand thebehaviorof mali ious users. It anbede nedasthe onjun tionofintegrity,availabilityforauthorizedusersonly, and on dentiality[AJB00℄. Identi ationofauthorizedusersisnamedauthenti ation.
Se ure bundle deployment means that these requirements are guaranteed during the whole deployment pro ess, that is to say from the publi ation of a bundle until the time whenthisbundle isstarted. Itisbasedonasymmetri ,orpubli key, ryptography,whi h publi lybindsagivenkeypairwithauniqueuser. Thispairismadeofase retprivatekey ownedby theuserandof apubli keythat is widelyavailable. Theprivatekeyisused to en ryptdata. Everythird partyuser anthen assertthat data that arede ryptable with thepubli keyhavebeenen ryptedwiththeprivateone.
Forea hofthese urityrequirementsthathavebeende ned,ade nitionwillbegiven,the ryptographi me hanismsne essaryfortheirenfor ementwillbepresented,andsupporting standardswillbeintrodu ed.
2.1 Integrity
Integrity is de ned by [AJB00℄ as the absen e of improper system state alterations. In thedeploymentpro ess,thismeansthatloaded bundlesmustnotbemodi edbetweenthe publi ationstepandthestartstep.
2.1.1 Digital Signature
A`DigitalSignature'isanele troni signaturethat anbeusedtoensurethattheoriginal ontent ofthemessageordo ument thathas beensentis un hanged,andto authenti ate the identity of the sender of a message or the signer of a do ument. That is to say a digitalsignatureguaranteesboththeintegrityofthedo umentandtheauthenti ationofits emitter. Wewill on entrateinthesese tiononintegrity. Authenti ationwillbepresented indetails inse tion2.2.
Theoverviewofthepro essofdigitalsignatureisshownin gure3.
This pro ess anbesharedin twoseparate steps: thesignature generation(A) bythe emitterofthesigneddo ument,andthesignaturevalidation(B),bythere eiver. Signature generation onsistsin applyinga signaturealgorithm on thesigned do ument. This algo-rithmresults in adata le alled Cryptohash, ormorefrequently DigitalSignature. This signatureis passedoverfrom the emitter to there eiveralongwith the signeddo ument. There eiver anthen he kwhetherthedigitalsignaturemat hesthedo ument.
The gure4and5showrespe tivelythepro essofdigitalsignaturegenerationandthe pro essofdigitalsignaturevalidation.
Figure4: DigitalSignature Generation Figure 5: DigitalSignature Validation
The pro ess of digital signature generation takesas input the do ument to be signed andtheprivatekeyofthesigner. Itprodu esasoutputadigitalsignature,orCryptohash, whi ha ompaniesthesigneddo umentsoastoproveitsintegrity. The rststepofdigital signature generation is to apply ahash fun tion to thedo ument, so asto obtain a xed lengthdata lethatuniquelymat hestheoriginaldo ument(A.1). Theresultinghashvalue is en rypted withthe private keyof thesigner, soasto guaranteethat nobody else ould haveprodu edthis signature,and thusto provethatno mali iousentityhaveprovided or modi edthedo ument(A.2). Thedo ument anthenbepubli lypublishedalongwithits digitalsignature(A.3).
When auser wants to exploit a do ument that is publi lyavailable,or that has been transferedoveraninse ure ommuni ation hannel su h astheInternet,it anthen verify that this do ument has been issued by the pretendedissuer, and has not been tampered withduringtransfer. Thepro essofdigitalsignaturevalidationtakesasinputthepublished do ument,thedigitalsignatureandthepubli keyofthepretendedsigner(B.0,B.2). The validationismadeoftwoparallelpro esses. Onthe rsthand,thedo umentishashedwith the samehash fun tion that hasbeen used for the signature generation (B.1). This step providesthehashvalueoftheavailabledo ument. Ontheotherhand,thedigitalsignature
(=theCryptohash)isde rypted withthepubli keyofthesigner(B.2). Thehashvalueof theoriginal do umentis retrieved bythis way. This stepguaranteesthat no otherperson tries toimpersonate therealsigner. On ethehash oftheoriginaldo ument andthehash oftheavailabledo umentareavailable,itissu ientto omparethem. Iftheymat h,the availabledo umentistheonethathasbeensigned. Otherwise,itmeansthat theavailable do umentisnottheonethat hasbeensigned.
The unvalidity of the pro ess of digital signature validation an have several auses. The moreobvious oneis of ourse the modi ationof the do ument, or the substitution by another one. But the modi ation of the digital signature itself has the same result. If someone has a valid do ument without the original digitalsignature, it an not he k the validity of the do ument. Another ause of validation error is the la k of knowledge aboutthe signer. Whenthe re eiverdoes nothavea opyof the publi keyof the signer thatheknowstobevalid,it annotvalidatethesignature. A tually,anybody ansignthe do ument and provide a valid signature for it. If you do not trustthe signer, the digital signature annotprovidetheproofofintegrityofado ument.
2.1.2 Cryptographi MessageSyntax
Another onstraintexists in theveri ation ofado ument. There eiverof thedo ument musthaveallne essarydataforexe utingthisvalidation,that istosaythedo ument,the digitalsignatureandthepubli key erti ateofthesigner. However,it anbene essaryto trustdo umentissuersthat are notknownbeforehand,that is tosayfor whi h thepubli key erti ateisnotpreviouslystoredbythere eiver. Therefore,thispubli key erti ate mustbeprovidedalongwiththesigneddo ument. Pro essoftrustingpreviouslyunknown signersimpliessignaturedelegation,whi hispresentedinsubse tion 2.2.
This dataavailability onstraintmeansthatseveral lesmust betransferedalongwith the signed do ument for veri ation. It is therefore ne essary to bind them together, so asto prevent omplexand slow do umentex hange proto ols between thesigner andthe re eiver. A solutionfor providing thedo ument, thedigital signature and thepubli key erti ate of the signer is to integrate them in a CMS (Cryptographi Message Syntax) do ument [Hou02℄
3
, and to publish not dire tly the signed do ument, but its asso iated CMS le. ThisCMS le an ontainornotthesigneddo ument,dependingonthe ontext ofpubli ation.
Figure6showsanexampleofaCryptographi MessageSyntax(CMS) ompliantFilein ahuman-readableXMLformat.
Foren apsulating Digital Signatures, the CMS type`signed-data' is used. It ontains datane essaryforvalidating theDigitalSignature. En apsulateddatainthiskindofCMS le is organized into two ategories: Signers data, and Certi ates data. Signers data ontainstheIDofoneorseveralsigner(s)ofthedo ument,aswellastheDigitalSignature ofthedo umentforea hsigner. Certi atesdata omprisesX.509Publi KeyCerti ates
3
Figure6: The ontentofaCryptographi MessageStandard(CMS) ompliantFile.
forthesigners,andpotentiallyaCerti ateRevo ationList. Moreover,thesigned-data le analso ontainthesigneddo umentitself.
CMS Files use the ASN.1 syntax and are en oded in DER (Distinguished En oding Rules) format[Bur93℄. This makesit possibleto integrate binary ontent su h asDigital Signaturestogetherwiththenameofthesignerandthepropertiesofthe erti ates.
2.1.3 Asymmetri En ryptionand Hashing Algorithms
Thepro essofdigitalsignaturegeneration andvalidationmakesuseoftwodierentkinds ofalgorithms: onehash fun tion,and oneen ryption algorithm. Numerous ryptographi algorithmsareavailablethat provideoneortheotherfun tionality. Although urrent re -ommendationsfordigitalsignaturestronglyrestri tthe hoi ebetweentheRSA/MD5pair and the DSA/SHA-1 pair, the hoi e of algorithm remains open. A tually, the required se urity level, the memory and performan e onstraints of the system that makes use of digitalsignature an stronglyimpa tthe hoi e.
CommonlyusedHashalgorithmsareMD5(Message-Digestalgorithm5)[Riv92℄, SHA-1 (Se ure Hash Algorithm) [Nat93℄, as well as SHA-224, SHA1-256, Tiger [AB96℄ and Whirlpool [Int04℄
4
. Table 1 shows the hara teristi s of these algorithms. The output lengthisthelengthoftheresultinghashvalue. Whenseveralvariantsexistforagiven algo-rithm,severaloutputlengthsaregiven. These uritylevelindi ates whetherthealgorithm is onsidered as se ure. The availability indi ates when a given algorithm is available in
4
OnlySHA-1orbetteralgoritmsshouldbeusedforsigningdo uments,sin eitispossibletobuildfalse Certi ates using MD5ina oupleof hours [WY05 ℄. Theoreti al atta ks alsoexist on the SHA-1 hash fun tion,butare urrentlynotexploitableinpra ti e.
toolsforsigningar hives(XXX),regularly onsideredinspe i ations(XX)oravailablein APIsbut notintegratedin existingtools(X).
Hash Algorithm Output length Se urity Availability (bytes) Level MD5 128 Broken XX SHA-1 160 Theoreti ally XXX Broken SHA-224 224 High X SHA256 256 High X Tiger 128/160/192 High X Whirlpool 512 High X
Table1: MainHashalgorithms
Commonly used en ryption algorithms are RSA [RSA93℄, DSA (Digital Signature Al-gorithm) [Nat94℄, and ECC (Ellipti CurveCryptography)[BWBL02℄. Table 2showsthe hara teristi softhesealgorithms. Thetypi alkeysizesgivesthekeysizes ommonlyused forensuringse ure ommuni ations. Forea hkey,dierentlengths anbeuseddepending onthene essaryse urity level. Several valuesarethen given. These uritylevel indi ates whetherthealgorithm anbe onsideredasse ure. Theavailabilityindi ateswhenagiven algorithmisavailablein toolsforsigningar hives(XXX), regularly onsideredin spe i a-tions(XX) oravailable in APIs but not integrated in existing tools (X). Whenavailable, thetypi alasso iated hashalgorithm givesthehash fun tion that is ommonlyused with theen ryptionalgorithm.
En ryptionAlgorithm Typi al Se urity Availability Typi al asso iated Key Sizes Level Hash algorithm
RSA 1024/2048 High XX MD5
DSA 1024/2048 High XXX SHA-1
ECC 160/192 High X
Table2: MainEn ryptionalgorithms
The hoi e of pairing a hash fun tion with an en ryption algorithm is quite open, al-thoughone restri tionexists: thelength ofthe data generated throughthe hashfun tion mustbeatleastaslongastheen ryptionkey. Forinstan e,SHA-1generatesadigestof160 bytes(=1280bits). Thelongestkey anthenbe1024bits. Foramorepowerfulsignature, itisne essaryto useahashfun tion withlonger output,forinstan e SHA-256(256 bytes =2048bits). Akeyof2048bits an thenbeused.
Fornon strategi systems,the urrent trendis to use theDSA/SHA-1algorithm pair. Itis onsideredassu ientlyse ure,andhasthenon-negligibleadvantageof ompatibility withexistingsignaturetools.
The digital signature of a do ument enables to guarantee its integrity, that is to say thatagivendo umentisidenti altotheoriginalone. Inparti ular,thisaimsatpreventing do ument modi ation orsubstitution. However,the guarantee of integrity requires that there eivertruststhesignerofthedo ument. Consequently,itisne essarytoauthenti ate thesigner. Otherwise,anybody anpublisha leandprovideavalidsignature. Two ases ofauthenti ationexist: either thesignerisalreadyknowntothere eiver,orit isnot,and a trusted third party is then required to guarantee the identity of all potential signers. Followingse tionwilldetailtheauthenti ationpro ess.
2.2 Authenti ation
Authenti ation is the formal identi ation of the emitter of amessage. It onsists in the veri ationofthevalidityoftheidentityofthisemitter.
Inthe ontextofDigitalSignature,theemitterofthemessageisinfa tthesignerofthe do ument. Itsidentityis arriedalongwiththesigneddo umentasapubli key erti ate ompliantwiththeX.509format. These dataareen apsulatedtogetherinaCMS le. The authenti ation pro ess impliesto omparethis erti ate bound to thedo ument andthe erti ates that are onsidered astrusted by theentity that performs the authenti ation. Thesetrusted erti atesarestoredin adatabase alledCerti ateStore.
2.2.1 Certi ate Validation
Twos enariosofauthenti ationofapubli key erti ateexist. EithertheSubje t,thatis tosaythesignerofthepubli key,isknowntotheentitythatperformstheauthenti ation, orit is not. In the se ond ase, theauthenti ation anbe performed if the Issuer of the publi key erti ate(oroneissueroftheissuer's erti ate)isknown.
The requirement for both authenti ation s enarios is that the set of erti ates that are onsidered as trusted are transfered in a se ure way to the entity that performs the authenti ationbeforetheauthenti ationo urs. The gure7showsthis pro ess.
The distribution of trusted erti ates is done in an initialization phase. A trusted Certi ationAuthoritydeliversthesetof erti atesthattheauthenti atingpart antrust overase ure hannel(orpossiblyo ine). These erti atesarestoredbytheauthenti ating partinitsCerti ateStore,andmarkedastrusted. Thismeansthatwhenthe lientlatter handles a erti ate that is available in the Certi ate Store and is marked astrusted, it willbeabletoassertthatthis erti ateisavalidone. Inother ases,itwillnotbeableto verifywhetheragiven erti atewhi hSubje tisforinstan eSFRENOTisavalidone,or afakeonebuiltbysomeonewhopretendsto beSFRENOTbutwhoisnot.
Figure7: TheCerti ationDistributionrequiredforCerti ateChe king
Figure8: Certi ateValidation (Case1): theCerti ateisknowntothe he ker
In the Case 1, theauthenti ating part rst need to retrievethe publi key erti ate. Inparti ular, in the aseof Digital Signature transmitted througha CMS le, it extra ts the erti ate from it (1). Then it an he k whether this erti ate is already known and marked as trusted (2). In our example, the signer is alled PIERREP. The Subje t of the erti ate is then PIERREP. It is possible to assert its validity be ause the same erti ate forPIERREP (withsameIssuer and erti atesignature) is markedastrusted intheCerti ateStore.
These ondme hanism(Case2)isshownon gure9.
Figure9: Certi ateValidation(Case2): theCerti ateisunknowntothe he ker
These ondme hanismismadepossiblebythestru tureofpubli key erti ates. They are either issued by athird party, orself signed. In any ase, they ontain two identities
that arerelevantforauthenti ation. The rstoneis theidentityof theSubje t, thatis to saytheownerofthe erti ate. These ondoneistheidentityof theIssuer,that istosay theentitythat hasemittedthe erti ate.
Theauthenti atingpart rstneedtoretrievethevariouspubli key erti atesthatare requiredto performthe authenti ation(1). Then it buildsthe erti atepath, by linking the erti ateof ea h Subje twith theoneofitsIssuer (2). Thevalidity ofthe erti ate path is asserted if the root erti ate that is to say the rst of the erti ate hierar hy exists in the Certi ate Store and is marked as trusted (3). The erti ate path is only validifall erti atesusedforsigningotheroneshavetherighttodoit,whi hisindi ated in the erti ate itself. In our se ond example, the signer PIERREP is unknown to the authenti ating part. It is provided with the erti ate for ARES, who has been used to issue it, and the erti ate for INRIA, that has been used to sign the ARES one. The validityof this erti ate hain is assertedbe ause both INRIAand AREShave theright toissue erti ates,andbe ausetheauthenti atingpartknowsthe erti ateofINRIA.
2.2.2 X.509 Certi ate
The X.509 publi key Certi ate is a data stru ture that en apsulates a publi key and asso iateddata ne essaryfor identifyingagiven subje t[HFPS99 ℄. It anbepublished in aCMS le,orasstand-alonedata.
The X.509 Certi ate is digitally signed by the issuer of the publi /private key pair, whi hthereby laimsthatthesubje tofthe erti ateistheowneroftheasso iatedprivate key. Italso laimsthathea knowledgesthatthesubje t'sname( alledDistinguishedName) is orre t. Everyuserwhi h truststhe issuer ofthe erti ate will then be ableto assert theidentity ofthe emitter ofamessagethat anbede rypted (or whosedigitalsignature anbeveri ed)withthepubli key ontainedinthis erti ate. Thisistheauthenti ation. Thispro essimpliesof oursethat theprivatekeyhasnotbeen orrupted.
Figure10showsthe ontentofaX.509 erti ate.
Fields of the erti ate are the publi key, the name of the Subje t, the name of the Issuer of the Certi ate, the validity period, the URL of the revo ation server, and the DigitalSignature. A additional eld allowsto he kthevalidityof the erti ates,and is notrepresentedinthishuman-readablerepresentation: thedigitalsignatureofthe erti ate byitsissuer.
The name of subje ts are de ned by Distinguished Names (DN), whi h originate in LDAP spe i ations [WK97℄. Distinguished Names are a omposition of following elds: CN=`CommonName',OU=`OrganizationUnit',O=`Organization',L=`Lo ation'( ity),S= `State',C=`Country ode'. De nition ofDistinguishedNamesstatesthatthe eldsfollowa hierar hi alorganization,andthusthattheirorderimports. Forinstan e,aDN{C=Fran e, O=INRIA} is dierent of a DN {O=INRIA, C=Fran e}. However, in several tools for manipulating erti ates, su h asSun Keytool, theorder of the elds is xed, preventing su h ambiguities.
Figure10: ContentofaX.509Certi ate
2.2.3 Certi ate Store
ACerti ateStoreisadatabasethat ontainsPubli KeyCerti atesthattheownerofthe Storeknows. Certi ates anbeidenti edastrustedanduntrusted. Itusuallyalsoin ludes oneorseveralprivatekeys. It isthen alledaKeystore
5 .
The Certi ate Store is prote tedby a password. When private keysexists, ea h one isprote tedbyits ownpassword. Consequently,aCerti ateStore(or aKeystore) anbe sharedamongseveralsubje ts,ifthe erti atemanagementisshared.
Figure11showsthe ontentofaCerti ateStore: trusted erti ates,untrusted erti - ates,privatekeys.
The onjun t useofadigitalsignature anda erti atestoreallowsto guaranteeboth the integrity of a do ument and to authenti ate its signer. Both properties must apply together. However,thisme hanism,ifitguaranteesthatado umenthasnotbeenmodi ed
5
Figure11: ContentofaCerti ateStore
after itspubli ation,doesnotprote tits ontentfrom mali iouseavesdroppers. Thethird se urityproperty, on dentiality, anbeusedtoa hievesu h aprote tion.
2.3 Con dentiality 2.3.1 De nition
Con dentiality is the absen e of unauthorized dis losure of information [AJB00℄. In the ontextof omponentdeployment,thismeansthat the ontentofthe omponent- odeor otherresour es- is notavailable to usersthat are notexpli itlyauthorized to manipulate them.
2.3.2 How to a hieve Con dentiality ?
Con dentialitywithasymmetri ryptographyisa hievedbyen ryptingthedo umentwith thePubli Keyofthere eiver(1). Thus, theownerofthemat hing privatekeyistheonly onethat ande ryptthedo ument(2),andgaina esstoits ontent.
Figure 12 shows thepro ess of en ryption and de ryption of ado ument for ensuring on dentiality.
Be ausethedo umentisnoten ryptedwiththeprivatekeyoftheemitter,thispro ess doesnotprovidemeansofperformingauthenti ation. Inpra ti e,en ryptionfor on den-tiality is used together with en ryption for authenti ation. Therefore, the re eiverof the do ument,afterhavingde rypteditwithitsownprivatekey, anmakethede ryptionwith thepubli keyoftheemitterandthus ontrolitsidentity.
2.4 Con lusions
Se urityrequirementsfor omputersystemsareintegrity,authenti ationand on dentiality. The rstpropertyaimsatverifyingthatthe ontentofdatahavenotbeentamperedwith. The se ond property aims at identifying the emitter of the data. Both steps an not be onsidered independently: if theemitter of amessageis not authenti ated, anymali ious
Figure12: En ryptionofado umentfor on dentiality
user anpublish data with orre t integrity validation me hanism. Similarly, if amessage isauthenti atedbutitsintegrityisnotguaranteed, thereisnowaynotknowwhether any singlebyte ofithasreallybeenemittedbytheauthenti atedemitter.
Thethirdpropertyis on dentiality. Itaimsatprote tingdatafromunduereada ess. Inthis report, wewill not onsider it further sin e we onsider that a ess to omponent resour esdoes not make it possible for amali ious user to gain a ess to the omponent platform.
3 Se ure Deployment
Theimportantin reaseofquantityanddiversityin omponentsystemsmakesitne essary toprote tthemagainstmali iouspersonsandsystems. Components anbemodi edduring deployment,orsimplybepublished byuntrustedissuers. Itisthereforene essaryto guar-anteetheintegrityofthe omponentsandtheauthenti ationoftheirissuer. Con dentiality willnotbe onsideredfurther.
Se urity me hanisms must not imply modi ations in the deployment pro ess. Users (andplatforms)must ontinue tousetheir omponentplatforms andto updateit without modi ation. Consequently, the signed omponents must be deliveredas asingle ar hive whi h in ludes both the original resour es and the data ne essary for verifying integrity and authenti ation. Otherwise, the se urityme hanismsare nottransparent, theywill be reje tedbytheusers,andwillnothelpimprovethese urityofthesystems.
Inthe aseofOSGi
tm
platforms,thesolution onsistsinin ludingthedigitalsignature in the omponent(also named bundle) itself. Consequently, it is not possibleto signthe whole omponent. Alistofresour espresentinthe omponentandoftheirrespe tivehash value is built. This list is the one that is signed, and in luded in the meta-data of the omponentalongwiththesignature.
This se tion rst presents an overview of the entities that intervene in the se ure de-ploymentofbundles,oftherequirementsandofthepro essforsigningandverifyingsigned omponents. Next,itdetailsthestru tureofasignedbundleasde nedforOSGi
tm
bundles. Lastly,thepro essofsignaturegenerationandsignaturevalidationwill bepresented.
3.1 Overview
This subse tionprovides anoverviewof the entities and data that intervenein se ure de-ployment of bundles in an OSGi
tm
platform. It shows how the digital signature an be exploitedin the ontextofbundledeployment,so asto guaranteetheintegrityof abundle andtheauthenti ationofitssigner.
First, the prin iples of bundle deployment are presented. Then, the requirements for supportingadigitalsignaturebasedse urityme hanismarepresented,aswellastheoverall pro essofbundlesigningandvalidating.
3.1.1 BundleDeployment
Thedeploymentof a bundle isthe partof its life y le that spans between theend of its developmentandthemomentitisreadytoprovideservi esonanOSGi
tm
platform. It on-tainsseveralsteps: publi ation ofthebundle, dis overy,dependen yresolution, download, installation, on guration. Update phasemustalsobetakenintoa ount[HHW99℄.
Two main types of deployment an be identi ed. The rst kind is platform-initiated deployment, whi h an be seen as 'pull deployment', where the signal that triggers the deploymentoriginatesfrom the omponentplatformitself. These ondkindofdeployment
o urswhen itisinitiatedthrougharemotesignal. Thiso urs forinstan ein the aseof onsole-basedremotemanagementofa omponentplatform[RF06℄.
Theentitiesthatinterveneinthedeploymentpro essarethefollowing:
The BundleIssuer, it is the person orsystem that makes the bundle available for the endusers. It anbeasoftwaredeveloperorasoftwarevendor.
The BundleRepository, it is theserverthat publishesthe bundles, that isto say that providearemotelya essibleservi esothat theendusers an ndanddownloadthe bundles.
The Exe ution platform, it is the omponent platform that exe utes the bundles. It must support bundle deployment, and often initiates it. In this report, it is also simply alledthe lient.
The deployment pro ess is initiated by a deployment trigger. This triggeris either a lo alshell(pulldeployment)oraremote onsole(pushdeployment).
Se uring thedeploymentpro ess impliesthat theexe ution platform onlydeploysand installsbundlesthat omefromtrustedissuers. Asfarasbundlesaresigned,they ansafely bepublished oninse urerepositories. The deploymenttrigger, onitsside, need to havea se ure ommuni ation hannel to the platform, so as to prevent deployment of bundles by untrustedparties. Moreover,it must be prote tedfrom undue use. The prote tionof deploymenttriggerrelatestosystemmanagementmorethantodeployment,soitwillnotbe studiedfurtherhere. Weassumethatonlyvalidusershavea esstotheexe utionplatform.
3.1.2 Requirementsfor Authenti ation
Subse tion 2.2 hasshown that the ondition forexploiting digitalsignature as amean of proving both integrity of a do ument and authenti ation of its signer is that the entity that he ks the signature (we will all it the lient) knows either the publi key of the signeritself, or the publi key of the erti ate issuer that has provided the signer'skey. Throughsignaturedelegation,a ompletehierar hyof erti ateissuers anexistbetween the erti ateissuerthe lientknowsandthesigneritself.
Inany ase,thesignermusthaveaprivatekeythat the lient antrust,andthe lient musthaveapubli keythat heknowsto betrustworthy. Typi ally,bothkeysareprovided bya ommon erti ationauthoritythroughase ure ommuni ation hannel.
Figure 13showstherequirementsfortheauthenti ationpro ess: thepubli keyofthe authenti atedpartmustbeknowntotheentitywhi hwishestoperformtheauthenti ation.
On etherequirementofkeyavailabilityisful lled,these uredeployment ano ur. Next se tion will present the internal stru ture of a signed bundle, and the way the digitalsignature isused to signnot onlyonedo ument, but also allavailable resour esof thebundle.
Figure13: Therequirementsfortheauthenti ationpro ess.
3.2 Stru ture of a Signed Bundle
Be ause ofthe parti ular onstraintson thesignatureof abundle, it is ne essarytostore it and all related resour esin the bundle itself. Moreover, it is mandatory that multiple signers ansignthesamebundle.
Thestru tureofasignedbundleisshownonFigure14.
SignatureFile andDigitalSignature
TheSignatureFileofasignedbundleisameta-data lethat the ontaintheSignature of theManifest le, that isto say itshashalue. ItguaranteestheintegrityoftheManifest le.
TheDigitalSignatureofa leisabytearraythat ontainsthe signatureofagiven lebyagivenperson,thatistosaythe en- ryptionofthehashvalueofthesigned le. Inasignedbundle, theDigitalSignatureoftheso- alledSignatureFileisstored in the Signature Blo k File. It guarantees theintegrity of theSignature Fileandtheidentityofthesigner
A rstsolutionforar hivesigning(bundlesarespe i jarar hives)isgivenbytheJar Ar hivespe i ations[Sun03℄. However,thisgivesthepossibilitytosignonlyasubsetofan ar hive. Thisimpliesthatmodi ationsarepossibleonthear hiveevenafter itssignature, whi h is a potential se urity leak. Therefore, OSGi
tm
spe i ationsrestri t thesignature by imposing that all resour es in an ar hive are signed by the signer(s). In the ontrary ase,thesignatureisnotvalid. Embeddedar hivesmustbesignedonthesameway. OSGi SignatureFilesonlyneedto ontainthehashvalueoftheManifest,hashvalueoftheother resour esarenotrequired[All05℄.
The Manifest le of the ar hive (1) ontains the hash valueof ea h resour e in the ar hive. To support several signers, the digital signature is applied not dire tly on the Manifest le,but onaso- alled`Signature File'(2),whi h isspe i toea hsigner. A hashvalueoftheManifest lemustbein luded. ThedigitalsignatureofthisSignature File is stored along with data that are ne essaryfor its validation in a CMS le of type `signed-data'whi h isnamed`SignatureBlo kFile'(3).
This stru ture of a signed bundlewill be enlightenedby asimple exampleof the Hel-loWorldbundle,whosesignerisnamedPIERREP.Thisbundle ontainsthree lasses: Hel-loWorldA tivator(the a tivator,orstarter,ofthebundle),HelloWorldInterfa e(the de ni-tionoftheHelloWorldInterfa eservi ethatisprovidedbythebundle),andHelloWorldImpl (theimplementationoftheabovementionedservi e).
The meta-data of the bundle are the following. First, the Manifest le, MANI-FEST.MF,whi h ontainsmeta-dataspe i toOSGi bundles,aswellasthehashvalue of allresour es. Se ondly, theSignature File, PIERRE.SF, ontains thehash valueof the Manifest le. Thirdly, the Signature Blo k File, PIERRE.DSA, is a CMS le that ontainsthedigitalsignatureof theSignature File,andthepubli key erti ateof thesigner. Theymustbestoredinthisorder(andbeforeallotherresour es)in thebundle ar hive.
A overview of the three meta-data les is shown is table 3. Spe i hara teristi sof ea hifthemeta-data lesusedforbundlesignaturearepresentedinsubsequentparagraphs.
File denomination Example Content
ManifestFile MANIFEST.MF Hashvalueforea hresour ein ar hive SignatureFile PIERREP.SF HashvalueoftheManifestFile Signature Blo kFile PIERREP.RSA DigitalSignatureof SignatureFile
Table3: Meta-datainvolvedin BundleSignature
3.2.1 The Manifest File
TheManifest lefortheHelloWorldexamplebundleisshowninFigure 15.
Figure15: TheManifestFilefortheHelloWorldExampleBundle.
TheManifest leof anOSGi
tm
bundle ontainsthemeta-datarequiredfor bundle de-ployment: the name of the bundle, its version, the pa kages it provides, the pa kages it dependson,itsa tivator lassforstartingit. Inasignedbundle,thismeta-dataisenri hed bythehash valueof ea h resour ethebundle ontains. A resour eis identi edbyits full path inside the bundle. It is ompleted bya property that indi ates its hash value. The propertynamedependsonthehash fun tionthat isused. Inourexample,thishash fun -tionisSHA-1, andthemat hing propertyis`SHA1-Digest'. Notethat amanifest le that ontainsresour eentries thatdonotexist in thear hiveorthat doesnotlist allresour es inthear hivehasprobablysuered additionorremovalofresour esandisnotvalid.
Storing the hash values of the resour es of the ar hive guarantees that none of this resour eshavebeentamperedwithafterthemomentthebundlehasbeensigned. Moreover, itguaranteesthat noresour ehavebeenaddedorremoved.
3.2.2 The Signature File
TheSignature lefortheHelloWorldexamplebundleisshowninFigure16.
Figure 16: TheSignatureFilefortheHelloWorldExampleBundle.
Ea h signer of a bundle reates its own signature in luding both Signature File and Signature Blo k File. The name of those le is the apitalized name of the signer. The SignatureFileisidenti edbya`.SF'extension. Forinstan e,inourexample,theSignature Fileisnamed`PIERREP.SF'.
TheSignature FileofsignedOSGi
tm
issimplerthattheoneofsignedJarar hives. As farasitisnotpossibleto signasubsetoftheresour e,no opyofthelistofthenameand hash valueof the resour esis required. Onlythe signature versionand thehash value of themanifestisne essary. Hashfun tionisusuallythesamethatisusedinthemanifestfor identifying resour es. InourHelloWorldexample,the hashvalueof themanifest isstored underthepropertyname`SHA-1-Digest-Manifest'.
Storing the hash value of the manifest le enables to guarantee that it has not been tamperedwithafterthemomentthebundlehasbeensigned.
3.2.3 The Signature Blo k File
TheSignatureBlo kFileof asignedbundle ontainsthedigitalsignatureoftheSignature Fileandalldatathatarene essaryto he kthevalidityofthesignature. Itsnameismade ofthe apitalizednameofthesigner. The leextensionisthenamedoftheen ryption algo-rithmusedforthedigitalsignature. Itisthereforeeither`RSA'or`DSA'.InourHelloWorld example,thenameisPIERREP.DSA.
The Signature Blo kFileis aCMS ompliant le (seesubse tion 2.1). It ontainsthe publi key erti ateofthesigner,andaSignerInfodatastru turewiththeidenti erofthe signerandthedigitalsignatureitself. It analso ontainaCerti ateRevo ationList.
TheSignatureBlo k ontainsavalidsignatureifthedigitalsignatureisavalidonefor the Signature File, and has been reatedusing the private keyof the signer. Of ourse, the validation pro ess must he k whether the publi key erti ate an be trusted (see subse tion 2.2). It guarantees that the Signature File has not been modi ed sin e the signatureo urred,andthatthesignerisatrustworthyone.
Thereader anreferintheFigure6foranexampleof aSignatureBlo kFile.
On ethestru tureofasignedbundleandofitsmeta-data leshavebeenpresented,the algorithmsusedforsigningthebundle,andforvalidating thissignature,willbedetailed.
3.3 The Pro ess of Signature and Validation
Thepro ess ofsigning bundlemust reate bundlemeta-datathat are ompliant with pre-sented spe i ations. Not only the meta-data ontent must be valid, but several other onstraintsmustalso be onsidered: theorder ofresour esin thear hiveandthe exhaus-tiveness ofidenti edresour es.
Of ourse, the pro ess of validation of the bundle signature must he k thesame on-straints.
3.3.1 Signature
Themain stepsofbundle signaturegeneration arethe following. First,thepubli /private keypairmustbeavailablebeforesigning. Thisistheinitializationphase. Next,themanifest le, MANIFEST.MF, is generated. It ontains the name of everyresour ein the bundle along with their hash value. Then, the Signature le is generated. It ontains the hash valueof themanifest le. TheSignature Blo kFile is generated, and ontainsthe digital signatureoftheSignatureFile,andthepubli key erti ateofthesigner. Lastly,thewhole ar hiveisgenerated,themeta-dataaresorted rst,andthentheotherresour es.
Figure 17 shows the algorithm for signing a bundle. You anrefer to gure 25 from Annexe6.3forfurtherdetails.
3.3.2 Validation
The pro ess of bundle signature validation is symmetri to the signature generation one. First,theentitythat he ksthesignatureneedstoauthenti atethesigner,thatistosayto he kwhetheritknowsitspubli key erti ateoritis apableofestablishingaCerti ate Pathbetweenthispubli key erti ate anda erti ate heknows (seesubse tion 2.2). If thesigner annotbeauthenti ated, itisnotworthtryingtoverifythesignature, be ause anybody anbuildavalidsignature.
The se ond step of thevalidation of bundle signature is theveri ationof the orre t order ofthe resour esin thear hive. As alreadymentioned, the rst lesmust be in this ordertheManifest le,theSignatureFileandtheSignatureBlo kFile. Allotherresour es omeafterwards.
Thethird step isthe validationof the oheren e of themeta-data les. TheSignature Blo kFile must ontainavalid digitalsignature of theSignature File bythe signer. The Signature Filemust ontainthe orre t hashvaluefor themanifest le. TheManifest le must ontainthehashvalueforallresour esofthear hive,withoutex eption,andwithout omission.
Whenthesethreestepsare he kedandvalid,thesignatureofthebundleisvalid. Should anyofthe riterianotbemet,thebundlesignatureisnotvalid.
Figure18showsthealgorithmforvalidatingasignedbundle. You anreferto gure26 fromAnnexe6.3forfurtherdetails.
3.4 Con lusions
Se uring the deployment of omponents implies to prote t the exe ution platform from mali ious omponentpublishers,andfrom potentialmodi ationsofthe omponentsafter theirpubli ation. Su hprote tionisa hievedinthe aseofOSGi
tm
bundlesbythesignature ofthebundles,whi his basedondigitalsignatureand enablesto storethesignatureitself and related data inside the bundle itself. The prote tion of bundles is done through two steps. First,the bundleis signedbya bundlepublisher thatis publi ly known. Se ondly, thebundlesignatureisvalidatedjustbeforebeinginstalled,soasto he kthatthesignature isvalidandthatthebundlehasnotsuered modi ations.
Su hapro essdoesnotpreventmali iouseavesdroppertostealthe ontentofthe om-ponent. This prote tion level would require on dentiality, and an not be a hieved by simpleintegrationofmeta-datainthe omponent. Itrequiresen ryptionofthe omponent, whi h makes ne essaryto havea dedi ated key management fa ility. Moreover,it would breakthe ompatibilityofpublished omponentswithunse uredplatforms.
4 Implementation: SFelix
SFelix 6
is the implementation of the bundle signature validation pro ess of the OSGi
tm
spe i ation, whi h is apartof OSGi
tm
Se urity Layer. It is provided together with the SFelixJarSignertool,whi henablestosignbundlesandtopublishthemonaFTPserver. It alsoprovidesthepossibilitytoupdatetherepositorymeta-data lefortheOSGi
tm
Bundle Repositoryversion2(OBR2). SFelixisbasedontheFelix
7
implementationoftheOSGi
tm
platform. Felixisaproje tfromtheApa heIn ubator,andisafollow-upofOs arOSGi
tm
platform 8
.
Totheextentofourknowledge,nootherimplementationofbundlesigningandvalidation fa ilityexistsfortheOSGi
tm
platform. SFelixisthenthe rstproje ttoprovideit,atleast in the Felix Proje t. Moreover, no Java implementation of ajar ar hive signer seems to beavailableasopensour eproje t. Atutorialexist ontheOnJavawebsite,butusesSun librariesthat havebeenremovedfromtheJavaVirtualMa hinedistribution
9 .
It has thus been ne essary to implement the whole bundle signature and validation pro ess in SFelix. An implementation of thealgorithms for signature andvalidation have beendeveloped(seesubse tion3.3).
4.1 Overview
We rst present anoverview ofthe prin iples of the SFelix se ure omponentdeployment appli ation. ItismadeupoftheplatformandoftheJarSignertool. Thepre iseroleofthe appli ationisdetailed,thenthestru tureoftheprogramanditspubli APIareexplained.
4.1.1 Role of SFelixplatformand SFelix JarSigner
SFelixJarSignerandSFelix overthewholedeploymentpro essof omponents.
SFelix JarSigner oversthe issuer side of the bundle deployment pro ess. It allows a bundle issuer to sign the bundle, and to publish them ona publi repository. Currently, onlytheFTPproto olissupportedfor letransfer,butanextensiontowardsotherproto ols su h asSSH orFTP/TLSis foreseen. Moreover,SFelixsupportsthe update ofthe meta-dataofthebundlerepository. Thesemeta-dataareaspe i lethat ontainsades ription ofbundlesthatareavailableonagiven(orevenseveral)bundlerepositories.Theyareused by lienttodis overwhi hbundlesareavailablefordownloadandinstallation,andtoinstall themtogetherwithotherbundlesthatarerequiredfordependen yresolution.
SFelix oversthe lient-sidepartofthedeploymentpro ess. Itvalidatesallexisting bun-dlesattheplatformlaun htime. Onlyvalidbundlesareinstalled,otheroneareignored.In the aseoftheinstallationofnewbundles,theselatterare he kedbeforetheirinstallation. This isdone independentlyof thelo ation of thebundle, beingstored lo ally orretrieved
6 http://sfelix.gforge.inria.fr/ 7 http://in ubator.apa he.org/felix/ 8 http://os ar.obje tweb.org/ 9 http://www.onjava. om/pub/a/onjava/2001/04/12/ signing_jar.html
fromabundlerepository. Validbundlesareinstalled,unvalidonesreje ted. Duringbundle update,thesameveri ationo urs.
SFelix bundle validation o urs independently of the type of deployment trigger. It supportspushdeployment(initiatedfromtheplatform)aswellaspulldeployment(initiated fromaremoteshell or onsole).
4.1.2 Stru ture ofthe Program
Thegeneralar hite ture ofSFelix isthe following. These uritylayer(whi h in ludes the bundlevalidation fa ility)is provided asalibraryusedbythe OSGi
tm
platform. This one has been slightly modi ed so as to he k the validity of the signature of a bundle before installingit. TheSFelixsignertoolisprovidedasOSGi
tm
bundles.
Figure19showsthegeneralar hite tureoftheSe ureFelix(SFelix)platform.
Figure 19: ThegeneralAr hite tureoftheSe ureFelix(SFelix)Platform.
4.1.3 The API
TheAPIofSFelixisreallysimple. Itismadeofamethod forsigningbundles,andanother oneforvalidatingtheirsignature.
ThesignatureAPIisprovidedbythe lassfr.inria.ares.jarsigner.JarSigner.Themethod is namedsign(), and takesasparametertheJar le that is to be signed, thename ofthe lewherethesignedbundleisto bestored,aswellasthenameofthesigner,thepassword toa esstheKeystore,andthepasswordthat prote tstheprivatekeyofthesigner.
ThesignaturevalidationAPIisprovidedbythe lassfr.inria.ares.jarvalidation.JarValidation. Thesinglemethod isnamed he k(),andtakesasparametersthebundletobeveri ed(as aFileobje t)andthepasswordoftheKeystore.
Figure20showsthepubli Appli ationProgrammingInterfa e(API)oftheSFelix plat-form.
Figure20: Thepubli APIoftheSe ureFelix(SFelix)Platform.
Next subse tion will present with more detail the SFelix bundle signature validation fa ility,aswellasmodi ationthathavebeendonetoFelixtointegratethisadditionalstep onthedeploymentpro ess.
4.2 Felix Modi ations for Bundle Validation
Soasto supportbundle validation,thealgorithmpresentedin subse tion 3.3must be im-plemented, and exe uted for ea h bundle that is installed (or updated) on the platform. Moreover, the Felix platform must be slightly modi ed so as to integrated the stage of bundlevalidationin theinstallation pro ess. Thesemodi ationsbuildthebridgebetween theFelix andSFelixplatforms. Modi ationsto the odewill bepresented,aswell asthe exe utionpro essatlaun htimeandatruntime.
4.2.1 The Code
ThevalidationAPI, JarValidation,isprovided asaseparatedlibrarythat isloaded atthe laun htimeoftheOSGi
tm
platform. Thislibraryis alledimmediatelybeforetheee tive installationofea hbundle. Whenthebundleisvalid,installationispro essednormally. In the ontrary ase,theinstallationabortsandthebundleisremovedfromthelistofavailable bundles. Allfollowingbundlesare he kedandinstalleda ordingtothesamepro ess.
Theintegrationof thebundle validationpro essonlyrequires themodi ationofthree lasses, BundleAr hive, BundleCa he and Felix, and the addition of the DefaultSe ure-BundleAr hive lass. Allremaining odeisprovidedinaseparatelibrary,jarvalidation.jar, whi h isrequiredbytheSFelixplatformat laun htime.
4.2.2 Laun h Timeof the SFelix Platform
TheSFelixplatformaimsat preventingmali iousbundlesto be installedandexe uted. It needs to a hieve its goalwhile limiting as mu h as possible the intera tion with its user (ormanager). These urityme hanismsmustbeastransparentaspossible,soasto avoid deterring theusersfrom exploiting them. Forguaranteeingthat the installed bundlesare valid, it is ne essaryto be able to assert that the platform itself has not been tampered with. Thevalidation pro ess thereforeo urs in twosteps. First, theplatform odemust beveri ed. Se ondly,theplatform,thatisknowntobevalid, he ksea hinstalledbundles. Thevalidationoftheplatform odeitself anbedonemanuallythroughar hivesigning inawaysimilartothebundlevalidation. However,inour ase,theintegrityoftheplatform ode is simply veri ed throughits hash value. The laun h s ript ontainingoriginal hash values is publi ly available online on the proje t web site. Its exe ution guarantees the validityofthe odear hive.
Theplatform anthensafely he kthevalidityofthesignatureofexternalbundles. At laun htime,allbundlesarevalidatedbeforetheirinstallation. Ifonebundleisnotvalid,it issimplyreje ted, and theinstallationofthe otherbundlesgoeson. Forea hbundle that is orre tlyinstalled,a on rmationofinstallation isprintedintheshelltotheuser.
Theonlyintera tionbetweentheplatformandtheusero ursthroughthe(S)Felixshell duringthevalidationofthe rstbundle. TheuserisaskedforthepasswordoftheKeystore, whi hisne essarytoretrievethelistof erti atethatare onsideredtrustful. Afterwards, thepasswordisstoredinthe oreoftheplatform,andreusedforea hvalidationofabundle. Sin ethe omponentsonlyhavea esstotheplatformthroughthebundle ontext,andnot dire tly,thiswayofstoringthepasswordissound.
The following ode(Figure 21)show theoutputwhen laun hing anewOSGi
tm
pro le withSFelix. Notethepasswordrequestandthenoti ationofbundlevalidation.
4.2.3 Runtimeof the SFelixPlatform
Whenbundlesareinstalledduringtheruntimeoftheplatform,orwhenbundlesareupdated, thesameveri ationpro ess o urs. Valid bundlesare installed,and invalid onereje ted. Thisisof oursetrueindependentlyofthelo ationofinstalledbundles,whish anbelo al orstoredinaremoterepository.
Figure22showsas reen-shotoftheFelixshellwhentryingtoinstallanunsignedbundle.
The SFelix platform enablesto validate all bundles that are exe uted before their in-stallation. The orre tness of the validation pro ess is guaranteed by the veri ation of the platform ode before laun hing the platform. In our urrent implementation, this is simplya hievedthroughhash-valuebasedveri ationofthe ode. More ompletesolutions are ne essary to a hievehigh level se urity, but depends on the exe ution ontext of the platform.
Theexisten eofase ureOSGi
tm
platformthatvalidatesbundlesbeforeinstallingthem makes itne essaryto have atoolavailable that support thepro essof signing them. We
Figure21: S reen-shotof SFelixshellwhenlaun hinganewSFelixPro le
therefore developed SFelixJarSigner. Soas to support the whole deployment pro ess, an additionalfa ilityisin ludedthatenablestopublishsignedbundlesin aremote le reposi-tory.
4.3 Tool: SFelix JarSigner
The SFelix JarSigner toolaims at supporting the publi ation part of thepro ess of om-ponent deployment. The publi ation is made of the signing of the bundles, and of their transfertoapubli bundlerepository. Thefun tionsofSFelixJarSignerare rstpresented, andthevariousbundlesthat omposeitaredetailed.
4.3.1 Fun tions ofJarSigner
JarSignerGraphi alUserInterfa eis omposedof threemain parts. The rstaims atthe onne tionto theKeystore. The se onddealswith bundlesigning. Thethirdis dedi ated tothepubli ationofbundlesontoaremoterepository.
The Keystore a ess takesasinputthename (Alias) of theperson that wantsto signbundles. ItalsotakesthegeneralpasswordoftheKeystore,thatenablestoa ess the listof trusted erti ates, and thepasswordthat prote tstheprivate keyofthe signer. The'OpenSession'buttonmakesitpossibleto he ktheparti ularalgorithm that isbound tothe urrentalias.
The lesigningpartenablestospe ifythenameofthebundlethatistobesigned,as wellasthenameofthefuturesignedbundle. Notethatthesenamesmustbedierent. Severala tionsoverthebundle anberealized. It anof oursebesigned,but it an alsosimplybe he ked. Whensigningor he kingabundlethroughthe'TreatBundle' button,theoutputofthepro ess(su ess/failure)isprintedin aspe i information eld at the bottom of the window. Moreover, bundles that are signed orre tly or whi h signature is validated are added to the 'Sele ted Bundle' list, that makes it possibleto hosewhi hbundleistobepublished.
The publi ation fa ility ofSFelix ontainstheabovementioned'Sele ted Bundle' list,alistof leservers,anda'LoadFile(s)'buttonthattriggersthepubli ation. A vail-able bundlesare ex lusivelythe signedones, but le servers anbeadded, modi ed andremovedbytheuserofSFelixJarSigner.
Figure23showstheGraphi alUserInterfa eoftheSFelixJarSignertool. Thedierent partsofthetoolthat havebeenpresentedin thisse tion anbeobserved.
ThemodularorganizationofSFelixJarSignerwillthenbepresented.
4.3.2 Bundles of JarSigner
SFelix JarSigner is an OSGi
tm
appli ation. It is a tool that makes it possible to se ure bundledeployment, andisitself madeupof validatedbundles: it isexe utedinthe SFelix
platform. Toexe uteitinanotherOSGi
tm
platformwouldrequiretomakethejarvalidation libraryavailable asanar hive. This isquiteeasyto a hieve,but, sin eit isnot ompliant withOSGi
tm
spe i ations,itisoutofthes opeofthisstudy.
SFelix is built of three sets of ode. The rst one is the jarvalidation library. The se ond one is a lightweight plug-in support we developed for graphi al interfa es named omponentGui. Thelastoneisof oursetheJarSignertoolitself.
Thejarvalidationlibraryprovidesthe ryptographi library,thelibraryfora essingto theKeystore,aswellasthebundlevalidation APIwhi hisalsousedin JarSigner.
The omponentGuifa ilityis provided asaset oftwobundles. The rst oneis named `SFelixUtilities',andprovidesvariouslibrariesforgraphi alinterfa eselements. These ond oneisnamed`Generi Frame',andprovidesasimplegraphi alwindowthat ontainsthelist ofallGraphi al UserInterfa esthat areavailablein theplatform. These GUIs aretagged bythefr.inria.ares.sfelix.utils.GuiSwingComponentprogramminginterfa etheyimplement. Theyaremadeavailable asOSGi
tm
servi es.
TheJarSignertoolis omposedoftwobundles,`JarSigner',whi hprovidestheservi e forsigningbundles,and`JarSignerGUI',whi hprovidesthegraphi alinterfa ethatallows toa essthesignatureservi e. Thisinterfa ehavebeenpresentedintheprevioussubse tion. Thefollowing ode( gure 24)showstheoutput whenlaun hingSFelixJarSigner. The on rmation of thevalidation of thesignature is printed forea h bundle, andthe various bundlesthatwere presentedarelisted.
4.4 Con lusions
In this se tion, the SFelix platform and the SFelix JarSigner tool have been presented. Used together, theysupport the whole pro ess of se ure deployment for OSGi
tm
bundles: signature,publi ation,andremoteinstallationthroughtheOBR2bundlerepositoryifthe bundles havea valid signature. SFelix is based on theFelix OSGi
tm
implementation: all bundlesthatruninSFelixalsorunonFelix,butFelixbundlesneedtobesignedbyaknown personbefore beingintegratedinthese ureSFelixplatform.
5 Con lusions
Until now, onlyveryfew eortseemsto havebeendedi ated to se uring omponent plat-forms. Duetotheevenbroaderdisseminationofsu hplatforms,itappearstobene essary to foster knowledge about se urity issues in omponent platforms. This work intends to make it possible for not se urity spe ialists to take su h stakesinto a ount when build-inga systembasedon a omponent platform. It istargeted to theOSGi
tm
platform, but presented on epts aneasilybemappedtowardsother omponentssystems.
This te hni al report gives a detailed overview of me hanisms that intervene during omponentsignatureandvalidation,in ludingthe ryptographi on eptsthatarene essary tounderstandthewholepro ess.
Mat hingimplementationofbundlesignatureandvalidationisintrodu ed. Bundle vali-dationispartofOSGi
tm
Release4Se urityLayer,andisassu hintegratedintheOSGi
tm
framework. Ourimplementationis availablein theSFelixframework,whi hisanextension oftheFelixOSGi
tm
implementation. Bundlesignatureisprovidedasastand-alone appli a-tion,SFelixJarSigner. This toolalsosupports publi ationof bundlein publi ly a essible servers.
This work has broughtto light further needs for se urity in omponent platforms. In parti ular,bundlevalidationimpliesthat lientshavareliableinformationsaboutthesigner. Severalquestionsemerge: howtomakesure lientshavea esstoallbundletheyareallowed toinstall? Howtorestri tthea essfrom ertain lientsto ertainsigners ? Howtodeal with new signers ? And how to dealwith previoussigners that are no longer allowed to publish bundles ? Moreover, it an sometime be ne essary to be able to revoke isolated bundles,withoutpreventingvalidbundlestobeinstalled.
6 Annexes
6.1 Existing Tools for Se ure Java Appli ations
Existingtools that are add-onsto the JavaVirtual Ma hine are jar signingfa ilities, and lass ipheringsoftware.
SigningJars Somefa ilitiesalreadyexistforsigningjar. Themain oneisSunJarsigner [Sun04℄, that providesa ommand lineutilityfor signingjars. It resemblesmu h toOSGi Se urityLayer,but hasadierentapproa h:
it is no Javaprogram, but a ommand line tool. This is not onsistent with OSGi spe i ation,whi hstatesthattheSe urityLayerispla edbetweentheJavaVirtual Ma hineandOSGiplatform,
one an not assume that an OSGi platform exe uting in a previsouly unknown en-vironnementhave ne essaryrightsto exe ute third partyprogram throughJNI, nor that thisthirdpartyprogram(hereSunJarsigner)isavailable
andlastbutnotleast,OSGispe i ationbringsitsown ontraintsonar hivesignature that arenotspe i edbyJarspe i ation,andthusnotenfor edbySunJarsigner.
Moreover,no readilyavailable library forsigning jar isavailable. Oneimplementation hasbeenproposed byRa Krikorianin anOn-Javaarti le. However,thisimplementation useaSunAPIthatisnolongersupported,asfarasithasbeenprovedtobeinse ure.
Ciphering of Classes Besides signingar hive,another wayto prote t lassesisto en- ryptthem,andtode ryptthemonlyatruntimefortheexe ution. Thiste hniqueenables toguaranteenotonlyintegrityofsour esandauthenti ationoftheemitter,butalso on -dentialityagainstpotentialmali iousthirdparties.
All su h libraries that are available are not free. Two of them, Canner and Katirya, are urrentlyonlyavailable fortheMi rosoftWindowsenvironment. Canner,byCinnabar Systems
10
, reatesanexe utable lethatthenexe utesonthelo alJVM.Katirya 11
works a ordingtothesameprin iple. jLo kistheonlytoolthatdonotonlyworkonMSWindows. Itpat hestheVirtualMa hinesoastointegrateruntimede ryptionofen rypted lasses
12 . Available toolsfor ensuringse urityin Javaappli ationsare stillquite limited. This is explainedbythefa tthatmostse urityproblemsareappli ationandenvironnementspe i . Therefore, eort for improving se urity in java system is either entered on the Virtual Ma hineitself-whi hdoesitsjobin aquitesatisfa torymanner-oronprovidingtoolsets for spe i appli ations. It is thus ne essaryto developp ourown tools for implementing OSGiSe urityLayer.
10
http://www. innabarsystems. om/ anner.html 11
http://www.my giserver. om/
∼
ipnetdevelop/katirya.html 126.2 Java Cryptographi Libraries
Developping our own toolsfor enfor ing Javase urity means providing a generi se urity APIforsigningandverifyingjars. Su hanAPIneedstoreleaveonavalidimplementation of ryptographi algorithms for hashvalue, digitalsignatureand en ryption. Su h an im-plementationisof ourseoutofs opeofourwork,andseveral ryptographi librarieshave beendeveloppedre ently.
This libraries aneasily bepluggedin javaprograms throughthe providerme hanism: byindi ating the abbreviation mat hing an available provider at a ryptographi method all,the aller ensuresthat thisprovideristhe onethat performs the ryptographi oper-ation. This makesitpossibleto integratethird partyproviders,but also tovalidate them independantlyoftheirappli ations.
A list of se urity provider is maintained by Sun 13
. The prin ipal open sour e ryp-tographi library has been developped by the Legion of the Boun y Castle
14
. However, forappli ationsthat needmorethanabasi levelof se urity, these ryptographi libraries need to be validated. The referen e organization for ryptographi module validation is theAmeri anNationalInstituteof StandardsandTe hnology(NIST)that hasdevelopped theFederalInformationPro essingStandards(FIPS)programforvalidating ryptographi libraries[Nat℄. SeveralJavalibraries haveundergone su h a validation,someof them are availableforuseasindependantsoftwareparts. TheselibrariesareRSABSAFECrypto-J, IBM SSLite and CryptoLite, Certi om Se urity Builder FIPS Java Module, and Entrust AuthoritySe urityToolkitfortheJavaPlatform.
6.3 Algorithm for Bundle Signature and Validation
Figure25showsthedetailedsequen ediagramofthealgorithmforsigningabundle. Figure 26showsthedetailed sequen ediagram ofthealgorithm forvalidatingasigned bundle.
13
http://java.sun. om/produ ts/j e/j e122_providers.html 14
e
Comp
onent
Deployment
JarSigner
KeyStoreManager
CryptographicLibrary
privateKey : getPrivateKey(signer, password)
SignedJarManifest
manifest : new(Jar, hashAlgorithm)
SignatureFile
signatureFile : new(manifest, signer)
JarSignerGui
: sign(jarFile, signer, password)
SignatureBlock
block : new(signatureFile, cert, privateKey)
cert : getCertificate(signer, password)
SignedJarFile
: buildSignedjarFile
hash : getHashValue(fileData, algo)
for all file in archive
hash : getHashValue(manifest, algo)
CMSfile : getCMSFData(signatureFile, cert, privateKey)
boolean : result
Created with Poseidon for UML Community Edition. Not for Commercial Use.
Figure 25: The Sequen e Diagram of the Algorithm for signing a Bundle. 0323
Parr
Felix
JarValidation
: check(file, password)
SignedJarFile
: new(file)
Certificate[] : getValidCertificates(password)
boolean : checkCoherence(certificate)
for each valid
certificate
KeyStoreManager
boolean : isValid(Certificate, password)
for each
certificate
boolean : checkResourceOrderValid()
boolean : checkSignatureBlockValidity(signer)
CryptographicLibrary
boolean : checkCMSDataValidity(signatureFile, block)
boolean : checkSignatureFileValidity(signatureFile, manifest)
boolean : checkHashValue(manifestHash, pretendedHash, algo)
boolean : checkManifestValidity()
boolean : result
boolean : result
boolean : checkHashValue(manifestHash, pretendedHash, algo)
for each file
in archive
26: The Sequen e Diagram of the Algorithm for v alidating a signedReferen es
[AB96℄ AndersonandBiham.Tiger: Afastnewhashfun tion.InIWFSE:International Workshopon FastSoftwareEn ryption,LNCS,1996.
[AJB00℄ A.Avizienis,J.C.Laprie,andB.Randell. Fundamental on eptsofdependability. Te hni al Report No00493, LAAS (Toulouse, Fran e), 2000. 3rd Information SurvivabilityWorkshop (ISW'2000),Boston (USA), 24-26O tobre2000, pp.7-12.
[All05℄ OSGI Allian e. Osgi servi e platform, ore spe i ation release 4. Draft, 07 2005.
[Bur93℄ Burton S.KaliskiJr. Alayman'sguidetoasubsetofasn.1,ber,andder. RSA LaboratoriesTe hni alNote,November1993.
[BWBL02℄ S. Blake-Wilson,D. Brown,andP.Lambert. Useofellipti urve ryptography (e )algorithmsin ryptographi messagesyntax( ms).IETFNetworkWorking Group,RequestforComments: 3278,April2002.
[HFPS99℄ R. Housley, W. Ford, W. Polk, and D. Solo. Internet x.509publi key infras-tru ture, erti ateand rlpro le. IETFNetworkWorkingGroup,Requestfor Comments: 2459,January1999.
[HHW99℄ Ri hardS.Hall,DennisHeimbigner,andAlexanderL.Wolf. A ooperative ap-proa htosupportsoftwaredeploymentusingthesoftwaredo k.InInternational Conferen e onSoftwareEngineering 1999, pages174183,1999.
[Hou02℄ R. Housley. Cryptographi message syntax ( ms). IETF RFC 3369, August 2002.
[Int04℄ InternationalStandardOrganization. Iso/ie 10118-3:2004. ISOStandard- In-formationte hnologySe urityte hniquesHash-fun tionsPart3: Dedi ated hash-fun tions,February2004.
[Nat℄ National Institute of Standards and Te hnology (NIST). Nist ryptographi modulevalidationprogram. http:// sr .nist.gov/ ryptval/140-1/1401val.htm.
[Nat93℄ National Instituteof Standardsand Te hnology (NIST). Se urehash standard (shs). FIPS Publi ation 180. Also published as RFC 3174 - US Se ure Hash Algorithm1(SHA1).,May1993.
[Nat94℄ NationalInstituteofStandardsandTe hnology(NIST). Digitalsignature stan-dard (dss). Federal Information Pro essing Standards Publi ation 186, May 1994.
