Re: Security provider self-integrity checking changes in JDK 9.0?

[Bradford Wetmore]

On 9/25/2018 2:14 PM, John Gray wrote:

Hello,

We have a couple questions regarding Jar verification in Java 9 (and later)


...deleted...

There is no mention of the self-integrity checking in this section?
There doesn’t seem to be an explanation as to why it was removed?


The self-interity requirement check was necessary for very early 
versions of JCE when crypto regulations were different, but is no longer 
necessary.  IIRC, we left the guidance in because some folks were still 
targeting those ancient versions along with JDK 6/7.  But with the docs 
cleanup in 9, we removed some of the old obsolete information like that.


---begin---
IMPORTANT NOTE: In the unbundled version of JCE 1.2.x, (used with JDKs 
1.2.x and 1.3.x), providers needed to include code to authenticate the 
JCA framework to assure themselves of the integrity and authenticity of 
the JCA that they plugged into. In JDK 6 and later, this is no longer 
necessary.

---end---

Thanks,

Brad




In Section 8.2, it briefly mentions self-integrity checking:

Step 8.2: Set Provider Permissions

Permissions 
 
must be granted for when applications are run while a security manager 
is installed. A security manager may be installed for an application 
either through code in the application itself or through a command-line 
argument.


 1. Your provider may need the following permissions granted to it in
the client environment:
  * java.lang.RuntimePermission to get class protection domains. The
provider may need to get its own protection domain in the
process of doing self-integrity checking.
  * java.security.SecurityPermission to set provider properties.

So we are just wondering if something has changed in JDK 9 (and later) 
that makes the self-integrity check by a security provider 
unnecessary.   If it has been changed, could we get information as to 
what has changed and why it changed?


Thanks so much

John Gray

Entrust Datacard

Security provider self-integrity checking changes in JDK 9.0?

[John Gray]

Hello,

We have a couple questions regarding Jar verification in Java 9 (and later)


We produce a Java based toolkit that contains a Security Provider.   Because of 
this, we follow the guidance on the following page:

https://docs.oracle.com/javase/9/security/howtoimplaprovider.htm#JSSEC-GUID-C6054169-FE6E-4837-B2BD-382DFEB955C0


However, we have recently noticed a change between JDK 9 and JDK 8


