Considerations for the OpenVPN Use Case Clause Samples

Considerations for the OpenVPN Use Case. This work was done as part of a project involving a Java Card applet to pro- vide authentication when establishing a VPN connection, tightly integrated into OpenVPN. The projected benefit of this was twofold: increased security and increased usability. Smart cards typically provide much more secure storage of the key material. By selecting the Java Card platform, the cross-platform applet can be easily combined with existing deployed systems. The tight integration with OpenVPN aims to improve the user experience: we avoid third-party mid- dleware (which would be required for the use of more generic solutions, such as hardware tokens relying on standards like PKCS#11) and store the configuration files for OpenVPN on the card to simplify the setup process for the user. This use case implies a set of assumptions and limitations. There is some margin in terms of signing time, as signing operations are fairly infrequent and users would expect some latency when establishing a connection. More impor- tantly, the required throughout is low: after signing once, typical usage scenarios suggest a period of time during which the card is connected and powered, but not used to produce a new signature. Furthermore, we note that key generation can be done during issuance, and even outside of the card (assuming a secure issuance environment – this is a reasonable assumption given that initialization also involves, e.g., PIN codes). In principle, there is a nice match between these properties and the XMSSMT signature scheme. There are many time-memory trade-offs that can be flexibly tweaked, and there is ample opportunity for pre- computation either during key generation or idle time. However, it is important to reiterate that memory (in particular the fast RAM) is a scarce resource on the card. The next section details these trade-offs. 4 Implementation‌ When designing a smart card application, it is important to consider natural ‘commands’ that divide up and structure the computation. For a traditional RSA-2048 or ECC signature, signing a message could be a single command with a single APDU as response. For XMSSMT , signatures are several kilobytes in size and must be spread out over multiple 256-byte response APDUs. This behavior is typical for hash-based signatures on small devices [12]; they are too large to comfortably fit in RAM but are very sequential in their construction, strongly suggesting an interface where the signature is streamed out incrementally. There is m...