Преминава се през последователността от задачи, започвайки с криптографски инвентар и хибриден обмен на ключове за TLS интерфейсите, а след това и IPsec връзките. Посочват се и отговорите на доставчиците, които трябва да будят съмнение, и се обяснява защо пропуснат интерфейс е вероятната точка на провал.

Не съм сигурен, че всяка задача може да се ограничи до отделни седмици, затова ще ги разчленя по точки. Първата задача е създаването на изчерпателен инвентар на цялата употреба на криптография с публичен ключ. Това включва идентифициране на 5G SBA интерфейси, IKE за IPsec-защитени връзки, DNSsec, криптирани API и т.н. Съставянето на пълен списък ще спести време и усилия по-късно. Втората стъпка е мигрирането на всичко, което използва TLS (включително SBA интерфейси, SEPP, уеб портали и OSS/BSS API), към хибриден обмен на ключове; това е най-достъпната налична технология.

Както вече споменах, най-лесно постижимата цел е обменът на TLS ключове. Внедряването на хибриден ML-KEM (X25519 ECC с ML-KEM, и ако е възможно с криптографско-гъвкаво архивиране към HQC) на всички TLS-защитени SBA и интерфейси от нивото на управление е най-лесната и най-въздействаща PQC мярка за всеки оператор.

Освен „все още не поддържаме PQC“, най-лошият отговор, който доставчик може да даде, е „чакаме стандартите да се стабилизират“. Въпреки че е вярно, че не всички RFC все още са финализирани, PQC се стандартизира по-бързо от всяка друга голяма иновация в историята на телекомуникациите. И тук криптографската гъвкавост е ключът към осигуряването на бъдещето, а не забавянето. Следващите най-лоши отговори са „но криптографски релевантните квантови компютри все още не са тук“ и „нашето криптиране се основава на симетрично криптиране и следователно е квантово защитено“, като и двата отговора показват или липса на разбиране, или умишлена измама.

Това се връща към въпрос, който подчертахме в предишен отговор – подготовката на пълен криптографски инвентар. Операторът може да обнови повечето от своите механизми за сигурност, но да пропусне интерфейс, като например машина с достъп през SSH, стар RADIUS интерфейс, балансьор на натоварването (load balancer) или NAT, инструмент за оркестрация, който никой не е докосвал от години и т.н. След това операторът получава фалшиво усещане за PQC сигурност, но разбира се PQC готовността е толкова сигурна, колкото е най-слабото звено.

Но има и друг проблем. Някои от по-новите механизми могат да нарушат предположенията за наследствено (legacy) оборудване. Това се случи, когато Kyber беше въведен за първи път – неговият многопакетен TLS client hello наруши предположенията на различни междинни устройства (middleboxes) и трябваше да бъде върнат назад.