In JDK 8:  
(https://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/HowToImplAProvider.html)
Step 1.1: Additional JCA Provider Requirements and Recommendations for 
Encryption Implementations

When instantiating a provider's implementation (class) of a Cipher, 
KeyAgreement, KeyGenerator, MAC or SecretKey factory, the framework will 
determine the provider's codebase (JAR file) and verify its signature. In this 
way, JCA authenticates the provider and ensures that only providers signed by a 
trusted entity can be plugged into JCA. Thus, one requirement for encryption 
providers is that they must be signed, as described in later steps.

In addition, each provider should perform self-integrity checking to ensure 
that the JAR file containing its code has not been manipulated in an attempt to 
invoke provider methods directly rather than through JCA. For further 
information, see How a Provider Can Do Self-Integrity 
Checking.


In JDK 9:  (https://docs.oracle.com/javase/9/security/howtoimplaprovider.htm )

Step 1.1: Consider Additional JCA Provider Requirements and Recommendations for 
Encryption Implementations

When instantiating a provider's implementation (class) of a Cipher, 
KeyAgreement, KeyGenerator, MAC, or SecretKey factory, the framework will 
determine the provider's codebase (JAR file) and verify its signature. In this 
way, JCA authenticates the provider and ensures that only providers signed by a 
trusted entity can be plugged into the JCA. Thus, one requirement for 
encryption providers is that they must be signed, as described in later steps.

There is no mention of the self-integrity checking in this section?There 
doesn't seem to be an explanation as to why it was removed?


In Section 8.2, it briefly mentions self-integrity checking:

Step 8.2: Set Provider Permissions
Permissions
 must be granted for when applications are run while a security manager is 
installed. A security manager may be installed for an application either 
through code in the application itself or through a command-line argument.

  1.  Your provider may need the following permissions granted to it in the 
client environment:
 *   java.lang.RuntimePermission to get class protection domains. The 
provider may need to get its own protection domain in the process of doing 
self-integrity checking.
 *   java.security.SecurityPermission to set provider properties.


So we are just wondering if something has changed in JDK 9 (and later) that 
makes the self-integrity check by a security provider unnecessary.   If it has 
been changed, could we get information as to what has changed and why it 
changed?


Thanks so much

John Gray
Entrust Datacard

Re: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx

[sha . jiang]

2. Is launching a separate process necessary? Can we just call 
KeyToolTest::main after setting system properties and copying the files.

I did think about this point.
It looks this test could be run by manual if someone want to set those 
system properties.

I supposed that's why KeyToolTest.java is not a jtreg test.

I misunderstood this point.
Will apply that.

Best regards,
John Jiang

Re: Conceptual feedback on new ECC JEP

[Michael StJohns]

On 9/25/2018 12:06 PM, Xuelei Fan wrote:



On 9/25/2018 8:34 AM, Adam Petcher wrote:
Yes, it is possible, at the expense of some assurance related to 
security against side-channel attacks. This interoperable 
implementation will be available by default in SunEC. A 
higher-assurance form of the same implementation will be available in 
the new provider. The additional effort required to put this 
implementation in both providers is expected to be relatively small.
Can we have the same security level impl in SunEC in some 
circumstances?  For example, when the key is not imported for the 4 
named curves. Using a new provider means we force applications to 
choose between weak and interop, just because we cannot provide both 
at the same time.


Thanks,
Xuelei


There's a hole in my desk from where I've been pounding my head on this 
subject.


Basically, for the opaque operations - signing, verifying, deriving 
shared secrets - Adam can meet his branchless goal.  For the non-opaque 
operations - importing and exporting the private key according to the 
interface specifications, he can't or thinks he can't.   And even with 
the latter - with the use of PKCS12 as the standard key store format - 
the import of a private key from a key store (e.g. internally stored as 
PKCS8) should be able to be implemented branchless without too much effort.


It's only when moving key material to/from his implementation where 
there are interoperability requirements that might involve branching 
(and not even then if he makes his own version of BigInteger to avoid 
those branches in the new() methods).  Given that once the key leaves 
his implementation he has no control over whether it's used branchless, 
it's utterly disingenuous to claim that the process of exporting also 
must be branchless.


So to clarify: all of his opaque code will be "high assurance" - and 
that's will be what's used about 99.999% of the time. The rest of this 
is just religious dogma that doesn't consider the actual use cases and 
costs related to moving keys to/from his implementation.


Later, Mike

Re: Conceptual feedback on new ECC JEP

[Xuelei Fan]

On 9/25/2018 8:34 AM, Adam Petcher wrote:
Yes, it is possible, at the expense of some assurance related to 
security against side-channel attacks. This interoperable implementation 
will be available by default in SunEC. A higher-assurance form of the 
same implementation will be available in the new provider. The 
additional effort required to put this implementation in both providers 
is expected to be relatively small.
Can we have the same security level impl in SunEC in some circumstances? 
 For example, when the key is not imported for the 4 named curves. 
Using a new provider means we force applications to choose between weak 
and interop, just because we cannot provide both at the same time.


Thanks,
Xuelei

Re: Conceptual feedback on new ECC JEP

[Xuelei Fan]

On 9/25/2018 8:34 AM, Adam Petcher wrote:

On 9/25/2018 11:15 AM, Xuelei Fan wrote:

I did not follow the discussion.  But it does not sound right to me to 
have an application to be provider dependent (#3).


There will be nothing provider-dependent in the TLS implementation. The 
point of #3 is to say that we should test the TLS implementation to 
ensure that it will work with either "EC" provider. The only required 
changes to TLS code will be using PKCS8 private keys instead of 
BigInteger private keys.


I read it as there is no need to change TLS implementation, right?  The 
change from BigInteger private keys to PKCS8 private keys is for test 
only, right?  What if we don't change test code as well?  Can an 
existing application survive if it uses BigInteger private keys (okay, I 
this is a interop question)?




I was not confident that a new provider instead of updating the 
existing provider is a good idea.  It might be a significant effort to 
update existing provider.  However, if we don't do that, the cost to 
use the new provider is not minimal.


As we discussed previous, lacking interop could face significant 
issues and result in complicated coding in practice.  Thinking about 
SunPKCS11 and SunMSCAPI provider, and how many trouble we have had for 
them, and how many workaround we have patched for them.


Unless it is not possible to have an interop-able implementation, I 
would suggest take more time to have an interop-able design and impl.


Is it possible to have an interop-able impl?  If it is possible, how 
much effort will it take?


Yes, it is possible, at the expense of some assurance related to 
security against side-channel attacks.

We may not want to have an impl to expose to side-channel attacks.

Okay, let me ask the question in another way.  Is it possible to have an 
interop-able impl without losing the quality of the new formula 
(side-channel attacks, etc)?   How much effort will it take to make it 
possible (please consider even we have to update the BigInteger APIs as 
well)?


Sorry for so much question, I did not take enough time for the new 
formula.  So I depend on the questions to you so that I can have a 
better feel of the design.


Thanks,
Xuelei

This interoperable implementation 
will be available by default in SunEC. A higher-assurance form of the 
same implementation will be available in the new provider. The 
additional effort required to put this implementation in both providers 
is expected to be relatively small.

Re: Conceptual feedback on new ECC JEP

[Adam Petcher]

On 9/25/2018 11:15 AM, Xuelei Fan wrote:

I did not follow the discussion.  But it does not sound right to me to 
have an application to be provider dependent (#3).


There will be nothing provider-dependent in the TLS implementation. The 
point of #3 is to say that we should test the TLS implementation to 
ensure that it will work with either "EC" provider. The only required 
changes to TLS code will be using PKCS8 private keys instead of 
BigInteger private keys.




I was not confident that a new provider instead of updating the 
existing provider is a good idea.  It might be a significant effort to 
update existing provider.  However, if we don't do that, the cost to 
use the new provider is not minimal.


As we discussed previous, lacking interop could face significant 
issues and result in complicated coding in practice.  Thinking about 
SunPKCS11 and SunMSCAPI provider, and how many trouble we have had for 
them, and how many workaround we have patched for them.


Unless it is not possible to have an interop-able implementation, I 
would suggest take more time to have an interop-able design and impl.


Is it possible to have an interop-able impl?  If it is possible, how 
much effort will it take?


Yes, it is possible, at the expense of some assurance related to 
security against side-channel attacks. This interoperable implementation 
will be available by default in SunEC. A higher-assurance form of the 
same implementation will be available in the new provider. The 
additional effort required to put this implementation in both providers 
is expected to be relatively small.

Re: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx

[sha . jiang]

Hi Max,

On 2018/9/25 22:30, Weijun Wang wrote:

Some questions:

1. Do we still need the OS check on lines 47-49? As long as getLibPath() can 
return something, does it mean the test should just run? Especially, does the 
test run on Windows?
The original test ignores Windows, and says "This test is only executed 
on several platforms".

So, I didn't change this test logic.
But I'll have a try without that OS checking.


2. Is launching a separate process necessary? Can we just call 
KeyToolTest::main after setting system properties and copying the files.

I did think about this point.
It looks this test could be run by manual if someone want to set those 
system properties.

I supposed that's why KeyToolTest.java is not a jtreg test.



3. Is it possible to include standard.sh?

No problem. This test looks quite similar to autotest.sh.

Best regards,
John Jiang


Thanks
Max


On Sep 25, 2018, at 6:30 PM, sha.ji...@oracle.com wrote:

Hi,
JDK-8164639 removed NSS libs from repo, so 
sun/security/tools/keytool/autotest.sh has to download NSS libs from 
artifactory on macosx.
This patch also refactors this shell test to a Java test.

Webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8209546

Best regards,
John Jiang

Re: Conceptual feedback on new ECC JEP

[Xuelei Fan]

I did not follow the discussion.  But it does not sound right to me to 
have an application to be provider dependent (#3).


I was not confident that a new provider instead of updating the existing 
provider is a good idea.  It might be a significant effort to update 
existing provider.  However, if we don't do that, the cost to use the 
new provider is not minimal.


As we discussed previous, lacking interop could face significant issues 
and result in complicated coding in practice.  Thinking about SunPKCS11 
and SunMSCAPI provider, and how many trouble we have had for them, and 
how many workaround we have patched for them.


Unless it is not possible to have an interop-able implementation, I 
would suggest take more time to have an interop-able design and impl.


Is it possible to have an interop-able impl?  If it is possible, how 
much effort will it take?


Thanks,
Xuelei

On 9/25/2018 7:40 AM, Adam Petcher wrote:
Thanks, everyone for your feedback on this JEP. I have incorporated this 
feedback (received on this mailing list and elsewhere) into the draft 
JEP[1]. Here is a summary of the current JEP and plan:


*) A new provider (name TBD) will be developed to hold the new ECC 
implementation for the three curves. This provider will feature the 
interoperability-limiting restrictions on its API that were discussed at 
length on this mailing list. The new provider will be at the end of the 
list, so it won't be used by default.
*) The operations of the new implementation will also be added to SunEC 
for the three curves. This means that the new implementation will be 
used by default, in a completely compatible way (without any 
restrictions on its API). Using the new implementation through SunEC 
will not provide the same level of security against side-channel attacks 
as using it through the new provider.
*) We will add some tests that make sure that TLS still work when the 
new provider is used instead of SunEC. We may need to make some small 
changes to the TLS implementation in order to get these tests to pass.
*) A couple of people asked me about whether we could modernize the 
implementation of more curves in the future. I added a section at the 
end of the JEP to discuss this.


Of course, none of this is set in stone, and we still have some API 
details to work out in the CSR. I'll be doing the CSR next, and I'm 
happy to accept feedback at any time.


[1] https://bugs.openjdk.java.net/browse/JDK-8204574


On 8/23/2018 1:50 PM, Adam Petcher wrote:
I'm starting work on yet another ECC JEP[1], this time with the goal 
of developing improved implementations of existing algorithms, rather 
than implementing new ones. The JEP will re-implement ECDH and ECDSA 
for the 256-, 384-, and 521-bit NIST prime curves. The new 
implementation will be all Java, and will resist side-channel attacks 
by not branching on secrets. It will go in a new provider which is not 
in the provider list in the java.security file by default. So it will 
need to be manually enabled by changing the configuration or putting 
the new provider name in the code. It will only support a subset of 
the API that is supported by the implementation in SunEC. In 
particular, it will reject any private keys with scalar values 
specified using BigInteger (as in ECPrivateKeySpec), and its private 
keys will not return scalar values as BigInteger (as in 
ECPrivateKey.getS()).


Please take a look and send me any feedback you have. I'm especially 
looking for suggestions on how this new implementation should fit into 
the API. I would prefer to have it enabled by default, but I can't 
think of a way to do that without either branching on secrets in some 
cases (converting a BigInteger private key to an array) or breaking 
compatibility (throwing an exception when it gets a BigInteger private 
key).


[1] https://bugs.openjdk.java.net/browse/JDK-8204574

Re: Conceptual feedback on new ECC JEP

[Adam Petcher]

Thanks, everyone for your feedback on this JEP. I have incorporated this 
feedback (received on this mailing list and elsewhere) into the draft 
JEP[1]. Here is a summary of the current JEP and plan:


*) A new provider (name TBD) will be developed to hold the new ECC 
implementation for the three curves. This provider will feature the 
interoperability-limiting restrictions on its API that were discussed at 
length on this mailing list. The new provider will be at the end of the 
list, so it won't be used by default.
*) The operations of the new implementation will also be added to SunEC 
for the three curves. This means that the new implementation will be 
used by default, in a completely compatible way (without any 
restrictions on its API). Using the new implementation through SunEC 
will not provide the same level of security against side-channel attacks 
as using it through the new provider.
*) We will add some tests that make sure that TLS still work when the 
new provider is used instead of SunEC. We may need to make some small 
changes to the TLS implementation in order to get these tests to pass.
*) A couple of people asked me about whether we could modernize the 
implementation of more curves in the future. I added a section at the 
end of the JEP to discuss this.


