Java 17 to 21: A Showcase of JDK Security Enhancements

[Music]

thank you everyone for joining a

security talk at 400

p.m. it's a little late in the afternoon

for some security topics um however I'm

grateful that you're here hope you will

enjoy this presentation until the end

that you will learn some useful things

that you can take in your daily

job and I'm looking forward to your

questions um at the end of the

presentation first of all I'm Anna

currently working as a developer

advocate in the Java team at Oracle I

enjoy programming with Java probably

like many of you since you are in this

room today and of course I enjoy working

with kubernetes as well now apart from

these two passions um I also like

security um in my past roles I like

security because I had to because it's

great to build secure software you have

your end users happy when they can

safely use their

applications uh so kind of security like

for many of you is embedded in the

practices that I have when I

code now when we talk about Java we I

hope that all of us in this room are

familiar with the new release Cadence or

you get to see many features delivered

every 6 months that you can try uh that

you can give uh um a feedback on and

these features are from multiple areas

many of them on language others on

performance and someone security yet

while these features get like Prime Time

your daily life can be impacted by those

many many enhancements that are not

necessarily formulated in a Jeep and

this presentation will show some of

those significant changes from 17 to 21

so if I am to ask you and because this

is a big room I cannot see all of you

but if I to ask you the question in the

slide can you shout at

me what do you think changed a change

that happened after jdk

17 with the security and jdk

anything just shout

it

records records that's a language

feature

security manager Bingo that's a very

good one the application for removal

we're going to talk a bit about it

anything else crypto

crypto that's a broad area we're going

to talk about it too anything

else

what I didn't understand you can you

please shout it h there TS TLS yes TLS

enhancements yes all great

answers and many more because we have 50

minutes for this presentation so I had

to fill it with something but the reason

why we care so much about jdk security

as developers is because over time the

algorithms that we are that we're using

in our applications weaken and can be

exploited more easily and it happens

that a GDK release take for example GDK

8 can Outlast the lifetime when these

algorithms are viable I mean jdk8

there's still many applications running

on those so what happens is that the

Java platform the jdk gets continuously

improved so that you can build secure

applications You're Building modern

applications but still they have to be

secured you're choosing Java to evolve

your applications because you know it's

secure that's one of the main things

that comes to your mind besides the

beautiful language there are many

beautiful languages that you can utilize

but you're also choosing them because

choosing Java because of security and of

course it's good to say to the business

Java is

secure so throughout time I've seen that

well people can think of java

security um as was some broad term so

what is Java security well Java security

has many components and since I'm going

to reference them in the presentation I

just want you to have a picture in your

head when I'm talking about them so here

they are the Java security components

are in the slide and of course they

start somebody said records of course it

starts with the

language um well but in the case of

security itself that is in the jdk the

higher level abstractions like you can

see here in the slide they are built on

top of lower layer Concepts so this is

why it's this like a brick wall

diagram and of course at the bottom the

Java language anguage is designed to be

type safe and easy to use so it has many

features that you probably use in your

application but the foundation of java

security well is based on

cryptography so the cryptography

component the Java cryptography

architecture

jca um or JC the Java cryptography

extension enables you to encrypt and

decrypt data in Java manage Keys sign

and authenticate message

and much more now we have also pki that

contains apis and implementations for

validating and building certification

paths or certification chains for only

many of your applications use

certificates and of course a way to

store those keys and

certificates next we go with how the

programs can access Security Services

via this lovely acronym which I'm not

going to read from the slide because I'm

terrible reading that acronym but we can

talk afterwards what it means it stands

for generic Security Service application

program interface that's why GSS upy and

the jdk contains such a GSS up

implementation of curve Ross now the

transport layer security which was

mentioned

earlier that

component is containing apis for TLS and

dtls and of course we're signing jars so

sign jars allow you to apply digital

signatures to the jar files in order to

ensure that you're sharing those with

some data integ the data you have in

those is shared with data integrity and

authenticity now the next components

they're

together because there are a series of

Frameworks and apis that are meant for

authentication and

authorization and of course probably

some of you have worked with XML

signatures which are a component uh well

this component that contains an API

implementation for generating and

validating XML

signatures but Java security is more

than just apis built on top on the

runtime it's also tools because

sometimes you need tools in your tool

chains to maybe I don't know validate

your certificates or and of course if

the jdk comes with them why not use them

since they're there so you get a small

set of tools that can help you set

security

policies probably many of you have

utilized in this lifetime key tool at

least

experimentally it's for managing key

stores keys and certificates of course

we have jar signer the one that we

talked a little bit earlier for sign

jars that helps of course signing those

jars and the last tab are actually the

tools for working with

kbros um but since Kos is not so touched

uh I'll leave them in peace for the

moment so hope you're feeling happy to

explore what happened with jdk

security and we're going to start with

the happy Parts modern cryptographic

algorithms now I started this

presentation telling you that over time

most or all algorithms weaken so they

can be exploited more easily now if you

get strong args you can continuously um

benefit of a stronger foundation for

your

application larger key sizes have been

delivered in jdk um 20 and 21 so you can

benefit of larger key sizes by default

like in case that when you're relying

for on the defaults and you're just

instantiating something um instantiating

a key without specifying the size

although that many examples over the

internet can have the size but if you

forget about that you don't need to

worry because the GDK can build that

securely at its best for you so you can

have here a table of what changed over

time this is good because this change

protects your data and communication by

using mathematical techniques that

ensure confidentiality integrity and

