Hacker News Reader

Comment by xnorswap | Hacker News Reader

> These values are actually the first AES 128bit CBC example key/iv listed in the NIST document SP800-38A.

I'd love to have a better insight into how exactly this happens. Not that it sounds like it would have been much of an issue even if properly generated keys and IVs were used.

View on HN

At the end of the day, lack of competent security leadership at Hyundai. In my work with other auto OEM's, there is some kind of security officer assigned to a vehicle model or platform that specifies requirements and that requires formal attestations for things like private key material, SSL cipher suites, process isolation and so forth.

At the other OEM's I have worked with, private key material lives on an HSM controlled by the OEM and all signing/encryption is done by the OEM for production builds.

If they are using example keys from NIST and private keys from published tutorials, then I would not be surprised if they are also using defaults for TLS - for example: allowing TLS 1.0, allowing TLS 1.1, allowing weak cipher suites, etc.

My bet is either subcontracting the development to a lowest-bidder with no understanding of the concepts behind the code they're writing, or malicious compliance by an engineer that sees no reason to prevent people from installing custom firmware on their own car but still needed something that "looked" secure to get approved by management.

Reply on news.ycombinator.com