Of course, none of this is set in stone, and we still have some API 
details to work out in the CSR. I'll be doing the CSR next, and I'm 
happy to accept feedback at any time.


[1] https://bugs.openjdk.java.net/browse/JDK-8204574


On 8/23/2018 1:50 PM, Adam Petcher wrote:
I'm starting work on yet another ECC JEP[1], this time with the goal 
of developing improved implementations of existing algorithms, rather 
than implementing new ones. The JEP will re-implement ECDH and ECDSA 
for the 256-, 384-, and 521-bit NIST prime curves. The new 
implementation will be all Java, and will resist side-channel attacks 
by not branching on secrets. It will go in a new provider which is not 
in the provider list in the java.security file by default. So it will 
need to be manually enabled by changing the configuration or putting 
the new provider name in the code. It will only support a subset of 
the API that is supported by the implementation in SunEC. In 
particular, it will reject any private keys with scalar values 
specified using BigInteger (as in ECPrivateKeySpec), and its private 
keys will not return scalar values as BigInteger (as in 
ECPrivateKey.getS()).


Please take a look and send me any feedback you have. I'm especially 
looking for suggestions on how this new implementation should fit into 
the API. I would prefer to have it enabled by default, but I can't 
think of a way to do that without either branching on secrets in some 
cases (converting a BigInteger private key to an array) or breaking 
compatibility (throwing an exception when it gets a BigInteger private 
key).