authenticity

better yet the tides of security threats

increase with the advancement of

technology and if you were the Kino this

morning

you probably saw the very nice keynote

about AI how AI can help us but those

were the good parts Ai and of course

computers that have large powerful cap

and large powerful

capabilities well they can be

instrumented for the wrong as well so if

large scale quantum computers are ever

built just this is a

hypothesis all widely used digital

signature schemes like

DSA RSA ecdsa and so on have the

potential to be broken that's because

the power of computation increased so

the IT industry has worked towards the

goal of creating postquantum

cryptographic algorithms that are

designed to be safe against such

powerful capabilities to

compute so as these postquantum

cryptographic algorithms progress and

mature of course they become standards

and are gradually Incorporated with the

Java security

components so we got the first post

Quantum cryptographic algorithms in open

jdk and you have here the explanation on

the slide so that you would know what it

stands for when you read

SSS

LMS so the lat Malla signature system is

one of the um one of these algorithms

and is the stateful health uh is a

stateful hash based algorith it's all

based on the hash based signature scheme

HPS that's what it's coming from the

hierarchical signature system is the

multi- three variant of the previous one

that's why it's SSS

LMS and most importantly it's one of the

two Quantum resistant signature

algorithms that have been standardized

there is another one it's called

XMS uh s it's similar but it's last

popular so the popular variant was

chosen um for the use case of such an

algorithm uh well it's used for software

and or firware

signing um and requires for the key and

signature generation to be performed in

Hardware cryptographic modules so that

they because those they do not allow

secret keying material to be exported

even in encrypted form that's why it

makes it quantum resistant it's hard to

export that from the

hardware so if we take a step back what

was done in the jdk right if um the um

signature generation happens on Hardware

what's happening in the jdk so when in

the jdk side the signature verification

implementation was

done so while the generation happens on

Hardware you can verify that signature

in the

jdk um and of course

you can have here in the slides the

explanations on why these this algorithm

is very great another thing that I need

to tell you is that this belief that the

security of LMS because it depends on

the security of the underlying hash

functions well it is believed that this

security is will never be broken by the

development of large scale computer

quantum computers hence why it's so

loved and

adopted now how does that look in your

code so how how do you verify a

signature with this new algorithm a

little bit of code in the slide just to

show you how it looks like you can use a

key Factory implementation available

from a provider now in this case if

you're running it with open jdk

distribution it probably will choose the

sound provider because that's the first

one that it finds it matches it and that

one will read an SSS LMS public key from

a stem a serialized

format so that's Reading part and of

course you need to verify the validity

and probably you've wrote this kind of

code sometimes to verify the validity of

a signature that uses SSS slms so the

thing that changed of course is the

algorithm being supported something

that's coming in 22 Key tool can also

operate with this one as well right now

it's available at the API level but in

22 jk22 it will have ke tool will have

that as a feature too so this one was

was one of the Breakthrough changes of

21

but besides the modern cryptographic

algorithms bringing new on the jdk

restricts the algorithms that are

weakened however there are multiple ways

to limit the usage of vulnerable

algorithms either the jav Java limits or

disables them to ensure that you are

running on a robust environment for your

not only for your own development but

also for your end users so what was

restricted some people probably saw that

kind of message when they tried to

validate a jar that was signed with

shaan and that it was having its

signature uh generated before 2019 1 of

January in 2019 so that's get a you get

a warning on that what's the story

behind it why Shawan jars were disabled

by default in Java 18 as the slide says

well it happens that in

2011 the National Institutes of

standards and Technology nist formally

dicated shaan usage and kind of told the

people well you know by

2030 you should kind of phased out the

usage from digital signatures that news

came two years later in

2013 so in consequence shaan was

disabled in TLS server certificates and

XML signatures was not just here now in

order to make sure that people are not

using this any

further jdk security team thought it

would be better if your

chars if you try to sign your chars with

this algorithm well to get the warning

that well um it's not good for you so

there's a a way to maintain uh backwards

compatibility of course for some of the

JS so if your jar was time stamped prior

to

20190101 We Shall one you get kind of

get away with it but uh if you have like

a very strict security team they can

alter a little bit the security rules

for you and they can impediment it so

I've seen cases when people went even

stricter given the threat of Shawan

usage so they restricted their security

properties even more we're going to talk

about that in a little

while so this was

one um another one delivered a lot

actually more delivery in 19 and 20

we're disabling weak TLS algorithms so

somebody mentioned TLS yes there were

enhancements but also disabled things

were disabled with the

TLs so in order to make it harder to use

week 3 3D Cipher suits they have been

removed from uh the TLs Cipher suits in

jk9 next 3s and arc4 they're also not

very safe um and because they were not

very safe also their Amon thls

ecdh ecdh Cipher suit also was disabled

because it doesn't preserve forward

secrecy and also it was rarely used in

practice sometimes these algorithms

they're not just insecure but they also

used in practice so disabling them is

not that difficult and well tls1.0 T and

TLS 1.1 they were disabled from April

2021 but as of J K2 dtls 1.0 is also

disabled because applications by the way

should use dtls 1.2 protocol which is

more secure and supported by the jdk but

in case that you have

issues yes you can also enable the one

that has been disabled you can reenable

it in the Java security configuration

file but that's something that you do at

your own risk so there's always a way to

alter the Java security file

but that's at your own risk when the um

of course the guidance says

different another thing that

came in the disabled algorithms area

restriction rules so how does these

rules are being put in application how