Automatic detection of file based KeyStore types.

In  elytron

Overview

  • If a user does not specify the type of a file based KeyStore can we auto detect the type?

  • There is most likely a finite set of types we would want to automatically recognise, possibly we could inspect the contents ourselves to detect different types - alternative attempt initialisation of different KeyStore objects until one succeeds. With the latter we would need to be careful one doesn’t silently succeed when it should have failed.

Issue Metadata

Issue

Dev Contacts

QE Contacts

  • TBD

Affected Projects or Components

  • WildFly, Security

Requirements

Hard Requirements

  • Point of this change is to be able to load keystore without specifying its type.

Implementation Plan

  • Finite set of supported keystore types for automatic detection: JKS, JCEKS, PKCS12, BKS, BCFKS, UBER

  • Some types are fairly easily recognizable, as they start with magic number: JKS (0xfeedfeed), JCEKS (0xcececece) - although if a keystore starts with such number it doesn’t necessarily mean that it is that type

  • Detect types of encrypted keystores? They may be a good candidate for try until success (let the provider do the decryption for us)

  • The idea is to prioritize different techniques with a priority

    • Magic number or different recognizeable pattern - check if the store contains one of known magic numbers - if yes, then try to load it and see if it is really that keystore

    • Try remaining supported types in a specific order / don’t try anything and fail - the order will be determined using file extension

  • Recognizable patterns:

    • JKS

      • Starts with magic number 0xfeedfeed

      • Version number - 0x00000002 or 0x00000001

    • JCEKS

      • Starts with magic number 0xcececece

      • Version number - 0x00000002 or 0x00000001

    • BKS

      • Starts with version number 0x00000002 - older version (BKS-v1) has version number 0x00000001

      • Salt length - looking at the BC provider source I found out its 20, hopefully it’t the only case - 0x00000014

      • Salt - 20 bytes

      • Iteration count - int with value 1024 - 2047 - 0x00000400 - 0x000007ff - top 21 bits are 0

        • 32 bytes until now

      • First entry type - byte of value 0-5 - first different pattern from UBER

    • BCFKS

      • ASN.1 encoding - starts with SEQUENCE - tag 0x30

    • PKCS12

      • ASN.1 encoding - starts with SEQUENCE - tag 0x30

    • UBER

      • Starts with version number 0x00000001 or 0x00000000

      • Salt length - looking at the BC provider source I found out its 20, hopefully it’t the only case - 0x00000014

      • Salt - 20 bytes

      • Iteration count - int with value 1024 - 2047 - 0x00000400 - 0x000007ff - top 21 bits are 0

        • 32 bytes until now (same as BKS)

      • encrypted data

Test Plan

  • TBD based on final implementation

Community Documentation