Communication Paths

YSoft SafeQ 6, on a very abstract level, is comprised of several network communication paths described in this article. A general overview of the communication is as follows:

There are eight major paths available in YSoft SafeQ 6:

1. Communication from client workstation to YSoft SafeQ server – for printing.

   1. Sending job from the computer

   2. Sending job from the mobile client

2. Communication from terminal/reader to YSoft SafeQ server – for MFD level authentication

3. Communication from server to network printer / MFD, covering the following:

   1. printing

   2. AAA services - authentication, authorization, and accounting.

4. Integration with identity management database or identity / authentication provider or Certification authority.

5. Connection from YSoft SafeQ server to the SMTP mail server or shared network folder for data delivery.

6. Integration with 3^rd party applications or systems.

7. Inter-server communication in Distributed SafeQ Server system.

8. Administrator access to YSoft SafeQ management interface.

Data security options

There are several data transfers realized over the described communication paths. Those data can be secured by the following means. Authentication and encryption details will be described further.

TLS-based data encryption

Authentication

• YSoft SafeQ 6 supports unauthenticated TLS communication for data paths 1, 2, 3, 4, 5, 7, 8

• 3^rd Party communication model is based on individual applications and/or protocols.

• Server Authentication is enabled by default for data paths:

  • 4 (YSoft SafeQ server verifies LDAP certificate & domain name)

  • 7 (SPOC server verifies Management server certificate)

  • 8 (Administrator web browser verifies YSoft SafeQ server certificate & server hostname).

• Server Authentication is supported for data paths:

  • 1 (Client computer verifies YSoft SafeQ server certificate & server hostname. YSoft SafeQ Client and printer drivers must be installed at the workstation, printer sharing from the central server is not possible)

  • 2 (YSoft SafeQ terminal verifies YSoft SafeQ certificate & server IP address)

  • 3a (YSoft SafeQ server verifies printer certificate & printer hostname)

  • 3b (MFD verifies server certificate - this depends on MFD capabilities and requires trusted CA)

  • 5 (YSoft SafeQ server verifies mail server certificate)

• Client authentication is supported for:

  • 7 (SPOC server verifies Management server certificate and vice versa)

Key management (trusted CA):

• Administrator uploads trusted issuer (CA) certificate to YSoft SafeQ 6.

• YSoft SafeQ server certificate(s) - for Terminals, Workstation Clients, and administrator workstation(s).

  • The administrator creates certificates for all servers using Trusted CA.

  • Server certificates (private keys) are stored in a password-protected key store on the YSoft SafeQ server disk with password hard-coded to the application or in System Key Storage (Windows Certificate Store).

  • Client can verify the server identity using certificate trust and server hostname / IP address.

• MFD Certificates

  • MFDs are verified using a trusted certificate and hostname.

• LDAP Certificate

  • The LDAP server is verified using a trusted certificate and hostname.

Key management (without trusted CA):

• YSoft SafeQ server certificate(s) - for Terminals, Workstation Clients, and administrator workstation(s).

  • The administrator creates self-signed certificates for all servers.

  • Server certificates (and private keys) are stored in a password-protected key store on the YSoft SafeQ server disk with password hard-coded to the application or in System Key Storage (Windows Certificate Store).

  • Client can verify the server identity using certificate trust and server hostname / IP address, in case the created certificate is stored in

• MFD Certificates

  • YSoft SafeQ retrieves X509 certificate on the first connection to the MFD.

• LDAP Certificate

  • YSoft SafeQ retrieves X509 certificate on the first connection to the identity database provider.

Authentication

YSoft SafeQ 6 supports user authentication to the terminal in various modes (Domain username, Username & password, PIN, card, and combinations of these). Terminal always communicates authentication data (PIN codes, Card Numbers, or User Credentials) via secured TCP/IP communication to the YSoft SafeQ server.

Authentication data are verified by the following means:

• For SPOC - data are ALWAYS verified with Local Data Cache and (only if not found locally) with Management Server. Data are replicated to SPOC data caches in scheduled intervals or on demand (by Administrator or 1st User Access).

• For Management - PIN codes and Card Numbers are verified by sub-string match in the YSoft SafeQ SQL database. PIN codes are typically stored in form of a one-way hash.

• User Credentials (Login/Password) on Management Server are verified either by sub-string match in YSoft SafeQ SQL database (if manually assigned to the user) or with LDAP - using the LDAP/S authentication mechanism. Locally stored passwords (one-way hashes) are replicated to the SPOC data cache. If the password is found in the SPOC data cache, Management Server (and further LDAP server) is not used.

Authorization model

YSoft SafeQ 6 is managed via a centralized web interface.

It uses Role-based access control (RBAC) with a Capability model for certain system operations. The administrator can create multiple roles and delegate selected administrative and managerial permissions and operations to these roles. It is also possible to define personal user accounts with full administrative privileges, and disable the default, anonymous administrative account.

YSoft SafeQ 6 supports replication of roles from external sources (e.g., Active Directory/LDAPS or CSV file) with additional administration within YSoft SafeQ 6.

With Active Directory and eDirectory, the YSoft SafeQ system takes advantage of advanced Active Directory-specific replication information to optimize the replication process.

Impact on system response speed

Enabled encryption of communication paths may produce a delay in data delivery. For most of the communication paths, the delay doesn't have any measurable impact on to end user experience, most affected data paths are 1, 2, and 3a.

Data delivery throughput for TLS-based encryption (SSL over IPP) depends on the speed of the target printer.

Internal System Audit log

SafeQ logs all CRUD operations to the log file(s) on the file system using the standard Log4j logging library. Manual administrative operations are tracked by the system in dedicated audit logs, which are accessible to delegated users in the web interface.

Passwords and authentication data are not logged. Access to the log files is not controlled and must be managed on the operating system level.

Data Storage Methods and Access to the System

All data within the operation of the system is stored in the following ways:

• Internal SQL database. In the case of embedded PGSQL/MSSQL Express, the database is accessible only via the local host interface. In the case of an external DB, the security model is the responsibility of the database administrator. The database is accessible only with the name and password stored in the configuration file.

• Internal Configuration Files. Are stored in the YSoft SafeQ 6 operation directory in a text format. The data is secured on the same level of access as relevant directories and OS.

• External Data sources. Configuration dependent.

• All passwords and user codes are stored in the configuration files and database in an encoded form (a one-way hash). Access data to external systems (including access to the SQL DB YSoft SafeQ 6 itself) is stored encoded by AES-256 encryption (using a hardcoded key).

• Print job data is stored temporarily on the file system in the plain unencrypted form as received from the source workstation. Using system configuration, this data can be automatically deleted (not wiped) after print or administrator-defined expiration time.

Used technologies

The whole solution is proprietary. Java 11 is used for System Core, MS .NET 4.5 Framework for MFD integration, and Apache Tomcat, MS SQL, or PostgreSQL Database Engines are among the standard 3rd party components used in the solution.

Additional notes

Some print drivers support print job data encryption for a particular printer. This feature can only be used for direct print to the specified device.

All session timeouts in the system (administrative console or terminal access) are administrator definable using a centralized web interface.

Older versions of SafeQ had the possibility to enforce minimum standards for secure passwords when adding new users to SafeQ. However, it was not enforced by default (the local administrator had to set the values for minimumPasswordLength and enforceStrongPasswords properties in the system configuration). Newer versions of SafeQ have these values enforced by default in case the local administrator did not change them manually already (there is no change in that case). The enforced password security applies only to new users. Existing users with weak passwords can still log in as same as admin with the default password. But it is highly recommended to change it.