[Info-vax] VSI has released 9.2-1

[Arne Vajhøj]

On 6/20/2023 8:29 AM, Simon Clubley wrote:
> On 2023-06-19, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> On 6/19/2023 8:20 AM, Simon Clubley wrote:
>>>
>>> This is not about selling new systems. This is about being a part of
>>> work to make sure that existing sites don't get forced to move away
>>> from VMS because VMS no longer meets the industry standard security standards.
>>>
>>> You can have a nice piece of software running on VMS, but that's no
>>> good unless those VMS systems are secure by modern standards. VMS systems
>>> _WILL_ be dropped in many areas if they are regarded as no longer being
>>> secure by today's standards.
>>
>> Which security standards mandate direct support for entropy generation
>> in the OS?
> 
> You can also do it using external devices, which has been the only option
> for VMS until now, because the goal is to be able to meet a set of
> specified standards.
> 
>>>> The OpenSSL maintainers may be happy that they get better entropy
>>>> with less code.
>>>
>>> Replace "better entropy" with "now-acceptable entropy".
>>
>> Who is saying that current OpenSSL way is no longer acceptable?
> 
> OpenSSL on VMS, not OpenSSL in general.
> 
>>>                                                       The new entropy
>>> engine running within the kernel offers a brand-new capability for VMS
>>> that is considered to be standard elsewhere.
>>>
>>> To put this another way, the previous solutions for generating entropy
>>> within user mode that I am aware of were not suitable by today's standards.
>>
>> So you say.
>>
>> I would really like to get some sources.
>>
> 
> Fair enough. The current standards are the NIST SP 800-90 series of
> standards:
> 
> https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final

This standard specifies in great detail how to get from
entropy to secure random bytes.

It does not specify how the entropy should be generated
(it uses an abstract function get_entropy_input for it).

> https://csrc.nist.gov/publications/detail/sp/800-90b/final

This is the relevant one.

Quotes:

<quote>
Noise sources can be divided into two categories: Physical noise sources 
use dedicated hardware
to generate randomness; whereas Non-physical noise sources use system 
data (such as output of
Application Programming Interface (API) functions, Random Access Memory 
(RAM) data or
system time) or human input (e.g., mouse movements) to generate randomness.
</quote>

<quote>
The requirements for the noise source are as follows:
1. The operation of the noise source shall be documented; this 
documentation shall include a
description of how the noise source works, where the unpredictability 
comes from, and
rationale for why the noise source provides acceptable entropy output, 
and should reference
relevant, existing research and literature.
2. The behavior of the noise source shall be stationary (i.e., the 
probability distributions of the
noise source outputs do not change when shifted in time). Documentation 
shall include why it
is believed that the entropy rate does not change significantly during 
normal operation. This
can be in broad terms of where the unpredictability comes from and a 
rough description of the
behavior of the noise source (to show that it is reasonable to assume 
that the behavior is
stationary).
3. Documentation shall provide an explicit statement of the expected 
entropy provided by the
noise source outputs and provide a technical argument for why the noise 
source can support
that entropy rate. To support this, documentation may include a 
stochastic model of the noise
source outputs, and an entropy estimation based on this stochastic model 
may be included.
4. The noise source state shall be protected from adversarial knowledge 
or influence to the
greatest extent possible. The methods used for this shall be documented, 
including a
description of the (conceptual) security boundary’s role in protecting 
the noise source from
adversarial observation or influence.
5. Although the noise source is not required to produce unbiased and 
independent outputs, it shall
exhibit random behavior; i.e., the output shall not be definable by any 
known algorithmic rule.
Documentation shall indicate whether the noise source produces IID data 
or non-IID data. This
claim will be used in determining the test path followed during 
validation. If the submitter
makes an IID claim, documentation shall include rationale for the claim.
6. The noise source shall generate fixed-length bitstrings. A 
description of the output space of
the noise source shall be provided. Documentation shall specify the 
fixed symbol size (in bits)
and the list (or range) of all possible outputs from each noise source.
7. If additional noise source outputs to increase security are used, a 
document that describes the
additional noise sources shall be included.
</quote>

(it also contains a lot about how to test noise)

But it is all very generic and it does not require and special
HW or OS functionality. Traditional SYS$GETJPIW seems fine
(assuming all the documentation and test is done, but that is
also a requirement for HW or OS provided functionality).

> https://csrc.nist.gov/publications/detail/sp/800-90c/draft

(that is still a draft)

Just like 90A it does not cover the entropy but just refer to
an abstract GetEntropy function and 90B.

> In each case, the actual standard can be found in the top right of the
> page, under the "Publication:" section.
> 
> However, since they can be hard to follow in certain parts,

The relevant parts are actually quite easy to follow.

They just don't say that current VMS methodology is unacceptable.

>                                                              here is
> a much more readable introduction-level document from Red Hat discussing
> these issues from a Linux point of view:
> 
> https://www.redhat.com/en/blog/understanding-random-number-generators-and-their-limitations-linux
> 
> Look at the sources Linux is using for the entropy pool. You can't duplicate
> that in user mode without access to a kernel module (and underlying OS
> support) to help you.

It explains what Linux does.

And it is not possible to do what Linux does without something in the
OS kernel.

But this was about your claim that VMS could be dropped because
it was considered not secure by todays standards.

#                                                        VMS systems
# _WILL_ be dropped in many areas if they are regarded as no longer being
# secure by today's standards.

# To put this another way, the previous solutions for generating entropy
# within user mode that I am aware of were not suitable by today's 
standards.

I want to know where those standards are.

It is certainly not the NIST 800-90A/B/C quoted above.

It is certainly not that Redhat article.

Did you just make it up????

>>> Maybe I am seeing something here you are missing ?
>>
>> Possible. I miss a lot of things. So just post links
>> to the standards, best practice documents etc. specifying
>> the need for direct OS entropy.
>>
> 
> The NIST and earlier standards specify a series of requirements. You can't
> meet those requirements in a software-based solution without kernel support
> to get direct access to the entropy sources.

No.

That is not what the NIST standards say.

Arne