FAQs
Read to get answers for general questions about IBM Digital Asset Offline Signing Orchestrator.
What are the hardware requirements to use IBM Digital Asset Offline Signing Orchestrator?
You can deploy IBM Digital Asset Offline Signing Orchestrator on all models of IBM z17.
For each LPAR configuration, you must meet the minimum LPAR requirements:
- At least 1 IFL, 24 GB RAM, and 198 GB storage on each LPAR
- One hiperSocket between LPAR_1 and LPAR_2
- One hiperSocket between LPAR_2 and LPAR_3
For more information, see System requirements.
How can IBM Digital Asset Offline Signing Orchestrator isolate transaction data flow?
IBM Digital Asset Offline Signing Orchestrator is deployed on logical partitions (LPARs) on all models of IBM z17. Each LPAR has its own operating system, memory, and hypervisor. You can consider an LPAR as strong as separate hardware that is isolated from application data that is running on a different LPAR on the same system.
How does IBM Digital Asset Offline Signing Orchestrator ensure security?
IBM Digital Asset Offline Signing Orchestrator is designed with time-based security that requires transactions to wait for predefined amount of time before they move to the next state. The time-based security reduces the risks of fake manipulations or forced attacks. For more information, see Time-based security.
What's the difference between IBM Digital Asset Offline Signing Orchestrator and traditional offline solutions?
Traditional offline solutions use cold wallet that is physically isolated and completely offline to store private keys. Cold wallets can ensure security, but are less efficient due to arduous processes with great number of human interactions that limit the speed and volume of transactions.
Compared to traditional offline solutions, IBM Digital Asset Offline Signing Orchestrator reduces human interactions, which not only eliminate operational costs and errors, but also increase the ability to scale.
How does IBM Digital Asset Offline Signing Orchestrator improve efficiency?
Traditional offline solutions do not connect to the Internet and requires arduous processes, which limit the speed and volume of transactions. IBM Digital Asset Offline Signing Orchestrator reduces human interactions and automates the signing service processes, which enables faster and more frequent transactions to improve efficiency.
Where are my data and keys stored? Is IBM Digital Asset Offline Signing Orchestrator a storage solution?
IBM Digital Asset Offline Signing Orchestrator provides transaction signing services and is not a storage solution. Customers' data and keys are stored outside of it. Offline Signing Orchestrator can retrieve encrypted transactions through FrontEnd component and send them to sign through BackEnd component.
No one without required authentication, including admins, can access your data and keys.
Who has access to what?
Different types of admins and users of IBM Digital Asset Offline Signing Orchestrator can access different components in IBM Digital Asset Offline Signing Orchestrator.
- A System Administrator can deploy Offline Signing Orchestrator on CCRV virtual machine and can access all LPAR resources and HiperSockets, to set up and monitor the entire system.
- A System Custodian can access all the contracts and attestation records.
- An Operator can access LPAR resources and HiperSockets to monitor transaction flow.
- An Auditor can access Confirmation queues to handle documents.
- A user with the username
libvirt-usercan access each LPAR only to access the libvirt remote APIs, and enable or disable the HiperSockets on LPAR2.
What happens if I lose the private key?
If the private key of any user is lost, a new key needs to be generated for this user and the contract needs to be updated with the new certificates or fingerprints. This requires redeployment of the IBM Digital Asset Offline Signing Orchestrator with the new contract.
Can I migrate my data that is processed in IBM Digital Asset Offline Signing Orchestrator?
IBM Digital Asset Offline Signing Orchestrator is transient and data is not persisted. When the system is redeployed (for example because of a change occurs in the contract), the current data is lost. Unsigned documents in the Preconfirmation queue will be requeued from the Frontend. Signed documents in the Postconfirmation queue will be lost and require the signing process to proceed again.