ScalarDL 3.8 has been released!

We are pleased to announce that we have released a new minor version of ScalarDL, ScalarDL 3.8. This minor release includes many new, backward-compatible features and improvements, including the addition of hash-based message authentication codes (HMACs) as a new authentication method. In this blog post, we will share some of those important new features and improvements in detail.

For ScalarDL design and implementation, please take a look at a previous blog post titled Scalar DL Implementation.

(For a Japanese version of this blog post, please see ScalarDL 3.8をリリースしました.

Authentication by using HMACs can now be specified

In ScalarDL 3.7 and earlier versions, only digital signatures could be used for client authentication (Ledger or Auditor authenticates the client), Ledger authentication (Auditor authenticates Ledger), and Auditor authentication (Ledger authenticates Auditor).

Digital signatures use asymmetric key pairs (private and public keys), and the sender uses their private key to create a signature for a message¹ and the receiver uses the public key corresponding to that private key to verify the message. Digital signatures can guarantee integrity, authentication, and nonrepudiation of messages², but that method is slow.

As of ScalarDL 3.8, you can use either digital signatures or HMACs for all authentications. HMACs guarantee the integrity and authentication of messages by sending and verifying messages by using a common key between the sender and receiver of messages. HMACs cannot guarantee nonrepudiation, since it is theoretically possible for the recipient to tamper with the message by using a common key³, but it is faster than digital signatures.

Note that using either digital signatures or HMACs does not sacrifice the capability of Byzantine fault detection in ScalarDL.

If the application that uses ScalarDL requires nonrepudiation⁴, digital signatures are needed. However, if the application that uses ScalarDL does not require nonrepudiation, HMACs are recommended as the authentication method from a performance perspective.

For further information on authentication methods in ScalarDL, please refer to the ScalarDL Authentication Guide.

[1]: This article assumes messages as client requests, asset records, and asset proofs in ScalarDL.
[2]: In this case, integrity means that the message has not been tampered with, authentication means the method to identify the creator of the message, and nonrepudiation means the property which proves to a third party that the received message was actually created by the sender.
[3]: Digital signatures can guarantee nonrepudiation because only the owner of the private key can create the signature.
[4]: For example, nonrepudiation is needed when an application wants to guarantee that data has not been tampered with after it has been read from ScalarDL.

ScalarDL containers now available on the AWS Marketplace with pay-as-you-go and additional metering capabilities

In ScalarDL 3.7 and earlier versions, container images of Ledger and Auditor in the AWS Marketplace were available under a bring-your-own-license (BYOL) model, which required a license agreement between your company and Scalar Inc.

As of ScalarDL 3.8, we added support for the AWS Marketplace Metering Service API, which automatically charges you based on how much you use the containers. Therefore, you no longer need to sign a license agreement directly with us when you use container images from the AWS Marketplace. This feature lets you easily use ScalarDL.

Note that the usage fees are calculated on an hourly basis per container. In addition, these container images currently run on instances with up to 2vCPU and 4GB memory.

For further information on ScalarDL containers in the AWS Marketplace, please refer to Scalar’s profile on the AWS Marketplace.

Client SDK, Ledger, and Auditor can be configured by using environment variables

In ScalarDL 3.7 and earlier versions, confidential information such as passwords and secret keys had to be written directly into the property files when configuring the Client SDK, Ledger, and Auditor. In addition, the property files had to be written to a disk device attached to the ScalarDL components. This would have risked leaking confidential information to third parties.

As of ScalarDL 3.8, you can now set these values from environment variables, enabling you to deploy ScalarDL with a higher level of security.

In addition to directly writing values such as <item name>=<value> in property files, as in ScalarDL 3.7 and earlier versions, you can now reflect the value set for the relevant environment variable by using placeholders such as <item name>=${env:<environment variable name>}. For more details, please refer to JavaDoc of ConfigUtil.

In addition, when using Docker container images that Scalar provides, you can set environment variables in the container configuration file (for example, in docker-compose.yml) to set the Client SDK, Ledger, and Auditor configuration values. This eliminates the need to create and maintain the property files when you are using ScalarDL, and lets you more easily and securely deploy and manage the containers.

For further information on the environment variables available when using the Docker container images that Scalar provides, please refer to the following documents:
- Fields section of ClientConfig
- Fields section of AuditorConfig
- Fields section of LedgerConfig

Wrap-up

We released ScalarDL 3.8, which contains great enhancements and improvements for our customers. To learn more about ScalarDL, please take a look at other posts on the Scalar Engineering Blog and the ScalarDL documentation.

If you have any questions or feedback, please contact us.