[External] : Re: RFD: Services lockdown for security providers

[Martin Balao]

Hi Tony,

Thanks for having a look at our proposal.

The main motivation for this enhancement is related to cryptographic 
policy enforcement and, in particular, the following capabilities: 1) 
enforcing that cryptographic services are provided by chosen security 
providers only, and 2) allowing or disallowing selected algorithms or 
service types across all Java Security APIs.

None of this is entirely new. In regards to capability #1, users can 
install or uninstall security providers already, or rely on priorities 
and algorithms shadowing. However, we deem this insufficient for the 
purposes of policy enforcement, lacking in flexibility, and at risk of 
introducing dependencies on implementation details. Some more details 
are provided under the section "What is the current limitation?" of the 
8315487 ticket [1]. As for capability #2, there is partial support 
currently: algorithms can be blocked from TLS or certificate paths 
validation uses but not across all JCA APIs. Thus, we share some of the 
motivations that led to existing features but intend to have a more 
powerful, comprehensive and flexible solution. As documented in our 
proposal, both solutions were combined in a multi-layer model.

The FIPS case is interesting because it requires a combination of 
capabilities #1 and #2. However, there are other cases that could 
benefit from different policies. I have described some of them below, 
providing a summary rationale for why a user might want to adopt the 
given policy, a filter conforming to the proposal that would achieve the 
desired outcome, and a comparison with how the same outcome might be met 
(or potentially be hard/impossible to meet) with the status quo. See 
Appendix #1.

As with most security properties, a specific configuration may render an 
application completely or partially unusable, and require a 
sysadmin/developer/security-expert to perform an assessment. This effect 
may be a desired outcome and trigger a remediation action. Other 
applications may react in a more resilient way and smoothly adapt to the 
policy enforced: use cryptography from an allowed security provider, 
skip the use of algorithms that are not allowed, ask the user to take 
action, etc. Our concern is that the lack of strong policy enforcement 
capabilities may lead to non-compliance issues going unnoticed.

Existing security capabilities such as the one to install or uninstall 
security providers, or even the one that allows to select preference per 
algorithm, require the knowledge of what these security providers 
implement and what applications require to use. Our proposal allows 
better granularity but is not different in terms of relying on public 
documentation or sysadmin/developer/security-expert knowledge.

While we don't necessarily share the view of the syntax as hard to use 
or error-prone, we concede that it leans more towards the expert UI side 
of all security properties. We designed the syntax with the ideas of 
consistency, similarity to the serialization filter —to the extent 
possible—, simplicity for trivial cases and powerfulness for complex 
ones. We want to make sure that it's not only tailored to our needs 
today but generic enough for other current or future uses. We tried to 
explain the use cases and desirable properties underneath the proposed 
design, but at the same time we would like to know if there is any 
aspect in particular that is of your concern and if you have any 
improvements to suggest so it's more accessible to less experienced 
users. We are open to considering specification, implementation and/or 
documentation changes.

Thanks,
Martin.-

--

Appendix #1

1) A policy that only authorizes the storage of certificates and keys in 
PKCS #11 devices, or in a specific instance managed by the 
CentralKeysProvider security provider:

*.KeyStore.PKCS11; !*.KeyStore; *

or

CentralKeysProvider.KeyStore; !*.KeyStore; *

In this scenario, a system administrator is concerned about how 
applications store sensitive cryptographic keys and intends to enforce a 
centralized or more restricted management. This policy aims to mitigate 
security risks and drawbacks associated with local file-based key 
storage. In the event of a key update, if centralized management is 
applied, applications have access to the latest key without any key 
population hassle. While this policy imposes restrictions on key 
storage, any security provider (including OpenJDK default ones) can use 
these keys after retrieval. This latter observation is relevant when, 
for example, PKCS #11 token devices with limited performance or 
algorithms availability are used.

We deem this type of policy useful for scenarios where centralized key 
management is feasible and desirable, or scenarios where keys are stored 
in hardware devices.

Enforcing this policy without the Security Provider Filter would be 
hard. While changing the default key store type by means of the 
keystore.type security property is possible, that configuration does not 
make other key store types unavailable. In addition, this security 
property lets users choose a key store algorithm but not its provider. 
Uninstalling security providers that offer unwanted KeyStore service 
types is not always an option because other service types they offer 
might be legitimately required. In other words, this option lacks 
granularity. The only way to enforce a policy such as the one described 
in this case is to audit the application and library sources, 
configurations or logs and check how keys are managed. This approach 
would require manual actions and rechecks after each application or 
library change.

