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

about these weak algorithms because they

they're not taken out they needs to be a

mechanis for that so in case of Koss

there's a car five.com file where you

can set those restriction rules for

security properties of the jdk of course

is the Java security configuration file

you can set there now for kbros for

those of you that maybe this sounds a

little bit foreign kbros is the protocol

for authenticated service requests

between trusted hosts and across let's

say in trusted Network like internet but

probably you saw keros if you ever

configured an application server like in

the old times that's probably You' have

seen curb Ross and details about it in

case of those application servers

configuring the KY by 5.com file is

crucial if you're using jars of course

for jar verification certificates TLS

and so on you can always work with a

Java configuration

file so for curve Ross let's start how

does the removing look like so in the

slide on my left side I would say okay

you can find on how an exerpt of kerros

configuration file looks like and I

extracted those two configurations

specifically because they're something

important with them so first of all desk

three des and rc4 encryption types well

they were removed from the default list

of carbros encryption types but

more um they were

disabled uh and you see that there's set

alone that allow weak crypto properties

set to false in uh in the slide right

why is that well allow crypto properties

acting like a global property and when

it's said to true you're actually

allowing all the bad algorithms that you

didn't want to have to be

selected so what happens if you want to

selectively reenable some of those

removed

weak um Cur encryption types because you

need it because your application cannot

evolve without those your server doesn't

start with that in configuration so in

those situations when you are in

need don't go and set allow crypto to

True by the way you can do that

selectively with a second property with

a permitted encryption types so there

you can go and say Hey I want you to

enable selectively these algorithms I

yeah probably they're not secure or

probably May some of them are secure and

they haven't been removed but only do

this for only a selected type don't do

this for everything they use the global

one so there's a way to escape but more

controlled and well it's always to have

this message that while re-enabling any

weak encryption type or any algorithm

that's considered disabled is always at

your own risk so be pay paying attention

when you reset your

configurations they can work against you

so

next in the jdk security configuration

file this is where you can modify

information about your security

properties and we have two types of

security uh properties so now you're

going to see highlighted in the slides

the different ones so the first ones are

the disabled ones this means that this

configuration restricts various

functionality Legacy me the other ones

that you really shouldn't use them

because they will be disabled most

likely in a future jdk release so Legacy

kind of allows you a way to still use

them but be paying attention that

sometimes they're going to go in the

forever gone category of disabled yes

you can alter the list there but again

at your own

risk so somebody else said something jdk

17 yes security manager security manager

was deprecated for removal in jdk 17

H

but you probably heard a lot about it it

generated a lot of rumor that

applications will be so much impacted

about this even though to your surprise

you're going to see that well was a

feature that was originally designed as

a stand boox for running potentially

untrusted applets who uses applets

nowadays then it was later enhanced to

have a fine grain permission Pro

permission model that was never widely

used so uh pretty much it had a lot of

things that were not useful to us so

because of the brittle permission model

difficult programming model and of

course poor performance that got to its

deprecation for removal in JK

177 however security manager still fully

supported in jdk 17 but you'll receive

warnings at runtime if you try to use it

so probably you've seen

that the other thing is that several

apis in the jdk thought it was a good

idea back then to use the security

manager in the beginning so because they

were tied to security manager there had

to be some replacement there needs

something to be done to it once this one

is deprecated for removal and because

some applications really really wanted

to use the security manager because they

couldn't upgrade very fast in in time

but still wanted to take advantage of

java latest

features it's also good that you can

allow the security manager temporarily

with your application name but you

should know that since jdk18 is this

allowed to use so there are still ways

to use it but pretty much not good so

let's go back to S to the API story

there are apis in the jdk that depend on

that apis that may be un need in your

day-to-day developer

life so we're going to go to the API

enhancements because many of them are

related to that so in the case of the

API repl replacement the Jaws apis were

the ones that were depending on the

security manager so what happened is

that the security

team has been implementing options to

still use the CH apis but a little

different so for example the adjust um

subject to us and subject get subject

API that dependent on the security

manager well uh even though they did not

require the security manager that's the

fun thing they depended on that one but

they did not needed it uh well they were

replaced in

jdk18 by different apis in the same

class name subject right so let's see

how code looks like for such an example

so for example using the old API the one

depending on security manager what you

need here you need to perform work as a

particular subject right but first you

require access to you get require

getting the access control context

object first I don't know

why well you yeah just use it further

and just get the subject so it was

cumbersome why was that extra object

needed while now you just invoke the

current method on the subject which

makes much more sense right it's much

more clean you don't need the access

control context for that you already in

the

context next

related to improvements to

apis well there are new apis for um

obtaining access to attributes for in a

key store so for example if before jdk18

this is how you would write a piece of

code to get access to the attributes of

an

um to get the attributes of a key store

so you're first needed to get an entry

from the key store uh then call the C

the get attributes on that entry like

okay so I need to know the entry then

call the attributes on the entry but I

want the key store right so why not do

that so that's the Improvement this it's

not just less code it's just actually

not having an extra object when you

don't need it so access an extra object

when you actually don't need to use that

object further in your

code there are also some improvements to

the apis that customize TLS and dtl LS

signature schemes so now they're like

Setters and Getters for getting the

signature

schemes um and when you need to

negotiate a TLS or dtls

connection um and yeah this is an

enhancement for the for a job regarding

the transport layer protocol that was in

the past and also for uh TLS and

dtls

there there's a new API for um the do I

duplicate this oh no no there's a new

API for customizing named groups also

for TLS and

dtls um at some point in my slides

you're going to see like a little flying

UFO in in down there it's very little

but I'm going to give you access to the

slides some of the changes that were

done in the jdk security were back

ported as well to 8 11 and 17 so um

that's the reason you have see the

little sorts um lateral UFO there uh

with also with the backboard so that you

know what was affected and maybe you can