[1] https://bugs.openjdk.java.net/browse/JDK-8204574

Re: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx

[Weijun Wang]

Some questions:

1. Do we still need the OS check on lines 47-49? As long as getLibPath() can 
return something, does it mean the test should just run? Especially, does the 
test run on Windows?

2. Is launching a separate process necessary? Can we just call 
KeyToolTest::main after setting system properties and copying the files.

3. Is it possible to include standard.sh?

Thanks
Max

> On Sep 25, 2018, at 6:30 PM, sha.ji...@oracle.com wrote:
> 
> Hi,
> JDK-8164639 removed NSS libs from repo, so 
> sun/security/tools/keytool/autotest.sh has to download NSS libs from 
> artifactory on macosx.
> This patch also refactors this shell test to a Java test.
> 
> Webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8209546
> 
> Best regards,
> John Jiang
> 

Re: RFR 8076190: Customizing the generation of a PKCS12 keystore

[Weijun Wang]

Webrev updated at http://cr.openjdk.java.net/~weijun/8076190/webrev.03/.

Mostly spec changes. The test is enhanced a little to check for macAlg interop.

> On Sep 24, 2018, at 11:15 PM, Sean Mullan  wrote:
> 
> Right, I understand their usage and the properties are well documented. My 
> comment is that if you just read the first sentence which is typically a 
> summary sentence, it gives no indication that some of these properties may 
> also be used when modifying a keystore. You have to read further to figure 
> that out, and that might be missed. Perhaps if you added a second sentence to 
> the first paragraph: "Several of the properties may also be used when 
> modifying an existing keystore." Then the next paragraph starts ...

