Um desenvolvedor diz que conseguiu executar seu próprio software no hardware de infoentretenimento do carro depois de descobrir que o fabricante do veículo havia protegido seu sistema usando chaves que não eram apenas conhecidas publicamente, mas que haviam sido retiradas da programação exemplos.
Daniel Feldman, engenheiro de software baseado em Minneapolis, Minnesota, queria modificar o sistema de infotainment (IVI) no veículo em seu Hyundai Ioniq SEL 2021.
Para fazer isso, ele teria que descobrir como se conectar ao dispositivo e contornar sua segurança.
Depois de tentar descobrir como personalizar atualizações de firmware para o sistema D-Audio2 do IVI, feito pela subsidiária da plataforma de mobilidade da montadora Hyundai Mobis, e tê-los aceitos pelo IVI, Feldman encontrou uma maneira inesperada – através do Google.
O IVI aceita atualizações de firmware na forma de arquivos ZIP protegidos por senha. Feldman baixou um ZIP de atualização do site da Hyundai e conseguiu contornar a simples proteção por senha no arquivo para acessar seu conteúdo, que incluía imagens de firmware criptografadas para várias partes do IVI.
Seu objetivo então era criar suas próprias imagens de firmware e criptografá-las de uma forma dentro de um ZIP que o carro aceitasse, instalasse e executasse, permitindo assim que ele assumisse o controle do hardware a partir de seu próprio código fornecido.
Por sorte, Feldman encontrou no site da Mobis um script de configuração do Linux que criava um arquivo ZIP adequado para realizar uma atualização do sistema.
Acontece que a chave de criptografia nesse script é a primeira chave de exemplo CBC AES de 128 bits listada em um documento NIST
O script incluía a senha ZIP necessária para os arquivos de atualização do sistema, juntamente com uma chave de criptografia AES simétrica Cipher-Block-Chaining (CBC) (uma única chave em vez de um par de chaves pública/privada assimétrica RSA) e o IV (initializ ation vector) para criptografar as imagens do firmware.
Esta informação também pode ser usada para descriptografar as imagens.
Isso significava que ele poderia usar a chave AES para descriptografar as imagens de firmware, modificá-las e, em seguida, usar o script para recriptografar as imagens usando a chave AES e empacotar tudo em um ZIP protegido por senha para o sistema de atualização IVI da Hyundai ingerir.
Mas não ia ser tão fácil: alguma parte dos dados fornecidos, pelo menos, precisaria ser assinado criptograficamente usando uma chave privada RSA, e Feldman não tinha isto. O atualizador usaria a chave pública RSA correspondente da chave privada para verificar se os dados foram assinados usando a chave privada secreta correta.
Ele precisava encontrar a chave privada RSA para obter mais informações .
“O script sugeria que a assinatura RSA estava sendo usada, mas infelizmente a chave usada para isso não estava no código-fonte”, explicou Feldman em um post de blog em maio que foi trazido à nossa atenção por um leitor esta semana.
“Acontece que o A chave de criptografia nesse script é a primeira chave de exemplo CBC AES de 128 bits listada no documento NIST SP800-38A [PDF]”, acrescentou. consenso na comunidade de criptografia parece ser que o CBC é difícil de usar corretamente e outras abordagens são recomendadas. A Microsoft alertou no ano passado que o uso do AES CBC com preenchimento pode não ser seguro.
“A Microsoft acredita que não é mais seguro descriptografar dados criptografados com o modo Cipher-Block-Chaining (CBC) de criptografia simétrica quando o preenchimento verificável foi aplicado sem primeiro garantir a integridade do texto cifrado, exceto em circunstâncias muito específicas”, o “Este julgamento é baseado em pesquisas criptográficas atualmente conhecidas.”
Hyundai revela o robotaxi que construiu para o Lyft, e uma versão para seu próprio metaverso
