View
6
Download
0
Category
Preview:
Citation preview
9/6/17
1
3.CryptographyReview
Prof.TudorDumitrașAssistantProfessor,ECEUniversityofMaryland,CollegePark
ENEE657
http://ter.ps/enee657
Today’sLecture
• Wherewe’vebeen– IntroducFontocomputersecurity
– MemorycorrupFonexploits
• Wherewe’regoingtoday– Cryptographyreview
• Wherewe’regoingnext– Homework1dueonFriday!
– OSprotecFonmechanisms
2
9/6/17
2
PilotProjectProposals• DueonMonday– PostproposalonthePiazzadiscussionboard– SomeideasavailableontheclassWebpage
• Proposalshouldbeconcise(2-3paragraphs)– Problemstatement– Approachconsideredfortacklingtheproblem
• Mustdescribeconcretetasks,notvaguedirecFons• Mustdemonstratethatyou’vethoughtaboutthefirststeps,andyouarenotsimplyparaphrasingtheprojectideasIgaveyou
• Comeseemeduringofficehours(AVW3425,Mon@2pm)– Ifyouarenotsurewhattodoforyourproject– Ifyouwanttoproposeatopicthatisnotonthelistfromthecoursewebpage– IfyouhaveanyquesFonsabouttheproject
3
RandomVariablesandRandomNumbers
• ArandomvariableXisaruleforassigninganumbertoeachexperimentaloutcome– Example:XisthenumberofheadsaYerncointosses
– We’reoYentryingtodeterminetheprobabilitydistribuRonofX• AssignprobabiliFesp1,p2,…pntovaluesx1,x2,…xnofX• UniformdistribuFon:p1=p2=…=pn
• Computersproducepseudo-randomnumbers– Sequenceofnumbersthatappearsrandom
– ThenumbersinthesequencefollowcertainmathemaFcalproperFes,e.g.uniformdistribuRon
– Sequenceofnumbers(orbit)starFngfromaseedvalue• Sameseedprovided =>samesequencegenerated
4Commoncryptomisuse#1:usingstaRcseeds
9/6/17
3
CryptoPrimiRves:Hashingvs.EncrypRon
• Givenplaintextx– Hashing: funcFonH(),suchthatH(x)isann-bitstring
– EncrypFon:funcFonsD()andE(),suchthatDkey’(Ekey(x))=x
• Hashingisone-way.Thereisno“uh-hashing”!– AciphertextcanbedecryptedwithadecrypFonkey…hasheshavenoequivalentofdecrypFon
• Hash(x)looks“random”butcanbecomparedforequalitywithHash(x’)– Hashthesameinputtwice→samehashvalue– Encryptthesameinputwithdifferentkeys→differentciphertexts
5Commoncryptomisuse#2:usingconstantencrypRonkeys
HashFuncRons:MainIdea
bitstringsofanylength n-bitstrings
. .
...
x’x’’
x
y’y
hashfuncFonH
• HashfuncFonHisalossycompressionfuncFon– Collision:H(x)=H(x’)forsomeinputsx≠x’
• H(x)shouldlookrandom– Everybit(almost)equallylikelytobe0or1
• AcryptographichashfuncRonmusthavecertainproperFes
“messagedigest”message
6
9/6/17
4
One-WayFuncRons
• IntuiFon:hashshouldbehardtoinvert– “Preimageresistance”
– Givenh()andy,itshouldbehardtofindanyxsuchthath(x)=y• yisann-bitstringrandomlychosenfromtheoutputspaceofthehashfuncFon,ie,y=h(x’)forsomex’
• Howhard?– Brute-force:tryeverypossiblex,seeifh(x)=y– SHA256(acommonhashfuncFon,brokenrecently)has256-bitoutput• SupposewehaveHWthatcancompute1B(≈230)hashesatonceanddo234trialspersecond
• Cantry289hashesperyear• Willtake2167yearstoinvertSHA256onarandomimage
7
BirthdayParadox
• Tpeople• SupposeeachbirthdayisarandomnumbertakenfromKdays(K=365)–howmanypossibiliFes?– KT-sampleswithreplacement
• HowmanypossibiliFesthatarealldifferent?– (K)T=K(K-1)…(K-T+1)-sampleswithoutreplacement
• ProbabilityofnorepeFFon?– (K)T/KT≈1-T(T-1)/2K
• ProbabilityofrepeFFon?– O(T2)
8
9/6/17
5
CollisionResistance
• Shouldbehardtofindx≠x’suchthath(x)=h(x’)• Birthdayparadox– LetTbethenumberofvaluesx,x’,x’’…weneedtolookatbeforefindingthefirstpairx≠x’s.t.h(x)=h(x’)
– Assuminghisrandom,whatistheprobabilitythatwefindarepeFFonaYerlookingatTvalues?
– Totalnumberofpairs?• n=numberofbitsintheoutputofhashfuncFon
– Conclusion:• Brute-forcecollisionsearchisO(2n/2),notO(2n)– ForSHA256,thismeansO(2128)vs.O(2256)
O(T2)
O(2n)
T≈O(2n/2)
9
One-Wayvs.CollisionResistance
• One-waynessdoesnotimplycollisionresistance– Supposeg()isone-way– Defineh(x)asg(x’)wherex’isxexceptthelastbit• hisone-way(cannotinverthwithoutinverFngg)• Collisionsforhareeasytofind:foranyx,h(x0)=h(x1)
• Collisionresistancedoesnotimplyone-wayness– Supposeg()iscollision-resistant– Defineh(x)tobe0xifxis(n-1)-bitlong,else1g(x)• Collisionsforharehardtofind:ifystartswith0,thentherearenocollisions;ifystartswith1,thenmustfindcollisionsing
• hisnotoneway:halfofally’s(thosewhosefirstbitis0)areeasytoinvert(how?),thusrandomyisinverFblewithp≥½
10
9/6/17
6
WeakCollisionResistance
• Givenarandomlychosenx,hardtofindx’≠xsuchthath(x)=h(x’)– “Secondpre-imageresistance”
– Avackermustfindcollisionforaspecificx…bycontrast,tobreakcollisionresistance,enoughtofindanycollision
– Brute-forceavackrequiresO(2n)Fme
• Weakcollisionresistancedoesnotimplycollisionresistance
11
ApplicaRon:PasswordHashing
• Insteadofuserpassword,storehash(password)
• Whenuserentersapassword,computeitshashandcomparewiththeentryinthepasswordfile– Systemdoesnotstoreactualpasswords!– Cannotgofromhashtopassword!
• Whatavacksdoesthisprevent?– Doeshashingprotectweak,easilyguessablepasswords?
12
9/6/17
7
ProtecRngPasswordsAgainstDicRonaryA`acks
• Peopletendtochosecommonwordsforpasswords– Avackercanpre-computeH(word)foreverywordinthedicFonary–thisonlyneedstobedoneonce!(moreonthislater)
– Defensesaimtoincreasetheavacker’sworkfactor
• SalFng– Choseasalt:doesnothavetobesecret,butmustberandom– ComputeH(salt||pwd)
• KeyderivaFonfuncFons– MulFpleiteraFonsofthehashfuncFon:H(H(H(…(salt||pwd))))
13
Commoncryptomisuse#3:hashingpasswordswithconstantsalts
Commoncryptomisuse#4:fewerthan1000iteraRonsofkeyderiv.funcRon
ApplicaRon:SoawareIntegrity
goodFile
SoYwaremanufacturerwantstoensurethattheexecutablefileisreceivedbyuserswithoutmodificaFon…SendsoutthefiletousersandpublishesitshashintheNYTimesThegoalisintegrity,notsecrecy
Idea:givengoodFileandhash(goodFile),veryhardtofindbadFilesuchthathash(goodFile)=hash(badFile)
BigFirm™ User
VIRUS
badFile
TheTimes
hash(goodFile)
14
9/6/17
8
WhichPropertyIsNeeded?
• Passwordsstoredashash(password)– One-wayness:hardtorecoverenFrepassword– Passwordsarenotrandomandthusguessable
• IntegrityofsoYwaredistribuFon– Weakcollisionresistance?– ButsoYwareimagesarenotrandom…maybeneedfullcollisionresistance
• AucFons:tobidB,sendH(B),laterrevealB– One-wayness…butdoesnotprotectBfromguessing– Collisionresistance:biddershouldnotbeabletofindtwobidsBandB’suchthatH(B)=H(B’)
15
CommonHashFuncRons
• MD5– Completelybrokenbynow
• RIPEMD-160– 160-bitvariantofMD-5
• SHA-1(SecureHashAlgorithm)– Widelyused(butrecentlybroken)
– USgovernment(NIST)standardasof1993-95• AlsothehashalgorithmforDigitalSignatureStandard(DSS)
• SHA256
16
9/6/17
9
IntegrityandAuthenRcaRon
IntegrityandauthenRcaRon:onlysomeonewhoknowsKEYcancomputecorrectMACforagivenmessage
Alice Bob
KEYKEY
message
MAC(messageauthenFcaFoncode)
message,MAC(KEY,message)
=?
RecomputesMACandverifieswhetheritisequaltotheMACavachedtothemessage
17
HMAC
• ConstructMACfromacryptographichashfuncFon– InventedbyBellare,Cane|,andKrawczyk(1996)
– UsedinSSL/TLS,mandatoryforIpsec
• WhynotencrypFon?– HashingisfasterthanencrypFon– LibrarycodeforhashfuncFonswidelyavailable– CaneasilyreplaceonehashfuncFonwithanother– ThereusedtobeUSexportrestricFonsonencrypFon
18
9/6/17
10
SymmetricCryptography
?---------------
Given:bothparFesalreadyknowthesamesecret
HowisthisachievedinpracFce?Goal:sendamessageconfidenFally
AnycommunicaFonsystemthataimstoguaranteeconfidenRalitymustsolvethisproblem
19
Kerckhoffs'sPrinciple
• AnencrypFonschemeshouldbesecureevenifenemyknowseverythingaboutitexceptthekey– Avackerknowsallalgorithms
– Avackerdoesnotknowrandomnumbers
• Donotrelyonsecrecyofthealgorithms(“securitybyobscurity”)
Fullname:Jean-Guillaume-Hubert-Victor-François-Alexandre-AugusteKerckhoffsvonNieuwenhof
20
Commoncryptomisuse#5:DIYcrypto
9/6/17
11
CommonSymmetricCryptoAlgorithms
• DES– 64-bitblocks(56-bitkey+8bitsforparity)– Outdated,butsFllinuse(especiallyas3DES)• 3DES:DES+inverseDES+DES(with2or3differentkeys)
• AES(Rijndael)– 128-bitblocks,keyscanbe128,192or256bits– USfederalstandardasof2001
• Theseareblockciphers– Operateonfixed-sizeblocks– Asopposedtostreamciphers(keyisaslongastheplaintext)
21
EncrypRngaLargeMessage
• So,we’vegotagoodblockcipher,butourplaintextislargerthan128-bitblocksize
• ElectronicCodeBook(ECB)mode– Splitplaintextintoblocks,encrypteachoneseparatelyusingtheblockcipher
• CipherBlockChaining(CBC)mode– Splitplaintextintoblocks,XOReachblockwiththeresultofencrypFngpreviousblocks
• Alsovariouscountermodes,feedbackmodes,etc.
22
9/6/17
12
ECBMode
• IdenFcalblocksofplaintextproduceidenFcalblocksofciphertext
• Nointegritychecks:canmixandmatchblocks
plaintext
ciphertext
blockcipher
blockcipher
blockcipher
blockcipher
blockcipher
key key key key key
23
InformaRonLeakageinECBMode[Wikipedia]
EncryptinECBmode
24
Commoncryptomisuse#6:usingECBmode
9/6/17
13
Sentwithciphertext(preferablyencrypted)
CBCMode:EncrypRon
• IdenFcalblocksofplaintextencrypteddifferently• LastcipherblockdependsonenFreplaintext
plaintext
ciphertext
blockcipher
blockcipher
blockcipher
blockcipher
⊕IniFalizaFon
vector(random) ⊕ ⊕ ⊕
key key key key
25Commoncryptomisuse#7:usingaconstantIVinCBCmode
CBCMode:DecrypRon
plaintext
ciphertext
decrypt decrypt decrypt decrypt
⊕IniFalizaFonvector ⊕ ⊕ ⊕
key key key key
26
• SFlldoesnotguaranteeintegrity
9/6/17
14
HowCanaCipherBeA`acked?
• AvackersknowsciphertextandencrypFonalgorithm– Whatelsedoestheavackerknow?DependsontheapplicaFoninwhichthecipherisused!
• Known-plaintextavack(stronger)– Knowssomeplaintext-ciphertextpairs
• Chosen-plaintextavack(evenstronger)– Canobtainciphertextforanyplaintextofhischoice
• Chosen-ciphertextavack(verystrong)– Candecryptanyciphertextexceptthetarget– SomeFmesveryrealisFc
27
InformalIntuiRon
• Securityagainstchosen-plaintextavack– CiphertextleaksnoinformaFonabouttheplaintext
– Eveniftheavackercorrectlyguessestheplaintext,hecannotverifyhisguess
– Everyciphertextisunique,encrypFngsamemessagetwiceproducescompletelydifferentciphertexts
• Securityagainstchosen-ciphertextavack– IntegrityprotecFon–itisnotpossibletochangetheplaintextbymodifyingtheciphertext
Minimumsecurityrequirementfora
modernencrypFonscheme
28
9/6/17
15
Encrypt+MAC
Goal:confidenFality+integrity+authenFcaFon
Alice Bob
K1,K2K1,K2
msg
MAC=HMAC(K2,msg)
encrypt(msg),MAC(msg)
=?
Encrypt(K1,msg)
Decrypt
VerifyMAC
encrypt(msg2),MAC(msg2)
Cantellifmessagesarethesame!
MACisdeterminisFc:messagesareequal⇒theirMACsareequal
SoluFon:Encrypt,thenMAC(orMAC,thenencrypt)
Breakschosen-plaintextsecurity
29
Public-KeyCryptography
?
Given:EverybodyknowsBob’spublickey -HowisthisachievedinpracFce?
OnlyBobknowsthecorrespondingprivatekey
privatekey
Goals:1.AlicewantstosendamessagethatonlyBobcanread 2.BobwantstosendamessagethatonlyBobcould
havewriven
publickey
publickey
AliceBob
30
9/6/17
16
ApplicaRonsofPublic-KeyCrypto
• EncrypFonforconfidenFality– Anyonecanencryptamessage• Withsymmetriccrypto,mustknowthesecretkeytoencrypt
– Onlysomeonewhoknowstheprivatekeycandecrypt– Secretkeysareonlystoredinoneplace
• DigitalsignaturesforauthenFcaFonandintegrity– Onlysomeonewhoknowstheprivatekeycansign
• Sessionkeyestablishment– Exchangemessagestocreateasecretsessionkey– Thenswitchtosymmetriccryptography(why?)
31
Public-KeyEncrypRon
• KeygeneraFon:computaFonallyeasytogenerateapair(publickeyPK,privatekeySK)
• EncrypFon:givenplaintextMandpublickeyPK,easytocomputeciphertextC=EPK(M)
• DecrypFon:givenciphertextC=EPK(M)andprivatekeySK,easytocomputeplaintextM– InfeasibletolearnanythingaboutMfromCwithoutSK
– TrapdoorfuncFon:Decrypt(SK,Encrypt(PK,M))=M
• Popularalgorithm:RSA32
9/6/17
17
DigitalSignatures:BasicIdea
?
Given:EverybodyknowsBob’spublickey OnlyBobknowsthecorrespondingprivatekey
privatekey
Goal:Bobsendsa“digitallysigned”message1. Tocomputeasignature,mustknowtheprivatekey2. Toverifyasignature,onlythepublickeyisneeded
publickey
publickey
Alice Bob
33
PopularDigitalSignatureSchemes
• RSAsignatures– SigninganddecrypFonarethesamemathemaFcaloperaFon
– VerificaFonandencrypFonarethesamemathemaFcaloperaFon
– Messagemustbehashedandpadded
• DSA(digitalsignaturealgorithm)signatures– U.S.governmentstandard(1991-94)– ModificaFonoftheElGamalsignaturescheme(1985)
– SecurityofDSArequireshardnessofdiscretelogproblem• Hardtoextractx(privatekey)fromgxmodp(publickey)
– Ifthesamemessageissignedtwice,signaturesaredifferent• Eachsignatureisbasedinpartonrandomsecretk• Secretkmustbedifferentforeachsignature!
34
9/6/17
18
Diffie-HellmanProtocol
• AliceandBobnevermetandsharenosecrets• Publicinfo:pandg– Hardtoextractx(privatekey)fromgxmodp(publickey)
Alice Bob
Picksecret,randomX Picksecret,randomY
gymodp
gxmodp
Computek=(gy)x=gxymodp
Computek=(gx)y=gxymodp
35
Commoncryptomisuse#8:exchangingkeysw/oauthenRcaRngtheendpoint
ProperResofDiffie-Hellman
• Assumingthediscretelogarithmproblemishard,Diffie-Hellmanisasecurekeyestablishmentprotocolagainstpassiveavackers– Eavesdroppercan’ttellthedifferencebetweentheestablishedkeyandarandomvalue
– Canusethenewkeyforsymmetriccryptography
• BasicDiffie-HellmanprotocoldoesnotprovideauthenFcaFon– IPseccombinesDiffie-Hellmanwithsignatures,anF-DoScookies,etc.
36
9/6/17
19
AdvantagesofPublic-KeyCrypto
• ConfidenFalitywithoutsharedsecrets– Veryusefulinopenenvironments
– Canusethisforkeyestablishment,avoidingthe“chicken-or-egg”problem• Withsymmetriccrypto,twoparFesmustshareasecretbeforetheycanexchangesecretmessages
• AuthenFcaFonwithoutsharedsecrets
• EncrypFonkeysarepublic,butmustbesurethatAlice’spublickeyisreallyherpublickey– Hardproblem,currentlysolvedusingpublic-keycerFficates(moreonthislater)
37
DisadvantagesofPublic-KeyCrypto
• CalculaFonsare2-3ordersofmagnitudeslower– ModularexponenFaFonisanexpensivecomputaFon
– Typicalusage:usepublic-keycryptographytoestablishasharedsecret,thenswitchtosymmetriccrypto• SSL,IPsec,mostothersystemsbasedonpubliccrypto
• Keysarelonger– 2048bits(RSA)ratherthan128bits(AES)
• Reliesonunprovennumber-theoreFcassumpFons– Factoring,RSAproblem,discretelogarithmproblem,decisionalDiffie-Hellmanproblem…
38
9/6/17
20
CommonCryptoMisuseExamples• UsingstaFcseedsforrandomnumbergenerators
• UsingconstantencrypFonkeys• Hashingpasswordswithconstantsalts
• Fewerthan1000iteraFonsofkeyderivaFonfuncFon
• DIYcrypto• UsingECBmode• UsingaconstantIVinCBCmode• Exchangingkeysw/oauthenFcaFngtheendpoint
• Manyothers(seehvp://cwe.mitre.org)39
the security benefits of symmetric encryption. For example,AdMob encrypts the phone’s location data using a constantkey and sends it over the network. Another example is anapplication that stores the user’s Google credentials on diskencrypted using a static key.
Rule 2: Do not use a non-random IV for CBC encryp-
tion. CryptoLint identified 1,932 applications that makeuse of constant initialization vectors in CBC mode encryp-tion.
Rule 4: Do not use constant salts for PBE. Cryp-
toLint identified 1,574 applications that use a static valuefor the salt used with the key derivation function in PBE.Using a static salt allows an attacker to pre-compute a dictio-nary based on the known salt, negating much of the benefit ofusing a salt at all. While the use of a static salt is better thanusing the password directly as encryption key, this choicenegates the advantages in multi-instance security [5].
Rule 5: Do not use fewer than 1,000 iterations for PBE.
The Java PBEKeySpec API implements password based en-cryption based on the PKCS#5 standard. The RFC forPKCS#5 recommends an iteration count of at least 1,000.CryptoLint identified 1,636 applications that use feweriterations. Applications that use a low iteration count anda static salt for password-based encryption are exposed totrivial dictionary-based o↵-line attacks, exactly the type of at-tacks that password-based encryption schemes were designedto protect against.
Applications violating multiple rules We next investi-gated the number of applications that violate multiple rules.These results are illustrated in Figure 1. Interestingly, itwas more common for applications to violate two rules thanonly violating a single rule. Of the applications violating asingle rule, rule 1 was violated the most (3,033 times). 511applications violated rule 2 and used constant IVs. For 246applications CryptoLint identified the use of a static sym-metric encryption key (violation of rule 3). 29 applicationswere flagged for using a low iteration count, and 13 appli-cations use static salt values for password-based encryptionschemes. CryptoLint identified 6 applications that onlyviolated rule 6 by seeding SecureRandom with a static seed.
The numbers of applications that violated exactly tworules are listed in Table 3. Additionally, our dataset con-tained exactly one application that violated all six rulesthat CryptoLint evaluates.
# apps rules violated1,905 Rule 1 & Rule 31,588 Rule 1 & Rule 61,247 Rule 4 & Rule 5866 Rule 2 & Rule 3109 Rule 1 & Rule 224 Rule 1 & Rule 511 Rule 3 & Rule 55 Rule 2 & Rule 52 Rule 1 & Rule 42 Rule 3 & Rule 4
Table 3: Applications violating two rules
1
10
100
1000
10000
0 1 2 3 4 5 6
Num
ber
of
dis
tinct
appli
cati
ons
Number of distinct violated rules
Figure 1: Number of applications violating 0, 1, 2,
. . . 6 rules.
6.2 Case Studies
Social gaming platform To estimate the impact of apply-ing cryptographic primitives incorrectly, we manually exam-ined a popular game that CryptoLint reported as misusingcrypto. This game is from a development studio that releaseda series of popular games, all containing a social platform forconnecting and interacting with friends. This social platformis used to track high-scores on a leader board. Accordingto Google play, the application we analyzed has between50,000,000 and 100,000,000 installations. The applicationcommunicates with the back-end servers of the social compo-nents over http. However, data that is transmitted betweenthe server and the client is encrypted. This application gotflagged by CryptoLint for two reasons. First, it uses theDES blockcipher in ECB mode. The developers explicitlyspecified the ECB block cipher mode as the used transfor-mation string is DES/ECB). Furthermore, CryptoLint alsocomplains that the application uses a static key with thisencryption scheme. We evaluated the correctness of theseresults by interacting with the game and exercising the socialnetwork functionality while at the same time recording allnetwork tra�c sent by the application. With the key ma-terial retrieved by CryptoLint, it was trivially possible todecrypt the encrypted network tra�c.
Bookmark Manager We also investigated a bookmark man-ager application in more detail (install base between 1,000,000and 5,000,000). This application allows the user to synchro-nize bookmarks between di↵erent browsers installed on themobile device. Furthermore, it provides the functionality tosynchronize browser bookmarks with Google’s web services.To make use of this functionality, the user has to provide herGoogle credentials. The application stores these credentialsin a regular Java property file. While the Google user-name isstored in the clear, the password is encrypted. CryptoLint
flagged this application because it uses the DES blockcipherin ECB mode to store that information in the property file.Furthermore, the application also uses a constant key forthe encryption. Again we verified that decryption of thepassword is trivially possible. We agree that safe storage ofaccess credentials is challenging to get right. To this end, An-droid provides a KeyStore facility that is designed for exactly
CryptomisuseinAndroidapps[Egeleetal.,2013]
88%ofappsmadeatleast1mistake
HowAreCryptosystemsA`ackedinPracRce?• Don’tbotherwiththecrypto;targettheusersinstead– Socialengineering– Passwordguessing
• ExploitbugsormisuseofcryptoAPIsintheimplementaFon– SSL:gotofail,Heartbleed– DieboldvoFngmachines:3DESinCBCmodewithNULLIV
• ExploitmisconfiguraFonsorenvironmentalfactors– Insufficiententropy,sharedprimes
• DebianOpenSSLbug• Embeddeddeviceswithoutkeyboard,mouse,real-Fmeclock,etc.
• Avackthemath– Flameworm:chosen-prefixcollisionavackagainstMD5 40
9/6/17
21
AddiRonalReferences
• JonathanKatz’sCourseraclass:hvps://www.coursera.org/course/cryptography
• KPSchapters2–6
41
ReviewofLecture• Whatdidwelearn?– HashfuncFons:one-way,collisionresistant,weaklycollisionresistant– MessageauthenFcaFoncodes– SecurityproperFes:confidenFality,integrity,authenFcaFon– Symmetriccrypto– Publickeycrypto– CommonwaystomisusecryptoAPIs
• Sources– VitalyShmaFkov
• Deadlinereminder– Monday:postpilotprojectproposalonPiazza– Ifyouarenotsurewhattodo,orifyouwanttoproposeatopicthatisnotonthelistfrom
thecoursewebpage,comeseemeduringofficehoursaYerclass
• What’snext?– OSprotecFonmechanisms 42
Recommended