Good.

> 
>>> The default alg values seem somewhat weak. Can we upgrade them or is there 
>>> a compatibility issue/risk?
>> It will be addressed in a different RFE and is not related to migrating 
>> cacerts to password-less.
>> I haven't studied it yet. Need to investigate how current releases of 
>> various tools (openssl, browsers...) support it.
> 
> Ok.
> 
> Still need to review PKCS12KeyStore, but here are some more comments:
> 
> * java.security
> 
> You should probably say that these properties are specific to the JDK PKCS12 
> KeyStore implementation and may not be supported by other PKCS12 
> implementations.
> 
> What happens if the properties are not set or are set to the empty String?

When not set, there is a default value. It happens to be the same as what the 
out-of-box java.security shows.

When empty, there will be an error. Say, NumberFormatException, 
NoSuchAlgorithmException.

> Are the algorithm names case-insensitive?

Should be case-insensitive. For each one, I've specified it as "algorithm 
defined in the XYZ section of standard names". Is that enough to show it's 
case-insensitive?

> 
> What if illegal values, or unknown algorithms are set for the properties? Are 
> they ignored? Do they throw an Exception? Or do they fallback to hard-coded 
> defaults? This behavior should be specified.

Throw an exception. I cannot guarantee when it will be thrown so I just say 
"when it's used".

> 
> * Passwordless
> 
> Can you add some comments as to why openssl is needed? Aren't there some 
> tests you can still do if it is not there? And maybe add some comments in the 
> class description as to what the test is generally testing as it hard to 
> discern that from just scanning the code.

Interoperability. I generate pkcs12 keystores from openssl using various 
settings and make sure keytool can read them, vice versa. Maybe I should move 
it to the infra test group.

Thanks
Max

> 
> --Sean

RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx

[sha . jiang]

Hi,
JDK-8164639 removed NSS libs from repo, so 
sun/security/tools/keytool/autotest.sh has to download NSS libs from 
artifactory on macosx.

This patch also refactors this shell test to a Java test.

Webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8209546

Best regards,
John Jiang

Re: recursive initialization issue with custom security manager

[Alan Bateman]

(I've changed the subject line to distinguish it from the ongoing 
discussion about introducing an execution mode that does not support the 
security manager)


On 25/09/2018 03:19, Peter wrote:

Hi Alan,

Ok will do.  I'm guessing the test case needs to be a jtreg test?
It doesn't need to be a jtreg test, I think all we need here is a 
minimal SecurityManager that shows the bug you are running into. As I 
said, there have been several changes in this area since JDK 8 so a 
custom SM that shows the issue with JDK 11 or JDK 12 EA builds would be 
good. I hope it doesn't require bringing along a complete URI parser.


-Alan