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

[Anthony Scarpino]

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
>