[Info-vax] Encryption, Security (was: Re: What to do with my VAX.....)

[Stephen Hoffman]

On 2020-11-20 13:37:22 +0000, Simon Clubley said:

> What people like you and Phillip need to understand is that 
> vulnerabilities exist everywhere and the less popular the OS, the more 
> likely they are to be silently exploited until a security researcher 
> finally invests the time to probe the OS.

Security through obscurity. The obscurity of the whole platform, in 
this case. And I too expect that detailed investigations will find 
additional exploits, though the still-prevalent usage of unencrypted 
storage protocols and of DECnet and telnet and ftp can all make that 
extra investment unnecessary for many targets.

> VMS has many good features but it doesn't mean that you can ignore some 
> uncomfortable truths about security on VMS and claim there isn't a 
> problem on VMS simply because no-one has invested the time to find 
> those vulnerabilities yet.

Or somebody has found exploits, and has been quietly sitting on those 
exploits. That DEF CON SMG exploit a while back sure looked like 
somebody leaked an exploit from a cache of vulnerabilities somewhere.

Exploit usage and exploit value differs for rare systems, and for those 
systems that are ubiquitous. An OpenVMS botnet makes little sense, as 
there are so few around. There are presently just shy of 1300 OpenVMS 
systems connected and accessible via the internet, with others not 
directly accessible and maybe a few more accessible but sufficiently 
masking their own identity.  For a more ubiquitous system, use as a 
botnet or other mass exploitation becomes more interesting. Usage which 
then exposes the exploits.

General:

AES symmetric encryption brute force is beyond current known 
capabilities. Brute-force timescales where we could more quickly visit 
other stars with our current tech. This absent either side channel 
access to the software using the keys (faster, though 
processor-integrated AES support reduces the vulnerability to side 
channel access), or an error in a specific encryption implementation, 
or with a whole lot of known plaintext (still beyond slow). This being 
security by design, rather than obscurity. And if somebody does have a 
trapdoor in AES, they're not going to want that known.

TLS asymmetric encryption design errors and attacks, and TLS 
implementation errors, have been more prevalent, with TLS itself 
receiving updates. TLSv1.3 is current, earlier protocol implementations 
are known to have weaknesses. I would not recommend using anything 
prior to TLSv1.2. As vulnerabilities and exploits are identified, 
remediations are implemented.

OpenVMS has some support for AES and for TLS, but does not have a 
cryptographic framework that can isolate apps from and abstract the 
lower-level changes and updates, for those apps that do use AES or TLS. 
I'm here ignoring the long-abandoned CDSA, and referring to an 
abstraction above the current ENCRYPT and TLS APIs. And among other 
gaps, OpenVMS lacks a password store, a certificate store, integrated 
multi-factor authentication, cryptographic secure storage and 
encryption acceleration hardware, and full-device encryption support. 
Intel SGX secure enclave usage might be feasible once the OpenVMS x86 
port is available, but the whole SGX approach has been problematic for 
a while.

OpenVMS VAX security (tying back to the original question) is more 
problematic, as OpenVMS VAX predates the integration of AES support in 
the V8 range, and the TLS and SSH support for OpenVMS VAX is 
third-party where available. And the end of the HPE hobbyist licenses 
will split off those that want VAX from those that want a way to run 
OpenVMS on low-end hardware.



-- 
Pure Personal Opinion | HoffmanLabs LLC