Mieux sé­cu­ri­ser les ob­jets connec­tés

Electronique S - - Sommaire -

Face aux be­soins crois­sants de sé­cu­ri­té ren­con­trés par les ap­pa­reils IoT grand pu­blic et in­dus­triels et par leurs uti­li­sa­teurs, les mi­cro­con­trô­leurs de der­nière gé­né­ra­tion em­barquent des mé­ca­nismes sé­cu­ri­taires de plus en plus per­fec­tion­nés.

Les ap­pa­reils IoT (In­ter­net of Things / In­ter­net des ob­jets) qui échangent don­nées et com­mandes sur le ré­seau mon­dial sont ex­po­sés à une va­rié­té et une quan­ti­té de me­naces net­te­ment plus im­por­tantes que les ap­pa­reils plus an­ciens qui uti­li­saient une com­mu­ni­ca­tion M2M (Ma­chine-to-Ma­chine), gé­né­ra­le­ment sur un ré­seau pri­vé et cloi­son­né. Le mo­dèle de clas­si­fi­ca­tion STRIDE, dé­ve­lop­pé à l’ori­gine par Mi­cro­soft, liste les me­naces de sé­cu­ri­té po­ten­tielles aux­quelles un ap­pa­reil IoT ou son uti­li­sa­teur ont à faire face : l’usur­pa­tion (spoo­fing), la fal­si­fi­ca­tion (tam­pe­ring), la ré­pu­dia­tion (re­pu­dia­tion), la di­vul­ga­tion d’in­for­ma­tions (in­for­ma­tion dis­clo­sure), le re­fus de ser­vice (de­nial of ser­vice) et l’élé­va­tion du pri­vi­lège (ele­va­tion of pri­vi­lege). Les fonc­tions et les res­sources né­ces­saires à la pro­tec­tion d’un ob­jet IoT contre ces me­naces de sé­cu­ri­té sont au­jourd’hui dis­po­nibles dans des composants spé­cia­li­sés, comme par exemple: - un sys­tème-sur-une-puce com­bi­nant un mi­cro­con­trô­leur avec ca­pa­ci­tés cryp­to­gra­phiques in­té­grées, mé­moire et in­ter­faces sé­cu­ri­sées. - des mé­moires non vo­la­tiles in­té­grant un mo­teur cryp­to­gra­phique pour n’au­to­ri­ser l’ac­cès à la mé­moire qu’aux seuls ap­pa­reils au­to­ri­sés. Mais l’uti­li­sa­tion de tels composants dis­crets dans des ap­pa­reils IoT se tra­duit par une aug­men­ta­tion du nombre de cir­cuits intégrés, de la com­plexi­té et du coût de no­men­cla­ture en com­pa­rai­son avec les de­si­gns fai­sant ap­pel aux ca­pa­ci­tés de sé­cu­ri­té in­té­grées du pro­ces­seur hôte (ou par­fois d’un pro­ces­seur d’ap­pli­ca­tion). La ques­tion cru­ciale pour les concep­teurs

d’ob­jets IoT consiste alors à dé­ter­mi­ner si les ca­pa­ci­tés du pro­ces­seur hôte sont suf­fi­santes pour contrer les me­naces lis­tées dans le mo­dèle STRIDE.

Une pro­tec­tion par couches

