IKEv1 супраць IKEv2: аўтэнтыфікацыя з агульным ключом і ў чым розніца

Два шлюзы, наладжаныя з адным і тым жа папярэдне агульным ключом, завяршаюць рукапацісканне, і перахоп пакетаў не паказвае, каб сакрэт перасякаў сетку. Гэта тая частка, якую людзі запамінаюць. Цікавая частка — што насамрэч вылічвае кожная версія, каб даказаць, што сакрэт вядомы, бо IKEv1 і IKEv2 будуюць гэты доказ з розных уваходных даных і паказваюць розную інфармацыю падчас гэтага. Чытайце два трасы побач, і розніца перастае быць касметычнай.

Што павінен забяспечыць доказ

Дыфі-Хэлмана дае абодвум бакам агульнае значэнне, публічныя паловы якога можа вылічыць любы назіральнік. Само па сабе гэта нічога не даказвае пра асобу: зламыснік, які завяршае абмен ключамі, мае тое ж агульнае значэнне, што і ваш шлюз. Этап аўтэнтыфікацыі існуе, каб звязаць гэты абмен з сакрэтам, які маюць толькі прызначаныя бакі, а таксама з асобамі і параметрамі, пра якія яны дамовіліся.

Менавіта гэтая сувязь тлумачыць, чаму хэш ахоплівае больш за ключ. Калі б ён ахопліваў толькі сакрэт, зламыснік мог бы перайграць яго ў іншы абмен з іншымі асобамі ці прапановамі.

IKEv1, асноўны рэжым: вывесці SKEYID, потым даказаць яго

Асноўны рэжым праходзіць шэсць паведамленняў. Першая пара ўзгадняе асацыяцыю бяспекі, другая абменьваецца публічнымі значэннямі Дыфі-Хэлмана і выпадковымі лікамі, а трэцяя нясе асобы разам з хэшамі аўтэнтыфікацыі пад шыфраваннем, якое толькі што ўстаноўлена. RFC 2409 вызначае канструкцыю: пры аўтэнтыфікацыі папярэдне агульным ключом SKEYID выводзіцца з сакрэту і абодвух выпадковых лікаў, а далейшы ключавы матэрыял выводзіцца з SKEYID, агульнага значэння Дыфі-Хэлмана, кукі і канстант.

Хэш у пятым і шостым паведамленнях вылічваецца па значэнні Дыфі-Хэлмана, двух кукі, прапанове і асобе адпраўніка з ключом SKEYID. Атрымальнік пералічвае яго са сваім наладжаным сакрэтам. Нясупадзенне спыняе абмен, і ні ў які момант сакрэт не з'яўляецца карыснай нагрузкай.

Агрэсіўны рэжым сціскае тую ж працу ў тры паведамленні, а гэта значыць, што асобы і хэш аўтэнтыфікацыі ідуць перш, чым існуе шыфраваны канал. Гэта рэальнае ўздзеянне для сакрэту, які можна адгадаць, і яно аддзеленае ад пытання, ці быў сакрэт перададзены. IKEv1 прызнаны састарэлым у RFC 9395, таму стары трас — гэта дыягнастычнае практыкаванне, а не мэта разгортвання.

IKEv2: іншае вывядзенне і іншая карысная нагрузка AUTH

IKEv2 не выкарыстоўвае паўторна расклад ключоў IKEv1. Пачатковыя ключы IKE паходзяць з насення, пабудаванага з выпадковых лікаў і агульнага значэння Дыфі-Хэлмана, а даччыныя асацыяцыі бяспекі выводзяцца з яго. Папярэдне агульны ключ зусім не сілкуе насенне.

Затым аўтэнтыфікацыя з'яўляецца як карысная нагрузка AUTH. Для аўтэнтыфікацыі агульным ключом RFC 7296 вызначае дапоўненую форму сакрэту, якая атрымліваецца хэшаваннем сакрэту з фіксаваным радком Key Pad for IKEv2, а затым хэшаваннем падпісаных даных абмену і асобы з гэтым дапоўненым ключом. Правяральнік можа аднавіць тое ж значэнне; назіральнік не можа без сакрэту.

Звярніце ўвагу, што змянілася. У IKEv1 сакрэт уплятаецца ў расклад ключоў да таго, як існуе хэш аўтэнтыфікацыі; у IKEv2 расклад ключоў не залежыць ад сакрэту, а доказ — асобная карысная нагрузка, прывязаная да падпісаных актэтаў. Тая ж канцэптуальная гарантыя, іншая механіка, і таму назвы параметраў і перахопы не адпавядаюць узаемна адназначна.

Што назіральнік насамрэч даведваецца

Публічныя значэнні Дыфі-Хэлмана, прапановы, выпадковыя лікі і кукі бачныя ў абедзвюх версіях. Асобы бачныя ў агрэсіўны рэжым IKEv1 і абароненыя ў іншых выпадках. Сакрэт не бачны ніколі.

Апошні сказ мае мяжу, якую варта назваць. Слабкі, выбраны чалавекам сакрэт можна атакаваць здагадкамі: зламыснік вылічвае, якім было б значэнне аўтэнтыфікацыі для кандыдата ў сакрэты, і параўноўвае. агрэсіўны рэжым IKEv1 робіць гэта самым танным, бо доказы адкрытыя, а стандарты ўвогуле папярэджваюць пра сакрэты з нізкай энтрапіяй. Ніколі не перадаваць сакрэт — не тое ж, што зрабіць дрэнны сакрэт бяспечным.

Што рабіць з параўнаннем

Выкарыстоўвайце адзін унікальны сакрэт на пару бакоў, генеравайце яго з выпадковай крыніцы і мяняйце яго праз той жа шлях забеспячэння, які яго размеркаваў. Калі сакрэт захаваны ў шаблоне канфігурацыі, які адпраўляецца ў кожнае аддзяленне, кампраміс у адным месцы — гэта кампраміс усюды.

Аддавайце перавагу аўтэнтыфікацыі на аснове сертыфікатаў там, дзе аперацыйныя выдаткі прымальныя, бо яна здымае праблему адгадвання агульнага сакрэту і дае кожнаму боку асобную асобу. Там, дзе папярэдне агульны ключ застаецца, трымайце яго доўгім, абмяжуйце яго і стаўцеся да версіі IKE як да рашэння бяспекі, а не да дэталі сумяшчальнасці.