You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: verify that BC works with approved_only mode set (#375)
The bouncycastle FIPS provider happily does things that are not
FIPS-compliant when the
`org.bouncycastle.fips.approved_only` system property is not set to
`true`. The following problems were observed:
1. using OAEP to `ENCRYPT` rather than `WRAP`. We are indeed using OEAP
for key wrapping so we just had
to change some cipher parameters. `WRAP` and `ENCRYPT` perform the same
operation; the only difference
is in the semantics and the JCA API associated with each operation. This
should not affect compatibility with other parts of the platform in any
way.
1. Without `approved_only` BC would be fine using a non-FIPS truststore.
Now we add an empty truststore
(with an empty password) of a type that can be loaded by the BC FIPS
truststore.
1. Our home grown implementation of HKDF didn't work because our usage
of `SHA-265/HMAC` within the HKDF
implementation triggers the error:
`ECKeyPairTest.createSymmetricKeysWithOtherCurves:129 » IllegalKey Key
size for HMAC must be at least 112 bits in approved mode: SHA-256/HMAC`.
By using a FIPS compliant provider that implements HKDF directly we
bypass this error.
We include the FIPS implementation of HKDF in a separate JAR due to its
dependency on the bouncycastle FIPS provider. If we included it in the
same JAR we would have a dependency on `bc-fips`, which would conflict
with usage of the regular bouncycastle provider. Since bouncycastle is
popular it seems best to allow non-FIPS usage.
The major change from a customer POV is that customers that want to use
EC crypto in a FIPS context will now
need to pull in the `sdk-fips-bouncycastle` jar and depend on `bc-fips`
since HKDF [only got a JCA name
in JDK 24](https://openjdk.org/jeps/478) and [bc-fips does not expose
HKDF through a provider
interface](https://downloads.bouncycastle.org/fips-java/docs/BC-FJA-UserGuide-2.1.1.pdf).
If using `bc-fips` is not appropriate
in a particular application it would be quite easy to implement an
alternative JAR that implements a similar
provider pattern and uses whichever FIPS-compliant library one wishes to
implement HKDF.
Also:
* pull the test scripts in `checks.yaml` in to bash files so they can be
run locally more easily
* add a FIPS mode `cmdline` platform integration phase
* publish the new FIPS provider JAR to maven central
* remove double addition of generated sources that was generating a
warning
* overwrite the `java.security` file in its entirety so that we know
exactly which providers we are using in FIPS tests
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
- name: Validate the SDK through the command line interface
148
+
- name: Build java SDK${{ matrix.label }}
141
149
run: |
142
-
printf 'here is some data to encrypt' > data
143
-
144
-
java -jar target/cmdline.jar \
145
-
--client-id=opentdf-sdk \
146
-
--client-secret=secret \
147
-
--platform-endpoint=http://localhost:8080 \
148
-
-h\
149
-
encrypt --kas-url=http://localhost:8080 --mime-type=text/plain --attr https://example.com/attr/attr1/value/value1 --autoconfigure=false -f data -m 'here is some metadata' > test.tdf
150
-
151
-
java -jar target/cmdline.jar \
152
-
--client-id=opentdf-sdk \
153
-
--client-secret=secret \
154
-
--platform-endpoint=http://localhost:8080 \
155
-
-h\
156
-
decrypt -f test.tdf > decrypted
157
-
158
-
java -jar target/cmdline.jar \
159
-
--client-id=opentdf-sdk \
160
-
--client-secret=secret \
161
-
--platform-endpoint=http://localhost:8080 \
162
-
-h\
163
-
metadata -f test.tdf > metadata
164
-
165
-
if ! diff -q data decrypted; then
166
-
printf 'decrypted data is incorrect [%s]' "$(< decrypted)"
encrypt --kas-url=http://localhost:8080 --mime-type=text/plain --with-assertions=$ASSERTIONS --autoconfigure=false -f data -m 'here is some metadata' > test.tdf
189
-
190
-
java -jar target/cmdline.jar \
191
-
--client-id=opentdf-sdk \
192
-
--client-secret=secret \
193
-
--platform-endpoint=http://localhost:8080 \
194
-
-h\
195
-
decrypt -f test.tdf > decrypted
196
-
197
-
if ! diff -q data decrypted; then
198
-
printf 'decrypted data is incorrect [%s]' "$(< decrypted)"
encrypt --kas-url=http://localhost:8080 --mime-type=text/plain --with-assertions="$SIGNED_ASSERTIONS_HS256" --autoconfigure=false -f data -m 'here is some metadata' > test.tdf
printf 'decrypted data is incorrect [%s]' "$(< decrypted)"
230
-
exit 1
231
-
fi
232
-
233
-
echo "rs256 assertions"
234
-
235
-
java -jar target/cmdline.jar \
236
-
--client-id=opentdf-sdk \
237
-
--client-secret=secret \
238
-
--platform-endpoint=http://localhost:8080 \
239
-
-h\
240
-
encrypt --kas-url=http://localhost:8080 --mime-type=text/plain --with-assertions "$SIGNED_ASSERTIONS_RS256" --autoconfigure=false -f data -m 'here is some metadata' > test.tdf
0 commit comments