The Security Provider Filter makes the enforcement of this policy easy, 
even under the circumstances of an application or library update, or 
after the deployment of a new application. The policy can also be 
updated to include other key store algorithms, security providers or 
combinations of both.

2) A policy that enforces the use of PKCS #12 key stores only:

*.KeyStore.PKCS12; !*.KeyStore; *

In this scenario, a system administrator is concerned about applications 
using key stores with non-standard formats such as JKS, JCEKS, BKS 
(Bouncy Castle) or BCFKS (Bouncy Castle) among others. These key store 
algorithms may introduce interoperability issues and require unwanted 
file conversions at some point. Thus, the system administrator enforces 
a policy that only authorizes the PKCS #12 standard for key storage.

As in case #1, the security property for controlling the default key 
store type is not enough to prevent applications from using other 
formats; uninstalling security providers is not always an option; and 
auditing application or libraries source code, configurations or logs to 
check how key storage is done could be inconvenient or unfeasible.

The Security Provider Filter provides flexibility to change the approved 
key store type or authorize more than one. Third-party security 
providers may refer to the PKCS #12 standard by different algorithm 
names but that should not be a problem either. For example, the filter 
may authorize algorithm name variations such as PKCS12, BCPKCS12 (Bouncy 
Castle) and PKCS12-3DES-3DES (Bouncy Castle): "*.KeyStore.PKCS12; 
*.KeyStore.BCPKCS12; *.KeyStore.PKCS12-3DES-3DES; ...", or more simply 
"*.KeyStore.*PKCS12*; ...".

3) A policy that does not allow algorithms considered insecure:

!*.*.MD5; !*.*.MD2; !*.*.SHA-1; *

Security concerns are the motivation behind this type of policy. A 
system administrator may enforce it with a deny-list —as done in the 
example— or even with a more strict allow-list one. This type of policy 
can be applied with algorithms considered secure today or algorithms 
that will be required in the future. The latter serves for the purpose 
of identifying potential compatibility issues and providing applications 
advanced notice to adapt.

While the Security Provider Filter is platform-independent, Linux 
crypto-policies is one of the motivations related to this case. Many 
Linux distributions, such as RHEL [2], have system-wide crypto-policies 
enabled by default. Different crypto-policies profiles (LEGACY, DEFAULT, 
FIPS, FUTURE, etc.) define sets of algorithms authorized for different 
software packages, including OpenJDK. Our intention is that 
crypto-policies for OpenJDK define, according to each profile, the set 
of algorithms allowed for all security APIs.

Before the Security Provider Filter, algorithms can be restricted for 
some uses with a deny-list type of configuration. However, not all uses 
are under scope and applications may use unauthorized algorithms by 
calling, for example, Signature.getInstance("<unauthorized-algorithm>") 
and using the service directly. Other approaches such as auditing 
application and libraries source code, configurations or logs to check 
which algorithms are used may not be practical, as pointed out in case #1.

The Security Provider Filter allows a system administrator to keep sets 
of authorized algorithms updated and apply its policy widely to all JCA 
service types.

4) A policy in which some uses of MD5 are acceptable (e.g. 
MessageDigest) but others are not:

!*.Signature.MD5*; !*.Mac.*MD5; !*.Cipher.*MD5*; *

or

*.MessageDigest.MD5; !*.*.*MD5*; *

Some algorithms may be secure for some uses but not for others. In this 
case, a system administrator authorizes MD5 for UUIDs, redundancy-check 
codes or other hashes, but prohibits its use for signatures, message 
authentication, and for deriving encryption keys (PBE).

This type of policy enforcement is possible because the Security 
Provider Filter lets users specify the service type, in addition to the 
algorithm. A system administrator can easily adjust the algorithms and 
service types that are allowed or disallowed.

For the same reasons explained in case #3, implementing this policy 
without the Security Provider Filter would not be possible or practical.

5) A policy in which only algorithms implemented by the FastProvider 
security provider are authorized for encryption:

FastProvider.Cipher; !*.Cipher; *

In this case, a system administrator is concerned about performance and 
wants applications to only do cipher operations in FastProvider.