Les ap­pa­reils IoT sont vul­né­rables par leur connexion au ré­seau. Un bra­ce­let connec­té sur­veillant par exemple le rythme car­diaque et le ni­veau d’oxy­gé­na­tion du sang d’un pa­tient peut en­voyer en conti­nu des don­nées per­son­nelles sen­sibles via une liai­son sans fil à une ap­pli­ca­tion mé­di­cale hé­ber­gée par un four­nis­seur de ser­vice cloud. Il est im­por­tant de consi­dé­rer la vul­né­ra­bi­li­té de ce type d’ob­jets – et par consé­quent la pro­tec­tion né­ces­saire – en termes de couches. Une couche cor­res­pond par exemple à la connexion au ré­seau personnel (PAN), ty­pi­que­ment une liai­son ra­dio Blue­tooth Low Ener­gy avec un smart­phone ou une ta­blette, au­quel est as­so­cié le bra­ce­let. Une ex­ten­sion de cette couche pour­rait être le lien Wi-Fi entre le smart­phone ou la ta­blette et un rou­teur ou une pas­se­relle ré­si­den­tiels. La deuxième couche pour­rait être la pla­te­forme cloud, comme Azure (Mi­cro­soft) ou AWS (Ama­zon), la troi­sième étant l’ap­pli­ca­tion elle- même, hé­ber­gée dans le cloud. D’autres couches pour­raient être dé­fi­nies, se­lon l’ar­chi­tec­ture. Bien en­ten­du, l’uti­li­sa­teur du bra­ce­let compte jouir d’une to­tale tran­quilli­té d’es­prit, sans in­quié­tude quant à des me­naces po­ten­tielles de sé­cu­ri­té. Se­lon le mo­dèle STRIDE, celles-ci se classent ain­si : - Usur­pa­tion – un autre ap­pa­reil se fait pas­ser pour le bra­ce­let de l’uti­li­sa­teur et gagne l’ac­cès aux don­nées de l’ap­pli­ca­tion dans le cloud. - Fal­si­fi­ca­tion – cor­rup­tion des me­sures car­diaques ou d’oxy­gé­na­tion four­nies par le bra­ce­let à l’ap­pli­ca­tion dans le cloud. - Di­vul­ga­tion d’in­for­ma­tion – un as­saillant fouine dans les don­nées per­son­nelles du pa­tient. - Dé­ni de ser­vice – im­pos­si­bi­li­té tem­po­raire d’uti­li­ser le ser­vice cloud. Si le pa­tient dé­pend de l’ap­pli­ca­tion cloud pour l’aler­ter lorsque des soins ou des mé­di­ca­ments ur­gents sont né­ces­saires, le dé­ni de ser­vice peut avoir des consé­quences sé­rieuses sur sa san­té. Le bra­ce­let est vul­né­rable à l’une ou l’autre de ces me­naces à chaque couche dé­crite plus haut, et il n’est pas re­com­man­dé d’uti­li­ser un seul mé­ca­nisme de sé­cu­ri­té pour cou­vrir l’en­semble du sys­tème connec­té. À titre d’exemple, comme on l’a fré­quem­ment rap­por­té, une unique vul­né­ra­bi­li­té dans la sé­cu­ri­té de Ya­hoo a per­mis à des in­trus d’uti­li­ser des co­okies fal­si­fiés afin de se faire pas­ser pour un uti­li­sa­teur va­lide (une at­taque par usur­pa­tion) puis ac­cé­der aux comptes de ces uti­li­sa­teurs sans mot de passe. Une telle at­taque par usur­pa­tion sur un four­nis­seur de ser­vice cloud peut ou­vrir le ca­nal de com­mu­ni­ca­tion du bra­ce­let vers le cloud. Il est par consé­quent es­sen­tiel que les autres couches – l’ap­pli­ca­tion hé­ber­gée dans le cloud ain­si que les liens Wi-Fi et BLE à In­ter­net – soient pro­té­gées par des mé­ca­nismes de sé­cu­ri­té in­dé­pen­dants. Par exemple la clé uti­li­sée pour en­cryp­ter les don­nées car­diaques trans­mises à l’ap­pli­ca­tion cloud de­vrait être dif­fé­rente de la clé uti­li­sée par le bra­ce­let pour au­then­ti­fier le ser­vice cloud.

Les be­soins de sé­cu­ri­té du coeur

À cha­cune des six ca­té­go­ries de me­nace STRIDE cor­res­pond un type de be­soin de sé­cu­ri­té ( voir fi­gure 1). La sé­cu­ri­té d’un ap­pa­reil IoT re­pose par ailleurs sur trois élé­ments: - les po­li­tiques de sé­cu­ri­té – elles dé­fi­nissent quelles condi­tions de sé­cu­ri­té sont

