Hi Tony,
Thanks for pointing this out. Your observation is right.
We looked at this problem from a different angle, when defining internal
consistency of a filter value as out of scope [1]. Our concern was that
a filter value may render services unusable because of dependencies
(e.g. Signature.SHA1withECDSA depends on MessageDigest.SHA-1, and
filtering out the latter would render the former unusable). Your point
of view is also valid: there could be a difference in behavior when
comparing the effects of a filter value on services of the same type and
algorithm but implemented by different security providers.
Tracking dependencies between services or providers transparently
—without an explicit declaration or API— is a hard problem in our view.
Even without the Security Providers Filter, a security provider may
depend on others to work, and 3rd party providers are not necessarily an
exception. For example, SunEC depends on a provider implementing
MessageDigest.SHA-1, such as SUN, for SHA1withECDSA to work. These
dependencies are not always explicit by JCA API calls: a service may use
other services directly linking their classes. OpenJDK is agnostic when
it comes to configuration consistency and requires users to make an
informed decision when installing security providers.
The Security Providers Filter is not different in this regard. The
Signature.SHA1withECDSA service may use a MessageDigest.SHA-1
underneath, or Cipher.AES an AlgorithmParameters.AES one, but we don't
know upfront as it depends on each implementation. Other relationships
such as KeyStore.PKCS12 depending on Mac.PBE and Cipher.PBE services are
more complex and less obvious. Even beyond security providers, the
application itself may be unusable for a filter value. It's difficult to
reason or make assumptions about the interaction between services of
different types, or between services and the application itself, and
this is why we proposed to leave filter consistency on the user side.
From the four allow and block combinations of Signature.SHA1withECDSA
and MessageDigest.SHA-1, we see three as clearly motivated: allow both,
block both and allow SHA-1 for MessageDigest but not for Signature. The
combination of blocking SHA-1 for MessageDigest but allowing it for
Signature does not seem to reflect a real case. In general, our
impression is that combinations in which a building block is blocked but
a related higher-level service is allowed do not reflect real cases.
With that said, we also considered temporarily bypassing the filter
inside each service implementation. In this scenario, allowing
Signature.SHA1withECDSA in the filter would be enough for the service to
work, irrespective of MessageDigest.SHA-1 being blocked. We can think of
this as a specific instance of filtering by use or caller, as Sean
suggested some time ago [2]. From a technical point of view, this idea
might be feasible but we have more general concerns that are worth
discussing.
One relatively efficient way to implement this bypassing concept is to
have a thread-local value or a ThreadTracker instance that is set while
executing inside a service instance method or constructor. This value
would be checked at the time of getting a service and, if set, the
service is allowed without any filter check. For example, a
Signature.getInstance() call would return a Signature instance such
that, for each of its instance methods and SPI constructor, the
thread-local value or the ThreadTracker is set and temporarily
guarantees access to all MessageDigest services. Thus, you have a
working Signature.SHA1withECDSA service even if MessageDigest.SHA-1 is
blocked. Other (more sophisticated) approaches such as performing stack
walks would imply a higher performance penalty.
However, we are concerned about the consistency and security
implications of this concept:
1) What does it mean for a KeyStore or an SSLContext service to ignore
the filter internally? This could be a complete bypass of the filter in
practical terms. On the other hand, if we treat some service types
differently in terms of bypassing the filter, how confusing would it be
for the user? For example, Signature services use the filter bypass
concept but KeyStores or 3rd party service types do not.
2) How do we enforce filters across all JCA APIs and what guarantees do
we have? There will be open doors in each security provider to use
algorithms, service types or even security providers that should not be
used. For example, in a FIPS scenario we prefer a failure rather than a
non-FIPS crypto. In a CRIU-snapshot scenario we prefer a failure rather
than the use of a SecureRandom.
3) What are the run time costs that we add? Not a Security Manager stack
walk but still some overhead.
4) What would happen if a security provider —possibly from a 3rd party—
implements services in a parallel way? The thread-local mechanisms might
not be enough for these cases.
We are open to having this discussion but, based on the elements
previously described, we lean more towards keeping the filter plain and
simple. Adding a bypassing mechanism or checking internal consistency
only addresses a portion of the problem at the cost of an increased
complexity.
Regards,
Martin.-
--
[1] -
https://mail.openjdk.org/pipermail/security-dev/2023-February/034554.html
[2] - https://mail.openjdk.org/pipermail/security-dev/2023-July/036540.html
On 10/26/23 01:33, Anthony Scarpino wrote:
Hi Martin,
Thanks for the additional motivation.
While thinking about this PR, I found that the filter can be
inconsistently applied between JDK and 3rd party providers. The java
providers use the JCA to build combined algorithms. For example, the
ECDSAwithSHA1 that comes from SunEC uses getInstance() for
MessageDigest.SHA-1. HmacSHA1 and PBEWithHmacSHA1AndAES_128 do the same.
If a filter only contains "*.MessageDigest.SHA-1", it will disable all
the combined algorithms for JDK providers that use SHA1. For 3rd party
providers, these algorithms would likely be enabled. A PKCS11 provider
that supports ECDSAwithSHA1 would use its internal SHA1 that the filter
would not effect.
I think the filters should be consistently applied to all providers. JDK
providers and any 3rd party providers that uses this pluggable design,
should not be more restricted. This inconsistency could lead to an
incorrect configuration. Have you noticed this in your testing? Can
you think of a way to avoid the inconsistency without changing all these
combined getInstance() calls?
thanks
Tony
On 10/6/23 9:55 AM, Martin Balao wrote:
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://urldefense.com/v3/__https://access.redhat.com/articles/3666211__;!!ACWV5N9M2RV99hQ!Po2RuiDeYlR92dfYip2ezt4Rm3LYPgRNL7QyeHqnNxFwSisPcez2ySr3eFLgt2vLeJhwN2qZKwcedWuMlYnq$
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