While it is possible to insert FastProvider in the first place of the 
security providers list, or even use the preferred algorithms security 
property, an application that is using an algorithm not available in 
FastProvider will silently slide to a slower implementation. As 
described for other cases, removing slower security providers may not be 
an option, and auditing applications or libraries source code, 
configurations or logs may not be practical.

6) A policy that only allows a specific source of randomness, 
irrespective of the algorithm:

SunPKCS11-HSM.SecureRandom; !*.SecureRandom; *

A system administrator has security concerns about sources of randomness 
and decides to authorize only one of them, irrespective of the 
algorithm. In this case, the prioritized list of security providers is 
not enough to use SunPKCS11-HSM because applications may try to use 
algorithms not implemented there and silently slide into other security 
providers.

Enforcing this type of policy without the Security Provider Filter may 
require actions such as uninstalling security providers or auditing 
source code, configurations or logs that is not always possible or 
practical.

7) In CRIU scenarios, it could be beneficial to enforce a policy that 
does not allow the use of random values or key generation before a 
snapshot is taken. A snapshot can be taken, for example, running the JDK 
with the following filter value:

!*.SecureRandom; !*.KeyPairGenerator; !*.KeyGenerator; *

In some cases, a system administrator might want to enforce an even more 
strict policy using an allow-list approach:

*.MessageDigest.SHA-1; *.CertificateFactory; !*

When resuming a snapshot, no filter is set.

This example is based on a real case. To achieve the desired effect 
without the Security Providers Filter, a system administrator has to 
create a custom security provider that only implements authorized 
service types and algorithms. This security provider is the only one 
installed while taking the snapshot. When resuming snapshots, all 
security providers are enabled. This solution is hard to implement and 
not easily extensible to other service types and algorithms. With the 
Security Providers Filter it is easy to decide what is available while 
taking a snapshot, and what is available while resuming it.

This type of policy falls into the category of those that may benefit 
the security of a deployment. The reuse of random seeds or keys in 
different executions of the same snapshot may weaken or compromise the 
security of a system.

8) A policy that allows the use of a 3rd party security provider for a 
specific purpose but not for anything else:

3rdPartyProvider.AllowedService; !3rdPartyProvider; *

In this case, a system administrator has concerns of applications 
depending on a specific security provider for more service types or 
algorithms than what is authorized (AllowedService).

This type of policy is difficult to implement without the Security 
Provider Filter because there is no granularity when installing a 
security provider: it's an all or nothing decision. Thus, the only way 
around to enforce compliance is to check applications or libraries 
source code, configurations or logs and understand what they are 
depending on.

Examples Summary

Throughout the previous scenarios, we have discussed security, 
interoperability and performance concerns that may be addressed by the 
Security Providers Filter. What all these cases have in common is policy 
enforcement at provider, service type or algorithm level. We think that 
the existing providers or algorithms preference configurations miss the 
partial or total closure that the Filter offers. In addition, the lack 
of granularity makes the installation of a security provider an all or 
nothing decision. Thus, policy enforcement can only be applied by 
auditing applications or libraries source code, configuration or logs. 
This type of enforcement is not always possible or practical: a new 
deployment or update of an existing one requires a check. The existing 
functionality to block the use of algorithms does not extend to all 
security APIs and it's, thus, not enough from a policy enforcement and 
compliance perspective. While we have showcased fabricated system 
administration scenarios in some cases, others are of general interest, 
can be used more widely or represent real cases. On a final note, we 
have intentionally left the FIPS use-case out of this Appendix as it has 
been discussed in previous comments.

--
[1] - https://bugs.openjdk.org/browse/JDK-8315487
[2] - https://access.redhat.com/articles/3666211



On 9/19/23 16:42, Anthony Scarpino wrote:
> Hi Martin,
> 
> Thanks for the proposal. Your documents mostly describe the solution. 
> Can you provide more of the motivations and use-cases for the change? Do 
> you see non FIPS-140 applications using this feature?
> 
> The feature does provide a comprehensive filtering system for JCA. The 
> syntax, while powerful, seems like it would be somewhat error-prone and 
> hard to use. We are also concerned that using the filter requires the 
> sysadmin or developer to know about the service and algorithm details of 
> every provider and which is required and which is not, all of which is 
> not easily determined.
> 
> thanks
> 
> Tony