17thACMSymposiumonOperatingSystemsPrinciples(SOSP'99)
PublishedasOperatingSystemsReview34(5):124–139, Dec.1999
Separatingkeymanagementfromfile systemsecurity
DavidMazi
`
eres,MichaelKaminsky,M.FransKaashoek,andEmmettWitchel
MITLaboratoryforComputerScience
dm@lcs.mit.edu,kaminsky@lcs.mit.edu,kaashoek@lcs.mit.edu,witchel@lcs.mit.edu
Abstract
Nosecurenetworkfile systemhasevergrowntospantheIn-
ternet. Existingsystemsalllackadequatekeymanagement
forsecurityataglobalscale. GiventhediversityoftheIn-
ternet, anyparticularmechanismafile e systememploys s to
managekeyswillfailtosupportmanytypesofuse.
Weproposeseparatingkeymanagementfromfile system
security,lettingtheworldshareasingleglobalfile systemno
matterhowindividualsmanagekeys. WepresentSFS,ase-
curefile systemthatavoidsinternalkeymanagement.While
otherfile systemsneedkeymanagementtomapfile e names
toencryptionkeys,SFSfile nameseffectivelycontainpublic
keys,makingthemself-certifyingpathnames. Keymanage-
mentinSFSoccursoutsideofthefile system,inwhatever
procedureuserschoosetogeneratefile names.
Self-certifyingpathnamesfreeSFSclientsfromanynotion
ofadministrativerealm,makinginter-realmfile sharingtriv-
ial. Theyletusersauthenticateserversthroughanumber
ofdifferenttechniques. Thefile e namespacedoublesasakey
certification namespace,sothatpeoplecanrealizemanykey
managementschemesusingonlystandardfile utilities. . Fi-
nally,withself-certifyingpathnames, peoplecanbootstrap
onekeymanagementmechanismusinganother.Theseprop-
erties make SFSmoreversatile thanany file e systemwith
built-inkeymanagement.
1 Introduction
ThispaperpresentsSFS, asecurenetworkfile e systemde-
signedtospantheInternet. SFSpreventsmanyvulnerabil-
itiescausedbytoday'sinsecurenetworkfile systemproto-
Thisresearch was partiallysupported byaNationalScienceFoundation
(NSF) Young Investigator Award and d the e Defense Advanced Research
ProjectsAgency(DARPA)andRomeLaboratoryunderagreementnumber
F30602-97-2-0288.
Permissionto makedigitalorhardcopies ofallorpartofthiswork for
personalorclassroomuseisgrantedwithoutfeeprovidedthatcopiesare
notmadeordistributedforprofit orcommercialadvantage,andthatcopies
bearthisnoticeandthefullcitationonthefirst page.Tocopyotherwise,to
republish,topostonserversortoredistributetolistsrequirespriorspecific
permissionand/orafee.
SOSP-1712/1999KiawahIsland,SC
c
1999ACM1-58113-140-2/99/0012...$5.00
cols. Itmakesfile e sharingacrossadministrativerealmstriv-
ial,lettingusersaccessfiles fromanywhereandsharefiles
withanyone. Mostimportantly, , SFSsupportsa moredi-
verserangeofusesthananyothersecurefile system. . It
canmeettheneedsofsoftwarevendors, unclassified d mili-
tarynetworks,andevenstudentsrunningfile serversintheir
dormrooms. Inallcases,SFSstrivestoavoidcumbersome
securityproceduresthatcouldhinderdeployment.
Fewpeopleusesecurenetworkfile systemstoday,despite
thefactthatattackerscaneasilytamperwithnetworktraffic.
Foryears,researchershaveknownhowtodesignandbuild
file systemsthatworkoveruntrustednetworks(forinstance
Echo[4]).Ifsuchafile systemcouldgrowtospantheInter-
net,itwouldletpeopleaccessandsharefiles securelywith
anyoneanywhere.Unfortunately,noexistingfile systemhas
realizedthisgoal.
Theproblemliesinthefactthat, atthescaleoftheIn-
ternet,securityeasilybecomesamanagementandusability
nightmare.Specifically ,thereexistsnosatisfactorymeansof
managingencryptionkeysinsuchalargeanddiversenet-
work.Thewrongkeymanagementpolicyharmssecurityor
severelyinconveniencespeople. Yet,onaglobalscale,dif-
ferentpeoplehavevastlydifferentsecurityneeds.Nosingle
approachtokeymanagementcanpossiblysatisfyeveryuser.
Mostsecuresystemslimittheirusefulnessbysettlingfora
particularapproachtokeymanagement. Considerhowfew
peoplerunsecurewebserverscomparedtoordinaryones.
EstablishingasecurewebserverwithSSLinvolvessignif-
icanttime, complexity,andcost. . Similarly,inthedomain
ofremoteloginprotocols, anyonewhohasusedbothKer-
beros[29]andthedecentralizedssh[34]packageknowshow
poorlytheKerberossecuritymodelfits settingsinwhichuser
accountsarenotcentrallymanaged.Unfortunately,mostse-
curefile systemscometightlycoupledwithakeymanage-
mentsystemthatcloselyresembleseitherKerberosorSSL.
SFStakesanewapproachtofile systemsecurity: : itre-
moveskeymanagementfromthefile systementirely. . SFS
introducesself-certifyingpathnames—file
namesthateffec-
tivelycontaintheappropriateremoteserver'spublickey.Be-
causeself-certifyingpathnamesalreadyspecifypublickeys,
SFSneedsnoseparatekeymanagementmachinerytocom-
municatesecurelywithfile servers. . Thus, , whileotherfile
systemshavespecific policiesforassigningfile e namestoen-
124
Pdf to text - control SDK platform:C# PDF Convert to Text SDK: Convert PDF to txt files in C#.net, ASP.NET MVC, WinForms, WPF application
C# PDF to Text (TXT) Converting Library to Convert PDF to Text
www.rasteredge.com
Pdf to text - control SDK platform:VB.NET PDF Convert to Text SDK: Convert PDF to txt files in vb.net, ASP.NET MVC, WinForms, WPF application
VB.NET Guide and Sample Codes to Convert PDF to Text in .NET Project
www.rasteredge.com
cryptionkeys,SFS'skeymanagementpolicyresultsfromthe
choiceusersmakeofwhichfile namestoaccessinthefirst
place.
SFSfurtherdecouplesuserauthenticationfrom thefile
systemthroughamodulararchitecture. Externalprograms
authenticateuserswithprotocolsopaquetothefile system
softwareitself. Theseprogramscommunicatewiththefile
systemsoftwarethroughwell-defined RPCinterfaces.Thus,
programmerscaneasilyreplacethemwithouttouchingthe
coreofthefile system.
Pushingkeymanagementoutofthefile systemlets s ar-
bitrarykey managementpolicies s coexistonthe same file
system, whichinturnmakesSFSusefulinawide range
of file e sharing g situations. . This s paper r will l describe nu-
merous key y managementtechniques s built on n top of SFS.
Two in n particular—certification
authorities and password
authentication—both
fill important t needs. . Neither r could
havebeenimplementedhadtheotherbeenwiredintothe
file system.
Withoutmandatinganyparticularapproachtokeyman-
agement,SFSitselfalsoprovidesagreatkeymanagement
infrastructure.Symboliclinksassignhuman-readablenames
toself-certifyingpathnames.Thus,SFS'sglobalnamespace
functionsasakeycertification namespace. . Onecanrealize
manykeymanagementschemesusingonlysimplefile utili-
ties. Moreover,peoplecanbootstraponekeymanagement
mechanism withanother. . Inpractice, , wehavefoundthe
abilitytocombinevariouskeymanagementschemesquite
powerful.
WeimplementedSFSfocusingonthreemajorgoals:se-
curity,extensibility,andportability. Weachievedportabil-
itybyrunninginuserspaceandspeakinganexistingnet-
workfile systemprotocol(NFS[23])tothelocalmachine.
Asaresult,theSFSclientandserversoftwarerunonmost
UNIXplatforms. Wesacrificed d performanceforportability
inourimplementation. Nonetheless,evenfromuser-space,
SFSperformscomparablytoNFSversion3onapplication
benchmarks.Severaloftheauthorshavetheirhomedirecto-
riesonSFSandperformalltheirworkonit.
2 Design
SFS'sdesignhasanumberofkeyideas. SFSnamesfiles
withself-certifyingpathnamesthatallowittoauthenticate
servers without performingkeymanagement. . Througha
modularimplementation, SFSalsopushesuserauthentica-
tionoutofthefile system. . SFSitselffunctionsasaconve-
nientkeymanagementinfrastructure,makingiteasytoim-
plementandcombinevariouskeymanagementmechanisms.
Finally,SFSseparateskeyrevocationfromkeydistribution,
preventingfle xibilityinkeymanagementfromhinderingre-
coveryfromcompromisedkeys.Thissectiondetailsthede-
signofSFS.
2.1 Goals
SFS'sgoalofspanningtheInternetfacedtwochallenges:se-
curityandthediversityoftheInternet.Attackerscaneasily
tamperwithnetworktraffic, makingstrongsecurityneces-
sarybeforepeoplecantrusttheirfiles toaglobalfile system.
Atthesametime,SFSmustsatisfyawiderangeofInter-
netuserswithdifferentsecurityneeds.Itisnotsufficient for
SFStoscaletomanymachinesintheory—it mustalsosat-
isfythespecific needsofdiverseusersontheInternettoday.
Inshort,SFSneedsthreepropertiestoachieveitsgoals: a
globalfile systemimage,security,andversatility.
2.1.1 Globalfilesystemimage
SFS'sgoalofasingleglobalfile systemrequiresthatitlook
thesamefromeveryclientmachineintheworld. Itmust
notmatterwhichclientapersonusestoaccessherfiles—
a global file e system m shouldbehavethesameeverywhere.
Moreover,noincentiveshouldexistforsitestosubvertthe
globalimagebycreatingan“alternate” SFS(forinstance,
outoftheneedtohaveadifferentsetofserversvisible).
Tomeetthisgoal,westrippedtheSFSclientsoftwareof
anynotionofadministrativerealm.SFSclientshavenosite-
specific configuration n options.Serversgrantaccesstousers,
nottoclients.Userscanhaveaccountsonmultiple,indepen-
dentlyadministeredservers.SFS'sglobalfile systemimage
thenallowssimultaneousaccesstoalltheserversfromany
client.
2.1.2 Security
SFSsplitsoverallsecurityintotwopieces: file systemse-
curityandkeymanagement. SFSproperprovidesonlyfile
systemsecurity.Informally,thispropertymeansthatattack-
erscannotreadormodifythefile systemwithoutpermission,
andprogramsgetthecorrectcontentsofwhateverfiles they
askfor. Wedefine e thetermmorepreciselybyenumerating
theassumptionsandguaranteesthatSFSmakes.
SFSassumesthatuserstrusttheclientstheyuse—for in-
stance,clientsmustactuallyruntherealSFSsoftwaretoget
itsbenefits. Formostfile e systems,usersmustalsotrustthe
servertostore andreturnfile e datacorrectly(thoughpub-
lic,read-onlyfile systemscanresideonuntrustedservers).
To get practical l cryptography, , SFS S additionally assumes
computationally bounded adversaries s and d a few standard
complexity-theoretichardnessconjectures. Finally,SFSas-
sumes thatmaliciouspartiesentirelycontrol thenetwork.
Attackerscaninterceptpackets,tamperwiththem,andin-
jectnewpacketsontothenetwork.
Undertheseassumptions,SFSensuresthatattackerscan
donoworsethandelaythefile system'soperationorconceal
theexistenceofserversuntilreliablenetworkcommunica-
tionisreestablished.SFScryptographicallyenforcesallfile
125
control SDK platform:C# PDF Text Extract Library: extract text content from PDF file in
Text: Extract Text from PDF. |. Home ›› XDoc.PDF ›› C# PDF: Extract PDF Text. Enable extracting PDF text to another PDF file, TXT and SVG formats.
www.rasteredge.com
control SDK platform:VB.NET PDF Text Extract Library: extract text content from PDF
PDF ›› VB.NET PDF: Extract PDF Text. Advanced Visual Studio .NET PDF text extraction control, built in .NET framework 2.0 and compatible with Windows system.
www.rasteredge.com
accesscontrol. Userscannotread, , modify,delete, oroth-
erwisetamperwithfiles withoutpossessinganappropriate
secretkey,unlessanonymousaccessisexplicitlypermitted.
SFSalsocryptographicallyguaranteesthatresultsoffile sys-
temoperationscomefromtheappropriateserverorprivate
keyowner.Clientsandread-writeserversalwayscommuni-
cateoveralow-levelsecurechannelthatguaranteessecrecy,
dataintegrity, freshness(includingreplayprevention),and
forwardsecrecy(secrecyofpreviouslyrecordedencrypted
transmissionsinthefaceofasubsequentcompromise).The
encryptionkeysforthesechannelscannotbeshortenedto
insecurelengthswithoutbreakingcompatibility.
File system security initselfdoes notusuallysatisfya
user'soverallsecurityneeds.Keymanagementletstheuser
harness file e system m security y to meethigher-levelsecurity
goals. Therightkeymanagementmechanismdependson
thedetailsofauser'shigher-levelgoals.Ausermaywantto
accessafile serverauthenticatedbyvirtueofapre-arranged
secretpassword,orelsethefile systemofawell-knowncom-
pany,oreventhecatalogofanyreputablemerchantsellinga
particularproduct.Nokeymanagementmechanismsatisfies
allneeds. Thus,SFStakestheapproachofsatisfyingmany
keymanagementmechanisms; itprovidespowerfulprimi-
tivesfromwhichuserscaneasilybuildawiderangeofkey
managementmechanisms.
2.1.3 Versatility
SFSshouldsupportasbroadarangeofusesaspossible—
frompassword-authenticatedaccesstoone'spersonalfiles to
browsingwell-knownservers. Inallcases,SFSmustavoid
unnecessarybarriers todeployment. . Inparticular, , anyone
withanInternetaddressordomainnameshouldbeableto
createanewfile serverwithoutconsultingorregisteringwith
anyauthority.
SFSachievesversatilitywiththreeproperties:anegalitar-
iannamespace, apowerfulsetofprimitiveswithwhichto
implementkeymanagement,andmodularity. ThoughSFS
giveseveryfile thesamenameoneveryclient,noonecon-
trolstheglobalnamespace;everyonehastherighttoadda
newservertothisnamespace.
SFS'ssecure,globalnamespacealsofacilitatesabroadar-
rayofkeymanagementschemes. Onecanimplementmany
schemesbysimplycreatingandservingfiles overSFS.SFS
alsoletsusersemployarbitraryalgorithmsduringfile name
resolutiontolookupandcertifypublickeys.Differentusers
canemploydifferenttechniquestocertifythesameserver;
SFSletsthemsafelysharethefile cache.
Finally, SFShas amodularimplementation. . Theclient
andserverareeachbrokenintoanumberofprogramsthat
communicatethroughwell-defined interfaces.Thisarchitec-
turemakesiteasytoreplaceindividualpartsofthesystem
andtoaddnewones—including
newfile systemanduser-
authenticationprotocols.Severalpiecesofclientfunctional-
ity,includinguserauthentication,occurinunprivilegedpro-
cessesunderthecontrolofindividualusers.Userstherefore
haveamaximalamountofconfiguration controloverthefile
system,whichhelpseliminatetheneedforclientstoknow
aboutadministrativerealms.
2.2 Self-certifyingpathnames
Asadirectconsequenceofitsdesigngoals,SFSmustcryp-
tographicallyguaranteethecontentsofremotefiles without
relyingonexternalinformation. SFScannotuselocalcon-
figuration files tohelpprovidethisguarantee,assuchfiles
wouldviolatetheglobalfile systemimage. . SFScannotre-
quireaglobalauthoritytocoordinatesecurityeither,assuch
anauthoritywouldseverelylimitversatility.Individualusers
mightsupplyclientswithsecurityinformation,butthisap-
proachwouldmakesharingafile cacheverydifficult t be-
tweenmutuallydistrustfulusers.
Withoutexternalinformation, SFSmustobtainfile e data
securelygivenonlyafile name. . SFSthereforeintroduces
self-certifyingpathnames—file
namesthatinherentlyspec-
ifyallinformationnecessarytocommunicatesecurelywith
remotefile servers,namelyanetworkaddressandapublic
key.
EverySFSfile systemisaccessibleunderapathnameof
the form
Location
HostIDLocationtells an n SFS
clientwheretolookforthefile system'sserver,whileHostID
tellstheclienthowtocertifyasecurechanneltothatserver.
LocationcanbeeitheraDNShostnameoranIPaddress.
Toachievesecurecommunication,everySFSserverhasa
publickey. HostIDisacryptographichashofthatkeyand
theserver'sLocation.HostIDsletclientsaskserversfortheir
publickeysandverifytheauthenticityofthereply.Knowing
thepublickeyofaserverletsaclientcommunicatesecurely
withit.
SFS calculates HostID with SHA-1 1 [8], , a a collision-
resistanthashfunction:
HostID
SHA-1(“HostInfo”, Location,PublicKey,
“HostInfo”, Location,PublicKey)
SHA-1hasa20-byteoutput,muchshorterthanpublickeys.
Nonetheless, finding g any y two inputs of SHA-1 that pro-
ducethesameoutputisbelievedtobecomputationallyin-
tractable.
1
Thus,nocomputationallyboundedattackercan
producetwopublickeyswiththesameHostID;HostIDef-
fectivelyspecifies aunique,verifiable publickey.Giventhis
scheme,thepathnameofanSFSfile systementirelysuffices
tocommunicatesecurelywithitsserver.
Figure1showstheformatofanactualself-certifyingpath-
name. Allremotefiles s inSFSlieunderthedirectory
.
1
SFSactuallyduplicatestheinputtoSHA-1.Anycollisionofthedupli-
cateinputSHA-1isalsoacollisionofSHA-1.Thus,duplicatingSHA-1's
inputcertainlydoesnotharmsecurity;itcouldconceivablyhelpsecurityin
theeventthatsimpleSHA-1fallstocryptanalysis.
126
control SDK platform:C# PDF insert text Library: insert text into PDF content in C#.net
|. Home ›› XDoc.PDF ›› C# PDF: Insert Text to PDF. Powerful .NET PDF edit control allows modify existing scanned PDF text.
www.rasteredge.com
control SDK platform:Online Convert PDF to Text file. Best free online PDF txt
Online PDF to Text Converter. Download Free Trial. Convert a PDF to Text. Just upload your file by clicking on the blue button
www.rasteredge.com
Location
HostID(specifies publickey)
pathonremoteserver
Figure1:Aself-certifyingpathname
Withinthatdirectory, SFSmountsremotefile e systems s on
self-certifyingpathnamesoftheformLocation:HostID.SFS
encodesthe20-byteHostIDinbase32,using32digitsand
lower-caseletters. (Toavoidconfusion,theencodingomits
thecharacters“l” [lower-caseL],“1” ” [one],“0” ” and“o”.)
SFSclientsneednotknowaboutfile systemsbeforeusers
accessthem. Whenauserreferences s anon-existentself-
certifyingpathnamein
,aclientattemptstocontactthe
machinenamedbyLocation. Ifthatmachineexists, , runs
SFS,andcanprovepossessionofaprivatekeycorrespond-
ingtoHostID,thentheclienttransparentlycreatestherefer-
encedpathnameandmountstheremotefile systemthere.
Self-certifying pathnames combine with h automatic
mounting to guarantee everyone the right to create file
systems. GivenanInternetaddressordomainnametouse
asaLocation,anyonecangenerateapublickey,determine
the corresponding HostID, run the SFS server r software,
andimmediatelyreferencethatserverbyitsself-certifying
pathnameonanyclientintheworld.
KeymanagementpolicyinSFSresults from thenames
ofthefiles usersdecidetoaccess. . Oneusercanretrievea
self-certifyingpathnamewithhispassword.Anothercanget
thesamepathfromacertification authority. . Athirdmight
obtainthepathfromanuntrustedsource,butwantcautiously
toperusethefile systemanyway.SFSdoesn'tcarewhyusers
believethispathname,orevenwhatlevelofconfidence they
placeinthefiles. SFSjustdeliverscryptographicfile e system
securitytowhateverfile systemtheusersactuallyname.
2.3 The
directory
TheSFSclientbreaksseveralimportantpiecesoffunction-
alityoutofthefile systemintounprivilegeduseragentpro-
cesses. EveryuseronanSFSclientrunsanunprivileged
agentprogramofhischoice,whichcommunicateswiththe
file systemusingRPC. . Theagenthandlesauthenticationof
theusertoremoteservers,preventstheuserfromaccessing
revokedHostIDs,andcontrolstheuser'sviewofthe
directory. Userscanreplacetheiragentsatwill. . Toaccess
aserverrunninganewuserauthenticationprotocol,forin-
stance,ausercansimplyrunthenewagentonanoldclient
withnospecialprivileges.
TheSFSclientmapseveryfile systemoperationtoapar-
ticularagentbasedonthelocalcredentialsoftheprocess
makingtherequest.
2
Theclientmaintainsadifferent
directory foreachagent, and tracks s which h self-certifying
pathnameshavebeenreferencedinwhich
directory.
Indirectorylistingsof
,theclienthidespathnamesthat
haveneverbeenaccessedunderaparticularagent. Thus,
ana¨ıveuserwhosearchesforHostIDswithcommand-line
filename completioncannotbetrickedbyanotheruserinto
accessingthewrongHostID.
SFSagentshavetheabilitytocreatesymboliclinks in
visibleonlytotheirownprocesses. Theselinkscan
map human-readable names s to o self-certifying pathnames.
Whenauseraccessesafile notoftheformLocation:HostID
in
,theclientsoftwarenotifies theappropriateagentof
theevent.Theagentcanthencreateasymboliclinkon-the-
fly soastoredirecttheuser'saccess.
2.4 Serverkeymanagement
Mostuserswillneverwanttomanipulaterawself-certifying
pathnames. Thus,onemustaskifSFSactuallysolvesany
problemsfortheaverageuser,orifinpracticeitsimplyshifts
theproblemstoadifferentpartofthesystem.Weaddressthe
questionbydescribingnumeroususefulserverkeymanage-
menttechniquesbuiltonSFS.Ineverycase,ordinaryusers
neednotconcernthemselveswithrawHostIDs.
Manualkeydistribution.Manualkeydistributioniseas-
ilyaccomplishedinSFSusingsymboliclinks.Iftheadmin-
istratorsofasitewanttoinstallsomeserver'spublickeyon
thelocalharddiskofeveryclient, theycansimplycreate
asymboliclinktotheappropriateself-certifyingpathname.
Forexample,giventheserver
,clientma-
chinesmightallcontainthelink:
. Users
inthatenvironmentwouldsimplyrefertofiles as
....
The password file e might t list a a user's s home directory y as
.
Securelinks.AsymboliclinkononeSFSfile systemcan
pointtotheself-certifyingpathnameofanother,forminga
securelink. Inthepreviousexample,thepath
designatesthefile
on
theserver
. Thatfile, , inturn,mightbe
asymboliclinkpointingtotheself-certifyingpathnameof
2
Typicallyeachuserhasoneagent,andrequestsfromalloftheuser's
processesgetmappedtothatagent.Userscanrunmultipleagents,however.
Additionally,anssuutilityallowsausertomapoperationsperformedina
particularsuper-usershelltoherownagent.
127
control SDK platform:C# PDF Text Search Library: search text inside PDF file in C#.net
|. Home ›› XDoc.PDF ›› C# PDF: Search PDF Text. C#.NET PDF SDK - Search and Find PDF Text in C#.NET. C#.NET PDF DLLs for Finding Text in PDF Document.
www.rasteredge.com
control SDK platform:VB.NET Create PDF from Text to convert txt files to PDF in vb.net
C# File: Split PDF; C# Page: Insert PDF pages; C# Page: Delete PDF pages; C# Read: PDF Text Extract; VB.NET PDF - Create PDF from Text in C#.NET.
www.rasteredge.com
server
.Usersfollowingsecurelinks
neednotknowanythingaboutHostIDs.
Securebookmarks. Whenrunin an SFSfile e system,
theUnixpwdcommandreturnsthefullself-certifyingpath-
name ofthe current working directory. . From m this s path-
name, onecaneasily y extractthe Location andHostIDof
the serveroneis currentlyaccessing. . We e havea10-line
shellscriptcalledbookmarkthatcreatesalinkLocation
Location:HostIDin auser's
di-
rectory. Withshellsthatsupportthecdpathvariable,users
canaddthis
directorytotheircdpaths.By
simplytyping“
Location”, theycansubsequentlyreturn
securelytoanyfile systemtheyhavebookmarked.
Certification authorities. SFS certification n authorities
arenothingmorethanordinaryfile systemsservingsymbolic
links. Forexample, , ifVerisignactedasanSFScertifica-
tionauthority,clientadministratorswouldlikelycreatesym-
boliclinksfromtheirlocaldiskstoVerisign'sfile system:
. Thisfile e systemwouldinturn
containsymboliclinkstootherSFSfile systems,sothat,for
instance,
mightpointto
.
Unliketraditionalcertification authorities,SFScertifica-
tionauthoritiesgetqueriedinteractively.Thissimplifies cer-
tificate revocation,butalsoplaceshighintegrity,availability,
andperformanceneedsontheservers.Tomeettheseneeds,
weimplementedadialectoftheSFSprotocolthatallows
serverstoprovethecontentsofpublic,read-onlyfile systems
usingprecomputeddigitalsignatures.Thisdialectmakesthe
amountofcryptographiccomputationrequiredfrom read-
onlyserversproportionaltothefile system'ssizeandrate
ofchange,ratherthantothenumberofclientsconnecting.It
alsofreesread-onlyserversfromtheneedtokeepanyon-line
copiesoftheirprivatekeys,whichinturnallowsread-only
file systemstobereplicatedonuntrustedmachines.
Passwordauthentication. SFSletspeopleretrieveself-
certifying pathnames s securely y from remote servers s using
their passwords. . Unfortunately, , users s often n choose poor
passwords. Thus, , any y password-based authentication of
servers must t prevent attackers from m learning g information
theycanusetomountanoff-linepassword-guessingattack.
3
Twoprograms,sfskeyandauthserv,usetheSRPproto-
col[33]toletpeoplesecurelydownloadself-certifyingpath-
namesusingpasswords. SRPpermits s aclientandserver
sharingaweaksecrettonegotiateastrongsessionkeywith-
outexposingtheweaksecrettooff-lineguessingattacks.To
useSRP,anSFSuserfirst computesaone-wayfunctionof
3
Ofcourse,anattackercanalwaysmountanon-lineattackbyconnect-
ingtoaserverandattemptingto“authenticate” aself-certifyingpathname
withaguessedpassword.Wemakesuchon-lineattacksveryslow,however.
Moreover,anattackerwhoguesses1,000passwordswillgenerate1,000log
messagesontheserver. Thus,on-linepasswordguessingattemptscanbe
detectedandstopped.
his passwordandstores itwiththe authserv daemonrun-
ningonhisfile server. sfskeythenusesthepasswordasin-
puttoSRPtoestablishasecurechanneltotheauthserv. It
downloadsthefile server'sself-certifyingpathnameoverthis
channel,andhastheuser'sagentcreatealinktothepathin
the
directory.
Intheparticularuser-authenticationinfrastructurewebuilt
(seeSection2.5), eachuserhas hisownpublickeyswith
whichtoauthenticatehimself.Auserscanadditionallyreg-
isteranencryptedcopiesofhisprivatekeyswithauthserv
andretrievethatcopyalongwiththeserver'sself-certifying
pathname.Thepasswordthatencryptstheprivatekeyistyp-
icallyalsothepasswordusedinSRP—a safedesignbecause
theserverneverseesanypassword-equivalentdata.
Suppose auserfrom MITtravels toaresearchlabora-
toryandwishestoaccessfiles backatMIT. . Theuserruns
thecommand“
”. The
commandprompts him for r a single password. . He e types
it, and the e command completes successfully. . The e user's
agentthencreatesasymboliclink
. The e usertypes s “
”. Transparently,heisauthenticatedto
usingaprivatekeythatsfskeyjustdownloadedinen-
cryptedformoveranSRP-negotiatedsecurechannel. The
usernowhassecureaccesstohisfiles backatMIT. . The
processinvolvesnosystem administrators,nocertification
authorities,andnoneedforthisusertohavetothinkabout
anythinglikepublickeysorself-certifyingpathnames.
Forwardingpointers.SFSneverreliesonlong-liveden-
cryptionkeysforsecrecy,onlyforauthentication.Inparticu-
lar,anattackerwhocompromisesafile serverandobtainsits
privatekeycanbeginimpersonatingtheserver,buthecannot
decryptpreviouslyrecordednetworktransmissions. Thus,
oneneednotchangeafile server'spublickeypreemptively
forfearoffuturedisclosure.
Nevertheless, servers s may y need d to change their self-
certifyingpathnames (forinstance iftheychangedomain
names). Toeasethetransitionifthekeyfortheoldpath
stillexists,SFScanservetwocopiesofthesamefile system
underdifferentself-certifyingpathnames.Alternatively,one
canreplacetherootdirectoryoftheoldfile systemwitha
singlesymboliclinkorforwardingpointertothenewself-
certifyingpathname.
Ofcourse,ifaself-certifyingpathnamechangeisprecip-
itatedbydisclosureoftheoldprivatekey,anattackercan
serveroguedatatousersinsteadofthecorrectforwarding
pointer. AsdiscussedinSection2.6,adifferentmechanism
isneededtorevokethepathnamesofcompromisedprivate
keys.
Certification paths. A user can give his agent a
list of directories s containing symbolic c links, , for r exam-
ple
,
,
.
Whenthe useraccessesa non-self-certifyingpathname in
128
control SDK platform:C# Create PDF from Text to convert txt files to PDF in C#.net, ASP
ASP.NET: Create PDF. ASP.NET: Convert PDF. ASP.NET: Edit PDF Text. ASP.NET: Edit PDF Image. C#.NET PDF - Create PDF from Text in C# Using XDoc.PDF SDK for .NET.
www.rasteredge.com
control SDK platform:VB.NET PDF delete text library: delete, remove text from PDF file
from PDF. |. Home ›› XDoc.PDF ›› VB.NET PDF: Delete Text from PDF. Free VB.NET PDF SDK library for deleting PDF text in Visual Studio .NET application.
www.rasteredge.com
,theagentmapsthenamebylookingineachdirectory
ofthecertification pathinsequence. . Ifitfinds s asymbolic
linkofthesamenameasthefile accessed,itredirectsthe
usertothedestinationofthissymboliclinkbycreatinga
symboliclinkon-the-fly in
.
Existing public keyinfrastructures. On-the-fly sym-
boliclinkcreationin
canbeusedtoexploitexisting
public keyinfrastructures. . Forexample, , one e mightwant
touseSSL[10]certificates toauthenticateSFSservers,as
SSL's certification n modelsuits s some purposes well. . One
caninfactbuildanagentthatgeneratesself-certifyingpath-
namesfromSSLcertificates. Theagentmightinterceptev-
eryrequestforafile nameoftheform
.Itwouldcontact
'ssecurewebserver,down-
loadandchecktheserver'scertificate, andconstructfrom
thecertificate aself-certifyingpathnametowhichtoredirect
theuser.
2.5 Userauthentication
Whileself-certifyingpathnamessolve theproblem ofau-
thenticatingfile serverstousers,SFSmustalsoauthenticate
users toservers. . As s withserverauthentication, nosingle
meansofuserauthenticationbestsuitsallneeds.SFSthere-
foreseparatesuserauthenticationfromthefile system. . Ex-
ternalsoftwareauthenticatesusersthroughprotocolsofits
ownchoosing.
On the e client t side, , agents s handle user authentication.
Whena userfirst t accesses s an n SFSfile e system, , the e client
delaystheaccessandnotifies hisagentoftheevent. . The
agentcanthenauthenticatetheusertotheremoteserverbe-
forethefile accesscompletes.Ontheserverside,aseparate
program,theauthenticationserveror“authserv er,” ” performs
userauthentication. Thefile e serverandauthservercommu-
nicatewithRPC.
The agent and authserverpass messages toeach other
throughSFSusinga(possiblymulti-round)protocolopaque
tothefile systemsoftware. . Iftheauthserverrejectsanau-
thenticationrequest,theagentcantryagainusingdifferent
credentialsoradifferentprotocol. Thus,onecanaddnew
userauthenticationprotocolstoSFSwithoutmodifyingthe
actualfile system m software. . Moreover,asingleagentcan
supportseveralprotocolsbysimplytryingthemeachinsuc-
cessiontoanygivenserver.
Ifauserdoesnothaveanaccountonafile server, , the
agentwillaftersomenumberoffailedattemptsdeclineto
authenticatetheuser. Atthatpoint,theuserwillaccessthe
file systemwithanonymouspermissions.Dependingonthe
server'sconfiguration, thismaypermitaccesstocertainparts
ofthefile system.
2.5.1 sfsagentandauthserv
Thissectiondescribestheuserauthenticationsystemwede-
signedandbuiltforSFSusingtheframeworkjustdescribed.
Oursystemconsistsofanagentprogramcalledsfsagentand
anauthserver,authserv.
Oneofthegreatadvantagesofself-certifyingpathnames
istheeasewithwhichtheyletanyoneestablishanewfile
server. If f users s had d to think about authenticating them-
selvesseparatelytoeverynewfile server,however,thebur-
denofuserauthenticationwoulddiscouragethecreationnew
servers. Thus,ourgoalwastomakeuserauthenticationas
transparentaspossibletousersofSFS.
Allusershave oneormore publickeys in oursystem.
sfsagentrunswiththecorrespondingprivatekeys. Whena
clientasksanagenttoauthenticateitsuser,theagentdig-
itallysignsanauthenticationrequest. Therequestpasses
throughtheclienttoserver,whichhasauthservvalidateit.
authservmaintainsadatabasemappingpublickeystouser
credentials. Whenitreceivesavalidrequestfromthefile
server,authservreplieswithasetofUnixcredentials—a user
IDandlistofgroupIDs.
sfsagentcurrentlyjustkeepsauser'sprivatekeyinmem-
ory. However,weenvisageavarietyofmoresophisticated
agents. Theagentneednothavedirectknowledgeofany
privatekeys. Toprotectprivatekeysfromcompromise,for
instance,onecouldsplitthembetweenanagentandatrusted
authserverusingproactivesecurity.Anattackerwouldneed
tocompromiseboththeagentandauthservertostealasplit
secretkey. Alternatively,theagentmightsimplycommuni-
catethroughaserialportwithaPDAthatknowsthekey.
Proxy agents s could d forward d authentication requests to
otherSFSagents. Wehopetobuildaremoteloginutility
similartossh[34]thatactsasaproxySFSagent.Thatway,
userscanautomaticallyaccesstheirfiles whenlogginginto
aremotemachine. Authenticationrequestscontaintheself-
certifyingpathnameoftheserveraccessedbytheuser.They
alsocontainafield reservedforthepathofprocessesandma-
chinesthroughwhichtherequestarriveattheagent. Thus,
anSFSagentcankeepafullaudittrailofeveryprivatekey
operationitperforms.
2.5.2 Userkeymanagement
authservtranslatesauthenticationrequestsintocredentials.
Itdoessobyconsultingoneormoredatabasesmappingpub-
lickeystousers.BecauseSFSisasecurefile system,some
databasescanresideonremotefile serversandbeaccessed
throughSFSitself.Thus,forexample,aservercanimporta
centrally-maintainedlistofusersoverSFSwhilealsokeep-
ingafewguestaccountsinalocaldatabase.authservauto-
maticallykeepslocalcopiesofremotedatabases;itcancon-
tinuetofunctionnormallywhenittemporarilycannotreach
theserversforthosedatabases.
129
Eachofauthserv'spublickeydatabasesisconfigured as
eitherread-onlyorwritable. authservhandlesanumberof
managementtasksforusersinwritabledatabases. Itallows
them toconnectoverthenetworkwithsfskeyandchange
theirpublickeys,forexample.ItalsoletsthemregisterSRP
dataandencryptedcopiesoftheirprivatekeysforpassword
authentication,asdescribedinSection2.4.Toeasetheadop-
tionofSFS,authservcanoptionallyletuserswhoactually
logintoafile serverregisterinitialpublickeysbytyping
theirUnixpasswords.
Aservercanmountapasswordguessingattackagainst
auserifitknowsherSRPdataorencryptedprivatekey.
SFSmakes suchguessingattacksexpensive, however, by
transformingpasswordswiththeeksblowfish algorithm[19].
Eksblowfish takes s a cost parameterthatonecanincrease
ascomputersgetfaster. Thus,evenashardwareimproves,
guessingattacksshouldcontinuetotakealmostafullsec-
ondofCPUtimeperaccountandcandidatepasswordtried.
Ofcourse,theclient-sidesfskeyprogrammustinvestcorre-
spondinglymuchcomputationeachtimeitinvokesSRPor
decryptsauser'sprivatekey.
Veryfewserversactuallyneedaccesstoauser'sencrypted
privatekeyorSRPdata,however. authservmaintainstwo
versionsofeverywritabledatabase,apubliconeandapri-
vateone.Thepublicdatabasecontainspublickeysandcre-
dentials, butnoinformationwithwhichanattackercould
verifya guessedpassword. . A A servercansafelyexporta
publicdatabasetotheworldonanSFSfile system. . Other
authservscanmakeread-onlyuseofit. Thus,forinstance,
acentralservercaneasilymaintainthekeysofallusersin
adepartmentandexportitspublicdatabasetoseparately-
administeredfile serverswithouttrustingthem.
2.6 Revocation
Whenaserver's privatekeyis compromised, itsoldself-
certifyingpathnamemayleaduserstoafakeserverrunby
amaliciousattacker. SFStherefore e provides twomecha-
nisms to o preventusers s from accessing g bad self-certifying
pathnames:keyrevocationandHostIDblocking.Keyrevo-
cationhappensonlybypermissionofafile server'sowner.It
automaticallyappliestoasmanyusersaspossible. HostID
blocking,ontheotherhand,originatesfromasourceother
than a a file e system's s owner, , and can conceivably y happen
againsttheowner'swill. Individualusers'agentsmustde-
cidewhetherornottohonorblockedHostIDs.
Inkeepingwithitsgeneralphilosophy,SFSseparateskey
revocationfromkeydistribution. Thus,asinglerevocation
mechanismcanrevokeaHostIDthathasbeendistributednu-
merousdifferentways.SFSdefines amessageformatcalled
akeyrevocationcertificate, constructedasfollows:
“PathRevoke”
Location
NULL
Revocationcertificates areself-authenticating. . Theycon-
tainapublickey,
,andmustbesignedbythecorrespond-
ingprivatekey,
.“PathRevoke” isaconstant.Location
corresponds totheLocationintherevokedself-certifying
pathname. NULL L simply distinguishes revocation certifi-
catesfromsimilarlyformatedforwardingpointers. Arevo-
cationcertificate alwaysoverrulesaforwardingpointerfor
thesameHostID.
WhentheSFSclientsoftwaresees arevocationcertifi-
cate,itblocksfurtheraccessbyanyusertotheHostIDde-
terminedbythecertificate' sLocationand
.Clientsobtain
revocationcertificates intwoways: : fromserversandfrom
agents. WhenSFSfirst t connectstoaserver,itannounces
theLocationandHostIDofthefile systemitwishestoac-
cess. Theservercanrespondwitharevocationcertificate.
Thisisnotareliablemeansofdistributingrevocationcertifi-
cates,butitmayhelpgetthewordoutfastaboutarevoked
pathname. Alternatively,whenauserfirst t accessesaself-
certifyingpathname,theclientaskshisagenttocheckifthe
pathhasbeenrevoked. Atthatpointtheagentcanrespond
witharevocationcertificate.
Revocation certificates
might be used as follows.
Verisigndecidestomaintainadirectorycalled
. In n that directory reside files s named d by
HostID,whereeachfile containsarevocationcertificate for
thecorrespondingHostID.Wheneverauseraccessesanew
file system,hisagentcheckstherevocationdirectorytolook
forarevocationcertificate. Ifoneexists,theagentreturnsit
totheclientsoftware.
Because revocation certificates s are e self-authenticating,
certification authoritiesneednotchecktheidentityofpeople
submittingthem.Thus,evensomeonewithoutpermissionto
obtainordinarypublickeycertificates fromVerisigncould
stillsubmitrevocationcertificates.
Of course, , people e who o dislike e Verisign n are free e to
lookelsewhereforrevocationcertificates. Giventheself-
authenticatingnatureofrevocationcertificates, however,an
“all oftheabove” ” approachto o retrieving them m can n work
well—e venuserswhodistrustVerisignandwouldnotsub-
mitarevocationcertificate tothemcanstillcheckVerisign
forotherpeople'srevocations.
Sometimesanagentmaydecideapathnamehasgonebad
evenwithoutfinding asignedrevocationcertificate. Forex-
ample,evenifafile system'sownerhasnotrevokedthefile
system'skey,anagentmayfind thatacertification authority
insomeexternalpublickeyinfrastructurehasrevokedarel-
evantcertificate. Toaccommodatesuchsituations,theagent
canrequestHostIDblockingfromtheclient. Thisprevents
the agent's ownerfrom accessingtheself-certifyingpath-
nameinquestion,butdoesnotaffectanyotherusers.
Bothrevokedandblockedself-certifyingpathnamesbe-
come symboliclinks tothe non-existentfile
.
Thus, while accessingarevokedpathresults ina file e not
founderror,userswhoinvestigatefurthercaneasilynotice
thatthepathnamehasactuallybeenrevoked.
130
NFS 3
Server
NFS 3
Client
Read-Only Client
NFS Mounter
Agent
Agent
SFS Client
User Program
Client Master
Kernel
Read-Write Client
Kernel
Server Master
SFS Server
Server Master
Read-Write Server
Read-Only Server
SFS Server
Authserver
TCP Connection
TCP Connection
MACed, Encrypted
Figure 2:TheSFSsystemcomponents
3 Implementation
Figure 2 shows the programs that comprise the SFS system.
At the most basic level, SFS consists of clients and servers
joinedby TCP connections.
For portability, the SFS client software behaves like an
NFS version 3 [6] server. This lets it communicate with
the operating system through ordinary networking system
calls. When users accessesfiles underSFS,the kernel sends
NFS RPCsto the client software. The clientmanipulates the
RPCsand forwardsthem overa secure channelto the appro-
priate SFS server. The server modifies requests slightly and
tags them with appropriate credentials. Finally, the server
acts as an NFS client, passing the request to an NFS server
onthe same machine. The response followsthe same path in
reverse.
3.1 Cryptographic protocols
This sectiondescribes the protocolsbywhich SFS clientsset
up secure chennels to servers and users authenticate them-
selves to servers. We use quoted values to represent con-
stants.
,
,and
designate public keys (belonging
to a client, server, and user, respectively).
designates
the private key corresponding to public key
.Subscript
representsa message encrypted with key
,while subscript
signifies a message signed by
.
3.1.1 Key negotiation
WhentheSFSclientsoftwareseesaparticularself-certifying
pathname for the first time, it must establish a secure chan-
nel to the appropriate server. The client starts by connecting
(insecurely) to the machine named by theLocation in the
pathname. It requests the server'spublic key,
(Figure 3,
step 2), and checks that the key in fact matches the path-
name'sHostID. If the key matches the pathname, the client
knows it hasobtainedthe correct public key.
Once the clientknowsthe server'skey,itnegotiatesshared
session keysusing a protocolsimilarto Taos [32]. Toensure
forward secrecy, the client employsa short-lived public key,
(Figure 3, step 3), which it sends to the server over the
insecure network. The client then picks two random key-
halves,
and
;similarly,the serverpicksrandom key-
halves
and
. The two encrypt and exchange their
key-halvesas shownin Figure 3.
3
1
4
Client
SFS
Server
SFS
2
Figure 3:TheSFSkeynegotiationprotocol
The client and server simultaneously decrypt each other's
key halves, overlapping computation to minimize latency.
Finally,theycompute two sharedsessionkeys—one foreach
direction—as follows:
“KCS”
“KSC”
The client and server use these session keys to encrypt and
guarantee the integrity of all subsequent communication in
the session.
Thiskeynegotiationprotocolassurestheclientthat no one
else can know
and
without also possessing
.
Thus,it givesthe client asecure channeltothedesiredserver.
The server, in contrast, knowsnothing about the client. SFS
servers do not care which clients they talk to, only which
users are on those clients. In particular, the client's tempo-
rary key,
, is anonymous and has no bearing on access
control or user authentication. Clients discard and regener-
ate
at regular intervals (everyhour by default).
131
3.1.2 User authentication
The currentSFSagentandauthserverrely onpublic keysfor
user authentication. Every user has a public key and gives
his agent accessto that key. Every authserverhasa mapping
from public keysto credentials. When a user accessesa new
file system, the client software constructs an authentication
request for the agent to sign. The client passes the signed
requestto the server,which asks the authservertovalidate it.
SFS defines an AuthInfo structure to identify sessions
uniquely:
SessionID
“SessionInfo”
AuthInfo
“AuthInfo”
“FS”
Location
HostID
SessionID
The client software also keeps a counter for each session to
assigna unique sequence number to every authentication re-
quest.
When a user accesses a file system for the first time, the
client initiatesthe user-authentication processby sending an
AuthInfostructureandsequencenumbertotheuser'sagent
(see Figure 4). TheagentreturnsanAuthMsgbyhashing the
AuthInfostructuretoa20-byte AuthID,concatenatingthese-
quence number,signing the result, and appending the user's
public key:
AuthID
AuthInfo
SignedAuthReq
“SignedAuthReq”
AuthID
SeqNo
AuthMsg
SignedAuthReq
The client treats this authentication message as opaque
data. It addsanother copy of the sequence numberand sends
the data to the file server, which in turn forwards it to the
authserver. The authserver verifies the signature on the re-
quest and checks that the signed sequence number matches
the one chosen by the client. If the request isvalid,the auth-
server maps the agent's public key to a set of local creden-
tials. It returns the credentials to the server along with the
AuthIDandsequencenumberofthesignedmessage.
The server checks that theAuthID matches the session
and that the sequence number has not appeared before in
the same session.
4
Ifeverything succeeds, the server assigns
an authentication number to the credentials, and returns the
number to the client. The client tagsall subsequent file sys-
tem requests from the user with that authentication number.
If, on the other hand, authentication fails and the agent opts
not to try again, the client tags all file system requests from
the user with authentication number zero, reserved by SFS
for anonymousaccess.
Sequence numbersare not required forthe security ofuser
authentication. As the entire user authentication protocol
4
Theserveracceptsout-of-ordersequence numberswithina reasonable
window toaccommodate the possibilityofmultiple agentsonthe client re-
turningout oforder.
SFS Client
6
SFS Server
5
2
3
4
Agent
Authserver
1
AuthInfo,
SeqNo
AuthNo
AuthId,
SeqNo,
Credentials
SeqNo,
SeqNo,
AuthMsg
AuthMsg
AuthMsg
Figure 4:TheSFSuserauthenticationprotocol
happens over a secure channel, all authentication messages
received by the server must have been freshly generated by
the client. Sequence numbers prevent one agent from us-
ing the signed authentication request of anotheragent on the
same client. Thisfreesthefile systemsoftware fromthe need
to keep signed authentication requests secret—a prudent de-
sign choice given how many layers of software the requests
must travel through.
3.1.3 Cryptography
SFSmakesthree computational hardnessassumptions. Itas-
sumes the ARC4 [13] stream cipher (allegedly the same as
Rivest's unpublished RC4) is a pseudo-randomgenerator. It
assumes factoring is hard. Finally, it assumes that SHA-1
behaves like a random oracle [1].
SFS uses a pseudo randomgenerator in itsalgorithms and
protocols. We chose DSS's pseudo-random generator [9],
both because it is based on SHA-1 and because it cannot
be run backwards in the event that its state gets compro-
mised. Toseed thegenerator,SFSasynchronouslyreadsdata
from various external programs (e.g.,
,
), from
(if available),from a
file saved
by the previous execution, and from a nanosecond (when
possible) timer to capture the entropy of process schedul-
ing. Programs that require users to enter a passphrase add
both the keys typed and inter-keystroke timers as an addi-
tional source of randomness. All of the above sources are
run through a SHA-1-based hash function [1] to produce a
512-bit seed. Because the external programs run in paral-
lel and SFS reads from them asynchronously,SFS can effi-
132
ciently seed the generator from all sourceseverytime a pro-
gram starts execution.
SFS uses the Rabin public key cryptosystem [31] for
encryption and signing. The implementation is secure
against adaptive chosen-ciphertext [2] and adaptive chosen-
message [3] attacks. (Encryptionisactually plaintext-aware,
an even stronger property.) Rabin assumes only that factor-
ing is hard, making SFS's implementation no less secure in
the random oracle model than cryptosystems based on the
better-known RSA problem. Like low-exponent RSA, en-
cryptionandsignatureverification areparticularlyfast inRa-
bin because they do notrequire modular exponentiation.
SFS uses a SHA-1-based message authentication code
(MAC) to guarante the integrity of all file system traffic be-
tween clientsand read-write servers, and encrypts this trafic
with ARC4. Both the encryption and MAC have slightly
non-standard implementations. The ARC4 implementation
uses 20-byte keysby spinning the ARC4 key schedule once
for each 128 bits of key data. SFS keeps the ARC4 stream
running for the duration of a session. It re-keys the SHA-1-
based MAC for each message using 32 bytes of data pulled
from the ARC4 stream (and not used for the purposes of en-
cryption). The MACiscomputed on the length and plaintext
contents of each RPC message. The length, message, and
MAC all get encrypted.
SFS's stream cipher is identical to ARC4 after the
key schedule, and consequently has identical performance.
SFS'sMACisslowerthan alternativessuch asMD5HMAC.
Both are artifacts of the implementation and could be
swapped out for more popular algorithms without affecting
the main claims of the paper.
3.2 Modularity and extensibility
Figure 2 reveals that a number of programs comprise the
SFSsystem. Allprogramscommunicatewith Sun RPC [27].
Thus, the exact bytes exchanged between programs are
clearly and unambiguously described in the XDR protocol
description language [28]. We also use XDR todefine SFS's
cryptographic protocols. Any data that SFS hashes, signs,
or public-key encrypts is defined as an XDR data structure;
SFS computes the hash or public key function on the raw,
marshaled bytes. We use ourown RPC compiler,specialized
for C++,along with a new, asynchronousRPC library.
Breaking SFS into several programs helps the reliability,
security, and extensibility of the implementation. Our RPC
library can pretty-print RPC traffic for debugging,making it
easy to understand any problemsby tracingexactlyhowpro-
cesses interact. We use SFS for our day-to-day computing,
but have neverrun acrossa bugin the system that took more
than a day to track down.
Within a machine, the various SFS processes communi-
cate over UNIX-domain sockets. To authenticate processes
to each other, SFS reliesontwo special propertiesofUNIX-
domain sockets. First, one can control who connects to
them by setting access permissions on directories. Second,
one can pass file descriptors between processes over Unix-
domain sockets. SeveralSFSdaemonslistenforconnections
on sockets in a protected directory,
.A
100-line setgid program,suidconnect, connects to a socket
in this directory, identifies the current user to the listening
daemon, and passesthe connected file descriptor back to the
invoking process before exiting. The agent program con-
nects to the client master through this mechanism, and thus
needs no special privileges;users can replace it at will.
SFS's modularity facilitates the development of new file
system protocols. On the client side, a client master pro-
cess, sfscd, communicates with agents, handles revocation
and forwarding pointers, and acts as an “automounter” ” for
remote file systems. It never actually handles requests for
files on remote servers, however. Instead, it connects to a
server, verifies the public key, and passes the connected file
descriptor to a subordinate daemon selected by the type and
version of the server. On the server side, a server master,
sfssd,acceptsallincomingconnectionsfromclients. sfssd
passes each new connections to a subordinate server based
on the version of the client, the service it requests (currently
fileserv er or authserver), the self-certifying pathname it re-
quests, and a currently unused “e xtensions” ” string.
Aconfiguration file controls how client and server mas-
ters hand off connections. Thus, one can add new file sys-
tem protocols to SFS without changing any of the existing
software. Old and new versions of the same protocols can
run alongside each other,even when the corresponding sub-
sidiarydaemonshavenospecialsupport forbackwardscom-
patibility. As an example of SFS's protocol extensibility,we
implemented a protocol for public, read-only file systems
that proves the contents of file systems with digital signa-
tures. As described in Section 2.4, read-only servers work
well asSFS certification authorities. Implementingthe read-
only client and server required no changes to existing SFS
code; only configuration files had to be changed.
3.3 NFS details
The SFS implementationwasbuilt withportability asa goal.
Currently, the system runson OpenBSD, FreeBSD, Solaris,
Linux (withan NFS3kernelpatch), and DigitalUnix. Using
NFSboth tointerfacewith the operatingsystemonthe client
andto access files onthe servermakesportabilityto systems
with NFS 3 support relatively painless.
The SFS read-write protocol, while virtually identical to
NFS3,addsenhanced attribute and accesscachingto reduce
the number of NFS
and
RPCs sent over
the wire. We changed the NFS protocol in two ways to ex-
tend the lifetime of cache entries. First, every file attribute
structure returned by the server has a timeout field or lease.
Second, the server can call back to the client to invalidate
133
Documents you may be interested
Documents you may be interested