This information within this document is the property of the EnOcean Alliance and its use anddisclosure are restricted. Elements of the EnOcean Alliance specifications may also be subject tothirdparty intellectualpropertyrights, includingwithout limitation,patent,copyrightortrademarkrights (such a third party may or may not be a member of the EnOcean Alliance.) The EnOceanAllianceisnotresponsibleandshallnotbeheldresponsibleinanymannerforidentifyingorfailingtoidentifyanyorallsuchthirdpartyintellectualpropertyrights.Thisdocumentandtheinformationcontainedhereinareprovidedonan“asis”basisandtheEnOceanAlliancedisclaimsallwarrantiesexpress or implied, including but not limited to (1) anywarranty that the use of the informationhereinwillnotinfringeanyrightsofthirdparties(includinganyintellectualpropertyrights,patent,copyright or trademark rights, or (2) any implied warranties of merchantability, fitness for aparticularpurpose,titleornon-infringement.
InnoeventwilltheEnOceanAlliancebeliableforanylossofprofits,lossofbusiness,lossofuseofdata, interruption of business, or for any other direct, indirect, special or exemplary, incidental,punitive or consequential damages of any kind, in contract or in tort, in connection with thisdocument or the information contained herein, even if advised of the possibility of such loss ordamage.AllCompany,brandandproductnamesmaybetrademarks thatare thesolepropertyoftheirrespectiveowners.
The EnOcean Alliance Security of EnOcean networks Specification is available free of charge tocompanies, individuals and institutions for all non-commercial purposes (including educationalresearch,technicalevaluationanddevelopmentofnon-commercialtoolsordocumentation.)
Thisspecificationincludesintellectualproperty(„IPR“)oftheEnOceanAllianceandjointintellectualproperties(„jointIPR“)withcontributingmembercompanies.Nopartofthisspecificationmaybeused in development of a product or service for sale without being a participant or promotermemberoftheEnOceanAllianceand/orjointowneroftheappropriatejointIPR.EnOceanAlliancegrantsnorightstoanythirdpartyIP,patentsortrademarks.
These errata may not have been subjected to an Intellectual Property review, and as such, maycontainundeclaredNecessaryClaims.
ThisdocumentspecifiesthesecurityconceptforERP(1/2).ThisconceptwasspeciallydesignedfordevicespoweredbyenergyharvestersandisbasedontheERP.Theobjectiveofthedesignwastokeep the energy requirements andµC resources for the implementationof the security as lowaspossible.
Theimplementationaspects,whichdescribewhichsecurityshallbeused,arelistenedinthechapter8. Chapter 2 – 5 goes into technical details describing the scenario against which the EnOceansecurity protocol protects, technical background and possible security formats. Most of thepossibilities are not recommended and new design shall follow the SLF described in chapter 8.Chapter6describesEnOceanHighSecuritywhichuseschallengeandresponse.Chapter7explainstheusageofSecureChainedmessages,whichshallbeusedtosenddatalongerthanonetelegram.
n Thermostat vacation mode - A family leaves their home for several weeks. They set theirthermostat in vacationmode. Obscuring data from the thermostatwill prevent an intruder toknowtheoccupancystateofthehouse.
n Windowcontrol–AbuildinghasawindowinstalledwhoseopeningiscontrolledbytemperatureandCO2sensors.Applyingasecureradioprotocolthewindowreceivershouldignoremessagesthat have been already used. Thiswill prevent an intruder to gain unauthorized access to thebuildingbyrecordingpacketsandreplayingthem.
Automated meter reading – Polling a thermostat per radio enables the collection of meterinformationwithout the necessity of a person entering the house. By obscuring data from thethermostatitwillbepreventedthatanintruderobtainsprivateinformationfromthetransmitteddata. To prevent an intruder forging the heating consumption the system must resist reply-attacks.
Figure 1. The picture shows the possible interferences and attacks in the actual EO radiocommunication. Attacks other than the ones shown in this figure will not be considered in this
System Specification
SecurityofEnOceanNetworksv2.51
Page9/63
documentation and in the implementation of a secure radio protocol. Attacks not consideredinclude,for instance,thephysicalmanipulationofasenderorareceivermodule;continuouswavesending;power-supplysabotage.Fromthefourscenariosdepicted,thefirst(CollisionwiththesameIDbase) corresponds to anunintentional control of a receiver by another EOuser. The last threescenarios represent, however, an intentional attack. Unauthorized listening of information that isbeingtransmittediscalledeavesdropping.
Figure2.This scenario isnotaproperattack. It’s simplyan IDduplicationwithin the rangeof thebase ID (see what is EnOcean Base ID). The duplication happens because two different usersprogrammedtheirsendermoduleswithidenticalIDwithinthebaseIDrange.Whentheuserinroom1 sends a signal with Sender 1 he controls unluckily also Receiver 2, in room 2. A symmetricalsituationhappenswhentheSender2inroom2isoperated.
System Specification
SecurityofEnOceanNetworksv2.51
Page10/63
Figure3. InthisscenarioanattackerprogramstheIDbasetakingintentionalcontrolofthesystemreceiver.Todothis,theintrudersimplylistenstothesenderID.ItprogramsthenthissameBaseIDinhis sendermodule, and controls the system receiver.All this is possibleusing EO toolswithoutperformingreverseengineering.
In an ERP system most common communication pattern is unidirectional. However there areinstallationswherebi-directionalcommunicationisrequiredforinstancebetweentwoGateways,inSmartACKorinRemoteManagementconcept.ThusthesecurityconcepthastobedesignedinawaythatitcanbeappliedtoN:Mcommunicationpatterns.
Telegram
EnOceanRFmodule
Gateway
EnOceanRFmodule
Sensor
EnOceanRFmodule
Sensor
EnOceanRFmodule
Sensor
EnOceanRFmodule
Gateway
System Specification
SecurityofEnOceanNetworksv2.51
Page12/63
3 Securityforoperationmode
RORG Description
0x30SEC
Secure telegram. This message was not created from a non-secure counterpart. Amessage with this RORG was created by the secure application and the data mayinterpretedbyaTeach-In-Processoutsideofthisspecification(i.e.EEPorGP).
The security strategiesdiscussed in thenext chaptersareapplied tomessages.Messagesabstracttheconceptoftelegrams.Messagesdonotspecifyacertainbyteorder.TheyaretobeimaginedasCstructureswithallnecessarymemberstocontaintheinformationstoredinatelegram.Amessageisageneralisationofserialandradiotelegrams.
Amessage contains all fields that a telegrammayhave: theR-ORG,DATA, Sender ID, receiver ID,repeatercounteraswellasthesecurityspecificmemberslikeRLC,CMAC,SLFthatwillbeexplainedinthenextchapters.
EO secure messages follow a flexible schema made up of different freely combinable securitymechanisms.TheSecurity level formatsdescribed in chapter8 shouldbeused.Thedescriptionofothercombinationstillexistsforlegacyproductsandmaybestillused1.
The security mechanism may transform the DATA and R-ORG fields of the non-secure message.Other fields like themessage sender ID, receiver ID, repeater counter arenot affectedor altered.The RLC and CMAC should be added. Notmodified fields like sender ID, received ID or repeatercounterarenotdepictedthroughthechapterwhenamessageisrepresented.
The following figure depicts the relevant secure radiomessage structuremembers, togetherwithexamplesofapplicationscenarios,attacksthatcanbeblocked.
—————————
1 As the different SLF allow significant freedom, and not all combinations can be seen as optimal secure solutions, and
Table3.ThetableshowsthedifferentsecuremessagesstructuresfortypicalEnOceanapplications..A securemessage is identifiedby specificR-ORGcodes representedasR-ORGS.Obscuredwill beonly the DATA of the message and optionally the original R-ORG. Any combination of DATAencrypted/not encrypted, RLC present/not present, and CMAC present/not present is technicalpossible.Butonlytheonementionedinchapter8shouldbeused.
The structure of the secure telegram is negotiated between the devices within the teach-inprocedure.See4.
3.1 Messagestructure
Figure 7. Relevantmessagemembers In the following chapters,wheneverDATA iswritten, DATAincludesOPTIONALDATA.
3.1.1 R-ORG
ThemessageR-ORG identifies the typeofmessage that isbeing sentor received.ThemessageR-ORGis1-bytelong.Securemessagesareidentifiedbythecodes0x30,0x31,0x33or0x35,denotedgenerallyR-ORGSintheTable3.
IfthereceivermissesmoremessagesthenthedefinedRLCwindow,noadditionalmessageswillbedecrypted by the receiver. In this case the receiver needs to resynchronize the RLC. Differentapproaches can be used for this, one is that the sender retransmits a Teach-IN telegrams whichincludesthecurrentRLC.ThereceiverwillresynchronizeitselfafterreceivingthisTeach-IN.Anotherpossibilityise.g.ifthereceiverisalinepowereddeviceanddidsufferapowerlosstoincreasetheRLC window to a very large number one time – for one incoming telegram. In this case it isrecommendedtoensurethatnotaduplicatedRLChasbeenreceived.
3.1.4 CMAC
TheCMAC is thecipher-basedmessageauthenticationcode field–withMSB first. Itsmission is toguaranteethatthemessagehasnotbeentamperedwith.Thisconfirmsthatthesenderisthestatedone.
In the explanation message fields such as sender ID, receiver ID and other message fields, notmodifiedbythesecuritytransformations,willbenotindicated.Thereadermustsupposethatthesefieldsarepartofthemessage.
Figure8.Anunsecuremessage is transformed intoa securemessage that includes theoriginalR-ORGby1-transformingthemessageR-ORGcodeto0x31.2-TheunsecureR-ORGfieldcodeandtheunsecureDATAfieldsareconcatenatedandthenencrypted.3-Theresultoftheencryptionisstoredin themost significant bytes of the securemessage DATA field. 4- A rolling code, RLC, might becalculated (section5.5).5-Finally, it ispossible toaddaCMACcode (chapter5.6).OthermessagefieldslikesenderID,receiverIDorrepeatercounterarenotmodified.
In this case, a secure message with R-ORG 0x31 is transformed into a non-secure message. ThetransformationimpliesdecryptingtheencryptedR-ORGandDatainformationwhichistobefoundconcatenatedintheDATAfieldofthemessage.
Figure9.AsecuremessagewithR-ORG0x31containstheunsecuredR-ORGencryptedintheDATAfield.TheDATAfieldofthemessagemustbedecrypted,maybewiththehelpoftheRLC.ThefirstdecryptedbyterepresentsthemessageR-ORGoftheunsecuremessage.TherestofthedecryptedDATA field bytes represent the unsecuremessage DATA bytes. CMAC does not play a role in thedecryption.Thisfieldwillbecheckedforauthenticationofthetelegram.
Figure 10. An unsecuremessage is transformed into a securemessage that does not include theoriginal R-ORG by 1- rewriting the message R-ORG code to 0x30. 2- The unsecure DATA field isencrypted.3-The resultof theencryption is stored in the securemessageDATA field.4-A rollingcodemightbecalculated.5-Finally,itispossibletoaddaCMACcode.Thepurposeofnotincludingtheoriginalunsecuremessage in the securemessageDATA field is to saveenergyat transmissiontime.
In this case, a secure message with R-ORG 0x30 is transformed into a non-secure message. ThetransformationimpliesdecryptingtheDATAfieldinformation.
Figure 11. The secure message with R-ORG 0x30 does not include the non-secure R-ORGinformation inanyform. Intheconversionfromsecuretonon-securemessagethe latterbecomestheR-ORG=0x32.TheDATAfieldisdecrypted,maybeusingtheRLCfield.TheCMACdoesnotplayaroleinthedecryption.Itisonlyusedforauthenticationpurposes.
System Specification
SecurityofEnOceanNetworksv2.51
Page17/63
4 Securityforteach-inmode
Thischapterexplainstheexchangeofthesecurityinformationviatheradiointerface,whichmaybeomitted.EspeciallysendingtheAES-KeyincleartextshouldbeomittedandatleastaPSKshouldbeused.Theexchangeofthesecurityinformationmaybedonebyusingotherinterfaces,andthenbeadded into the device. This is not explained in details here. (E.g. ReCom, Serial interface or IPGateway)
Firstly, theDeviceBmustbeset in learningmodetoaccepttheteach-inmessages fromDeviceA.TheDeviceAsendsthesecurityteach-inmessage(aredescribedinchapter4.1)wheneveritsspecifictrigger is activated. After reception of the teach-in message the Device B stores the securityparametersofDeviceA:theseparametersincludetheDevice'sAprivatekey,KEY,currentRLC,RLC,RLCsizeandCMACsizeandwayofencryptinginformation.TheKEYandRLCcanbesentencryptedbythesenderusingthesocalledpre-sharedkey,PSK.Moredetailsunderchapters4.1.2.3and4.2.
If the process is bidirectional theDevice B, a gateway, for instance, answers backwith a securityteach-inmessage.Thisteach-inmessagecontainsasreceiver-IDtheIDoftheDeviceA.IftheDeviceBencryptsitsteach-inmessageitwillmakeuseofthesamePSKkeyoftheDeviceA.Inthesecondsecurityteach-indepictedinthepicturetheDeviceB informstheDeviceAof itsownKEYandRLC
BeforeDeviceAsendsthesecurityteach-inmessage,thereceiverisputintoteach-inmode–activelistening for teach-inmessages. The teach-inmethod is limited typically to 30 seconds. After thistime-outthemoduleleavesitsteach-inmode,andreturnstypicallytoitsoperationmode.Teach-inmessagesarenotaccepteduntilthenextactivationoftheteach-inmode.
o Teach-inmessageissentinplaintext(noencryptionintheinformationisperformed)..Thisshould not be used, as a third party could sniff the key and listens to all latercommunication.
o Partsof the teach-inmessageareencrypted.For theencryptionapre-sharedkey isused.Encrypted are the RLC and KEY. Message structure is listed below. Details about thisexecutioncanbefoundinchapter4.2
Toenableprofile interpretationaprofile-teach-inmessage(EEPorGP)hastobetransmittedafterthe secure teach-in. This profile teach-in is conducted already secured (encrypted) using thedecryptedkeythatthesecureteach-intransmitted.
4.1.1 R-ORGTS
Theonebytesecureteach-inR-ORGis0x35.
System Specification
SecurityofEnOceanNetworksv2.51
Page19/63
4.1.2 TEACH-ININFO
7 6 5 4 3 2 1 0
IDX CNT PSK TYPE INFO
0-NoPSK
1–PSK
0–NoPTM
1–PTM
InterpretationdependsonType.
See4.1.2.5
Table4.Teach-ininfobytefields
4.1.2.1 FieldIDX
A tech-in message can be divided in several telegrams. This field indicates the order of thosetelegrams. The first telegram receives the IDX = 0. In the case that the teach-in message is notdividedtheIDXshallbesetto0andthismessageistheonlyone..ChainingisexplainedinchapterA.1.2
Table 5. Security Level Format fields and its interpretation.When RLC_ALGO is 1 or 2 the secure teach-inmessagecontainstherollingcodewhosesizecorrespondstotheonedescribedbythatbitfield.—————————
2Thecodes6&7shouldbeusedinnewdesigns.3 In older specification the RLC_ALGO field was split into RLC_ALGO + RLC_TX. The same functionality of the old
Thepre-sharedkeyofthesendermodulemusthavebeencommunicatedtothereceiver(agateway)via serial interface in advance. The pre-shared key is typically written on a sticker on the sendermodule.Thepre-sharedkeyisnottransmittedthroughtheEnOceanairinterface.
This section describes the security algorithms for the ERP that are used to secure the telegramcontent.
5.1 VAES(variableAES)encryptionAmore secureway to encrypt data is using the 128-bit AES algorithm(1) in combinationwith therolling code. Themechanismdescribed here allowsDATA lengths from1 toN,whereN does nothave to benecessarily amultiple of 16. Thanks to the rolling code the generated encrypted codevaries, although the DATA input is constant. This feature improves the obscurity of the originalinformationandavoidsreplayattacks.Encryptionisdonein16byteschunks,similartothepreviousalgorithm.But the lengthof the resultingcipher text is the sameas the lengthofplain text.AftertransmittingeachmessagetheRLCisincreased.
Figure14.EncryptionoftelegramDATAusingvariableXORAES128forDATAequalor lessthan16bytes.TheAES128 isusedtoperformapseudorandomgenerator.TheplussymbolwithinacirclerepresentsabitwiseXORoperation.OneDATAchunkcanhaveamaximumof16bytes.ThelengthofDATA_ENC is equal to the lengthofDATA.VAES INITVector is a constant16-bytehexadecimalstringarray.TheRLCisXORedwiththeVAESINITVectorbeforeenteringtheAES128algorithm.TheVAES INIT VECTOR byte array first element, VEAS_INIT_VECTOR [0], is XORed with the RLCmostsignificantbyte.VEAS_INIT_VECTOR[1]isXORedwiththeRLC2ndmostsignificantbyteandsoon.
Figure15.EncryptionoftelegramDATAusingvariableXORAES128forDATAlongerthan16bytes.EncryptionisrepeatedbutinallfollowingcyclestheENCfieldfrompreviouscycleisXORedwiththeencryption input for theactualcycle.TheRollingCode is thesameforall cycles.Byusing theENCfieldinallfollowingcyclestheencryptioninputwillchangeandsotheENCfieldforDATA.Otherwisesamerulesapplyasinencryptionwithlessthan16bytes.
System Specification
SecurityofEnOceanNetworksv2.51
Page25/63
5.2 VAES(variableAES)decryption
Figure 16. Decryption algorithm of the received telegram. DATA_ENC is the received encryptedDATA.DATAislessthan16bytes.Note:TheAESalgorithmrequiredisthesameasintheencryptionalgorithm.TheRLCvalueinthereceivermustbethesameasinthetransmittermodule.Otherwisethe decryptedDATAwill not correspond to theDATA in the transmitter. TheDATA has the samelengthastheDATA_ENC.TheXORbitalignmentfollowstheideasdescribedin
ForthisalgorithmtoworkcorrectlythereceivermustcheckfirstthatitsinternalRLCiscorrect.Thiscanbedonebycomparing the internalRLCagainst the telegramRLCor, if there isnotransmittedRLC,bycomparingtheMAC(see5.6).
5.5 RollingCodeThe rolling code is a value stored in the sender and transmittermodule independently. The codechanges for every sent/received telegramaccording to apredefinedalgorithm. The rolling code isusedas toobtaindifferentCMACcodes (5.6) andVAESencryption values (5.1) although telegramDATAremainsconstant.
• If theRLC is send, rolloverof theRLC isnotallowedandwindowalgorithm isnotused.AreceivershallblockmessageswithalowerRLC.TheRLCshallonlyberesetwhenanewkeyisused.
Figure 18. Rolling Window of Acceptance for Counter Values (AVR411: Secure Rolling CodeAlgorithm).
The RLCwindow is amechanism that ensures that even if the transmitter and receiver lost theirsynchronization(transmitterwasoperatedoutsidetherangeofthereceiverortelegramswerelost),telegramswillbestillaccepted.Thedifferencebetweentherollingcodecountersinthesenderandreceivermustnotbebiggerthantherollingcodewindowsize.WhenthereceivermodulereceivesawrongRLC it tests thenextrollingcode. If this test failsagain, it tests thenextrollingcode.Thesetestscontinueuntil theRLCmatch,oranumberofRLCwindowsize testswereperformed. In thislastcasethereceiverreturnstoitsoriginalRLCandrejectsthetelegram.
Ifmessagespayloadisalignedby16bytes,thecase(a) isused.SubkeyK1isusedinthiscase.See5.6.2 for details about the subkey generation. The case (b) applies for messages that are notmultipleof16bytes.SubkeyK2isusedthen.
M_iare16-bytelongarrayofthemessagebyteswhoseCMACistobecalculated.M_1..M_n-1are16-byte long arrays. In case of (b) the last byte of the message is concatenated with the bitsequence10…0,toobtaina16byte-longarray.
Figure19.CMACgenerationalgorithmforamessage<=16bytes.TheR-ORG-S isthesecureradiomessageR-ORGcode.DATAisthesecuremessageDATAfield.WhenR-ORGS=0x31,DATAincludesthe encrypted non-secure R-ORG asmost significant byte.When R-ORG S= 0x30, DATA does notincludetheencryptednon-secureR-ORG.IfnoRLCisused(eitherinthemessageorinternally)thefield RLC is not included for the CMAC calculation. IMPORTANT: if the RLC is used but nottransmitted with the telegram then the RLC is included in the CMAC calculation. In this way theCMACchangesforeachtransmittedmessage.FromtheAES-generatedarraythebyteswithindex0,1,...,(CMAC_size-1)aretakenasCMAC.Thepaddingbytesareonlynecessaryforthecasethattheinputinformationis<16bytes.
A four byte CMAC corresponds to the string array bytes 0 (MSB), 1, 2, 3 (LSB) generated by theAES128 algorithm. A three byte CMAC corresponds to the string array bytes 0(MSB), 1, 2 (LSB)generatedbytheAES128algorithm.
n Enableprotectionagainstspecialman-in-middleattack(relayattack)
n Enablemoreflexiblehandlingfordevicescommunicatingbidirectionalwithencryption
Tohandlefirstrequirementisitsuitabletoapplythechallenge&responseprocesswithtimelimitedauthentication. This implies that both communication devices are bidirectional. All the followingdefinitionsarebasedonthatconstrain.
6.1 UseCasedefinitionHighsecurityspecificationisdevelopedforspecificdesignedapplicationswherethiskindofsecurityis required (e.g. doorlock, access control, safety applications). It is not the baseline for securityapplicationbutthehighestgradeandshouldbeappliedonly inapplicationswhere it isavalidusecase.
Bothdeviceshaveenoughcomputingcapabilitiesandenergytoperformsecurityrelevanttasks.Data telegrams are exchanged in both ways e.g. communication between smart plug andgateway.
Onedevice isdoingenergyharvestingandthesecond is line-powered.Dataflowisexecuted inbothdirections.Theautarkicdevice initializes the communicationand thenexpectsa responsefromtheline-powereddevicei.e.SmartAcknowledgeprocess.
One device is energy harvesting and the second is line-powered. Data flow is executed in onedirection – from the autarkic device to the line-powered. Bidirectionality is only required toexecutehighsecurityfeaturesnotforactualapplicationusecase.InthiscaseSmartAcknowledgewillbeusedtoo.
6.2 ProtectionagainstRelayAttacksRelay attacks are special man-in-the-middle attack scenarios. The intruder intercepts thecommunicationandblocksthetargetedreceiver.Thenhecanreplaythecommunicationtoa latermoment.WiththisscenariohewillevenbypasstheRLCCounterchecking,becausethereceiverhasnotupdatedhiscounterandsoacceptsthereplayedmessage.
Topreventthisattackscenariothemessagevaliditymustbetimelimitedand/orthereceivermustbe aware of transmission process ongoing. Time limitations are ensured by performing anauthenticationbychallengeandresponsewhichvalidonly limitedtime(500ms).DuringchallengeandresponseaNonceisusedaschallenge.
System Specification
SecurityofEnOceanNetworksv2.51
Page33/63
6.2.1 AuthenticationbasedonCMAC
Authenticationcanbe:
n Unilateral – only one of the communication partners is authenticated and his outgoingcommunicationisprotectedagainstreplayattacks–oneNonceisexchanged
n Mutual – both communication partners are authenticated and both communication ways areprotectedagainstreplayattacks–twoNonceareexchanged
For CMAC computing the EnOcean security concept uses the Payload of telegrams. The Nonce isusedduringCMACcomputingtooandsoensuresthattheNonceisconnectedwiththeexchangedmessageanditsdatacontent.Sobecomesthedatacontentalsovalidforlimitedtime.
EnOceanSecurity conceptuses theVAES fordataencryption.TheNoncecanbealsoused for theinitializationvectorfortheVAESprocess.ThiswayarandomelementisaddedtotheVAESprocess.ThisisrequiredifNonceisarandomnumberandnoRLCisused.
TheNoncecanbe:
n UsedduringCMACcounting
n UsedasinitializationvectorforVAEScounting
Nonce represents the challenge and has to be therefore exchanged between the communicationpartners via air interface. The Challenge and Response does not have to encrypt and can betransferredplaintext.TheCMACalgorithmrepresentsthesecuringelement.
n Bidirectionalcommunicationcanbeonlyexecutedaftermutualauthentication.Bothpartiescantriggertheauthentication
n Unidirectional communication is unilateral authenticated. The emitter of the data flow isauthenticatedandonlytheemittercantriggerthecommunication.Thechallengeisprovidedbytheconsumerofthedata
ForNoncewecanuse:
n Randomnumber32bit–here iscritical thatthegeneratorprocess isnotpredictable,doesnotrepeatsamesequencesandisequallyspreadonthedefinedrange
n Simpleincrementing,non-repeatingsequence32-bitnumber
6.2.2 Communicationscenarios
To protect against relay attacks we define three new security communication approaches. TheydifferinaspectoftheUseCasedefinitionmadeinchapter6.1:
In following definitions the DEVICE A is the sensor / autarkic device which initialize thecommunication. DEVICE B is the line-powered device which is receiving the communication. ThedefinitionsalsoapplyforUseCase1,thenDEVICEAisalsoanlinepowereddevice.
4. B receives Response with payload within timeout B. Validates it with help of both RNDs.Optionally–continueswithcommunicationandsendanotherpayloadmessage.
No further communicationwith same RND A and RND B can be executed, because no Sequencenumberispresentandreplayattackscouldbeexecuted.Totransmitbiggerdataquantitiesatonceusemessagechaining.
In this scenario the HASH is represented by one random sequence. No RLC is used. This is thesolutionwhichrequirestheleastamountofresourcesandensuresrelayattackprotection.
Failuresliketimeoutsarenotconsidered.Onlytheidealcaseisdescribed.OnanyfailureCMACnotvalidated or timeouts thewhole process is discarded and needs to start from beginning or othermeasurese.g.resynchronizemustbetaken.Thecommunicationwillbeexecutedinthesesteps.
Repeated transmissions of request for challenge or challenge messages between identicalcommunication partners shall restart the authentication process and cancel any previous ongoingvalidation.
sd Unilateral authentication with RND as NONCE
Device A Device B
{A is authenticated}
{max 500 ms}
Send Request for ChallangeRORG-MS DATA()
Generate RND B()
{max 500 ms}
Send Challange to ARORG-MS DATA(RND)
Calculate Response CMAC(PAYLOAD, RND B)
Send Response to Bwith Payload
RORG-SEC(PAYLOAD, CMAC)
Authenticate CMAC(PAYLOAD, RND B)
Process Payload from A()
System Specification
SecurityofEnOceanNetworksv2.51
Page39/63
6.3 HighSecurityinclusionintoexistingconcept
6.3.1 SecurityLevelFormatextension
Which High Security communication concept is used during data communications needs to becommunicatedat teach in time.For thispurposethedefinedSLF isextended.Followingextensionhasbeenmade:
The VAES process has to be extended to use RND during processing of VEAS INIT Vector. Thecommunicationscenariosinchapter6.2.2aredefinedtoRNDasinitialisationvector.
Amessage consists of a number of chained telegrams. Each telegram in a chain has a sequencenumberandan index.Thesequencenumber is thesameforeachmessage in thesamechainandindicates that the messages belong to the same chain. It is increased with every new CDM andcannotbeequalto0.
This chapter explainswhich device should usewhich sort of SLF explained 4.1.3. All these pointsshould be used when starting new devices. Only devices using these SLF shall get a “securedcertification” 01.03.2020. These devices can still be certified using lower levels, but a secureinteroperable communication cannot be guaranteed. Other possible combinations of the SLF aredeprecatedandshouldnolongerbeused,exceptthechallengeresponse(Highsecurity).
The RLC as plain information (not encrypted) should be transmitted explicitly inside the telegramwithoutcorruptingthedataencryption/authenticationor increasingtheriskofpotential intruderattacks.Ifthedevicedoesnothaveanyenergystorageandisextremelylimited(See8.2.3)thismaybeomitted.
This SLF shall only be used if a device does not contain any sort of energy storage and has anextremely tight energy budget. Therefore, it has to use the generated energy directly afterharvesting it. For example, a kinetic transmitter which immediately sends after activation securedata(Pushbuttontransmitter)
7 6 5 4 3 2 1 0
RLC_ALGO MAC_ALGO DATA_ENC
4–24bitRLC–nottransmitted
5-24bitRLC–24bitTransmitted
1-AES1283byte
3–VAES–AES128-RLC
System Specification
SecurityofEnOceanNetworksv2.51
Page47/63
8.3 SecureTeach-inPlain text AES transmission over the AIR is deprecated and shall not be used for newimplementations. The security teach-in shallbehandledby,entering the security container(SLF + Key (+optional RLC)) using a second pathway (e.g. Security Link tables with SecureReMan,SerialCommunicationorviaIPbackbone).
NOTE: Since the RLC is part of the CMAC computing, the RLC in every data telegram is signed.Therefore there is no additional risk in taking the RLC from the first radio telegram. It isrecommended that the first data telegrammust be triggered by the user at a defined moment,similartoteach-intelegrams.
Figure26.InthemostgeneralversionofthesecuremessagetheRLCandCMACfieldsarepresent.DATA can be encrypted. The fields R-ORG S, DATA, RLC and CMAC are integrated withoutmodification in theERP1 telegram. IfDATA isencrypted in themessage it isalsoencrypted in theERP1telegram.TheIDandSTATUSarespecifictothetelegram.
Teach-in message information divided in two ERP1 telegrams. The telegram withTEACH_IN_INFO_0 byte is sent first. This telegram contains the teach-in RLC, SLC and thefirstpartoftheKEYoftheteach-inmessage.ThesecondtelegramtransportsthesecondpartoftheKEY.
TEACH_IN_INFO_0
SLF RLC KEY RORG-TS ID STAT
KEY RORG-TS ID STAT TEACH_IN_INFO_1
System Specification
SecurityofEnOceanNetworksv2.51
Page52/63
The IDX bit field of TEACH_IN_INFO_0 = 0 indicates that this is the first telegram. The CNT=2indicatesthatthemessage isdivided in2telegrams.TEACH_IN_INFO_1 IDXfield=1saysthatthistelegramisthesecondone.Seechapter4.1.2tolearnmoreabouttheTEACH-ININFObitfields.
It is specified, that there is no direct timeout between the chained telegrams of the teach-in-message.Eachnewerreceivedtelegramoverwritesolderreceivedtelegrams.Attheendofthelearnmode,allpartlyreceivedmessageswillbedeleted.
Many EnOcean applications have a very limited amount of energy available. For this reason, ifneeded,ispossibletofragmenttheteach-inmessage(describedin4)inseveraltelegrams.