uti­li­sées pour per­mettre l’ac­cès au sys­tème, au ré­seau et/ou aux don­nées. - la cryp­to­gra­phie – les al­go­rithmes arith­mé­tiques mis en oeuvre se­lon les dif­fé­rents types de sé­cu­ri­té exi­gés. - la ré­sis­tance à l’ef­frac­tion – l’ap­ti­tude d’un sys­tème à uti­li­ser la cryp­to­gra­phie et à ap­pli­quer ses stra­té­gies de sé­cu­ri­té sans faire fui­ter des in­for­ma­tions sen­sibles, ni être en­dom­ma­gé. Pour un ap­pa­reil IoT et pour ses uti­li­sa­teurs, les stra­té­gies de sé­cu­ri­té sont ty­pi­que­ment les pre­miers choix à faire. Après cette étape, l’in­gé­nieur de concep­tion sys­tème doit vé­ri­fier si les choix de sé­cu­ri­té qui uti­lisent la cryp­to­gra­phie et la ré­sis­tance à l’ef­frac­tion peuvent être mis en oeuvre de ma­nière ef­fi­cace dans le mi­cro­con­trô­leur de l’ob­jet connec­té, ce qui amène les ques­tions sui­vantes: - mes clés de cryp­to­gra­phie peuvent-elles être sto­ckées de ma­nière sé­cu­ri­sée? - pos­sède-t-il des ac­cé­lé­ra­teurs hard­ware pour les al­go­rithmes de cryp­tage stan­dards tels que RSA, ECC, AES et SHA? - existe-t-il un gé­né­ra­teur de nombres aléa­toires vé­ri­tables (TRNG)? Est-il cer­ti­fié ? - est-il pos­sible de dé­tec­ter une ef­frac­tion phy­sique sur l’ap­pa­reil ? Jus­qu’à main­te­nant, la dis­po­ni­bi­li­té de ces fonc­tions a été li­mi­tée à des composants dis­crets spé­cia­li­sés. Mais la pro­li­fé­ra­tion de l’IoT gé­nère une de­mande nou­velle de mi­cro­con­trô­leurs in­té­grant ces fonc­tions et d’autres pour ré­pondre aux be­soins spé­ci­fiques de l’IoT. C’est par exemple ce que Cypress Se­mi­con­duc­tor adresse au­jourd’hui avec sa nou­velle fa­mille de mi­cro­con­trô­leurs PSoC 6, qui com­bine une consom­ma­tion ul­tra-basse, une puis­sance de trai­te­ment éle­vée et une sé­cu­ri­té mul­ti­ni­veaux pour ré­pondre aux me­naces ty­piques de l’IoT. Les mi­cro­con­trô­leurs PSoC 6 pos­sèdent une ar­chi­tec­ture à double coeur: - un coeur ARM Cor­tex-M4 haute per­for­mance ca­pable d’exé­cu­ter avec ra­pi­di­té des tâches de cal­cul in­ten­sif, et bas­cu­lant en mode veille basse consom­ma­tion après ce­la. - un coeur ARM Cor­tex-M0+ pou­vant réa­li­ser en conti­nu des fonc­tions simples comme la ges­tion d’un groupe de cap­teurs ou une connexion Blue­tooth Low-Ener­gy, à un ni­veau de consom­ma­tion ul­tra-faible. L’ar­chi­tec­ture PSoC 6 MCU tire pro­fit de la dis­po­ni­bi­li­té de deux coeurs pour four­nir une sé­cu­ri­sa­tion mé­moire au ni­veau hard­ware. Un mi­cro­con­trô­leur mo­no­coeur opère dans un es­pace mé­moire unique. Les don­nées de sé­cu­ri­té comme les clés sont sto­ckées dans cet es­pace avec le firm­ware stan­dard. Une fonc­tion temps réel de su­per­vi­sion (ty­pi­que­ment four­nie par un sys­tème d’ex­ploi­ta­tion temps réel) gère en­suite les adresses sé­cu­ri­sées pen­dant le fonc­tion­ne­ment opé­ra­tion­nel, de telle sorte que seuls les pro­grammes au­to­ri­sés y aient ac­cès. Dans un PSoC 6, le contrôle d’ac­cès peut être confi­gu­ré à un ni­veau ar­chi­tec­tu­ral avant que le mi­cro­con­trô­leur passe en mode opé­ra­tion­nel nor­mal. Par exemple, une por­tion de mé­moire par­ta­gée peut être confi­gu­rée pour n’être ac­ces­sible que par le coeur Cor­tex-M0+. De cette ma­nière, les mi­cro­con­trô­leurs PSoC 6 peuvent of­frir une mé­moire à sé­cu­ri­té hard­ware, qui ajoute un ni­veau de pro­tec­tion sup­plé­men­taire contre les ac­cès non au­to­ri­sés (voir Fi­gure 2). Les mi­cro­con­trô­leurs PSoC 6 dis­posent éga­le­ment d’un ac­cé­lé­ra­teur hard­ware de sé­cu­ri­té dé­dié sup­por­tant les al­go­rithmes de cryp­tage stan­dard cou­rants tels que AES, RSA, ECC et SHA, et d’un gé­né­ra­teur TRNG. Comme avec la mé­moire in­té­grée, l’ac­cès à ce bloc peut être contrô­lé au ni­veau de l’ar­chi­tec­ture. En­fin, la pla­te­forme PSoC 6 in­tègre des fonc­tions pour la dé­tec­tion d’ef­frac­tion au ni­veau du boî­tier de l’ap­pa­reil : des blocs ana­lo­giques pro­gram­mables peuvent être confi­gu­rés pour réa­li­ser une dé­tec­tion de ten­sion ou de cou­rant et de la sur­veillance d’hor­loge, tan­dis que la tech­no­lo­gie de dé­tec­tion ca­pa­ci­tive CapSense de Cypress per­met de dé­tec­ter des ten­ta­tives frau­du­leuses d’ef­frac­tion du boî­tier.

Une sé­cu­ri­té conçue spé­cia­le­ment pour l’IoT

Cette ca­pa­ci­té à of­frir un sto­ckage in­té­gré sé­cu­ri­sé par hard­ware, un ac­cé­lé­ra­teur cryp­to­gra­phique et des fonc­tions de dé­tec­tion d’in­tru­sion n’était pas dis­po­nible au­pa­ra­vant dans un mi­cro­con­trô­leur pour les ap­pli­ca­tions IoT clas­siques. Les nou­velles de­mandes gé­né­rées par l’IoT im­posent de nou­veaux mi­cro­con­trô­leurs spé­ci­fi­que­ment conçus pour ces ap­pli­ca­tions et in­té­grant les fonc­tions de sé­cu­ri­té, les ca­rac­té­ris­tiques de basse consom­ma­tion et les ca­pa­ci­tés de trai­te­ment né­ces­saires aux ap­pa­reils IoT.

JACK OGAWA (CYPRESS SE­MI­CON­DUC­TOR) Jack Ogawa est di­rec­teur du mar­ke­ting au sein de l’ac­ti­vi­té Mi­cro­con­trô­leurs de Cypress Se­mi­con­duc­tor. Il a pré­cé­dem­ment fait une par­tie de sa car­rière chez Al­te­ra puis chez NXP Se­mi­con­duc­tors.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.