@RemoteWhitepaper Ver1.3
@RemoteWhitepaper Ver1.3
@RemoteWhitepaper Ver1.3
Service
White Paper
--
and
Data Security Policy
For Customers
Revision History
Note: This service offering may not be available in some countries or regions and depends
on the customer's technical environment.
Note: This service is not always effective for all breakdowns. But RICOH is working to
improve it.
Note: Reports may not be available in some countries or regions and some report content
may not be accessible depending on the customer's technical environment.
Communication Requirements
External communication over the internet: The remote service plugins use
Transport Layer Security (TLS) to communicate over the Internet.
Service plugins: To use RICOH @Remote Service, one of the following modules must
be installed in order to connect and communicate to the @Remote system. The
supported communication methods differ between these module plugins.
Note: When creating customer’s firewall exception is needed, please confirm to RICOH
personnel to have the IP Address or URL of @Remote system
Communication
Module Type Remarks
Method
@Remote embedded
Ethernet Built-in type.
devices
A separate server is
Software, running on a
Ethernet required to run the
server
software.
Note: These modules may not be available in some countries or regions and options and
implementation depend on the customer's technical environment.
The device sends the following information to the RICOH Server as necessary:
1. Supply calls
2. Service alerts
3. Device startup notifications
4. Alarm notifications
5. Failure recovery notifications
6. Manual service calls
7. Failure analysis
Note:
1. Some communication activities may not be supported in a specific country
depending on the device or @Remote module type.
2. The accuracy of the third party device information cannot be guaranteed.
The @Remote system mainly uses TLS (Transport Layer Security) for communications
between RICOH devices and RICOH Servers. This includes communications between RICOH
devices and the @Remote appliance, or between remote service components and the
RICOH data center. For communication between non-RICOH devices and the @Remote
appliance, the system mainly uses Simple Network Management Protocol (SNMP). Please
refer to 8.1.2 to be more precise.
Notes:
1. Depending on the devices or @Remote appliance type, only prior encryption
standards may be supported. Refer to the appropriate product manual or similar
documentation to check which encryption standards are supported.
2. Some RICOH devices may be shipped with a default authenticate key length of 512
bits. If higher security is required, Ricoh will change the key length to 2048 bits on the
devices.
1. RICOH @Remote Service never sends or obtains sensitive information or data (such
as personal information).
2. RICOH @Remote Service does not access any sensitive information such as the
customer’s print data, address book, or files contained in the device’s local storage
disk.
When it is necessary for the RICOH Server to obtain device information, for example, for
remote diagnostics, the RICOH system sends a secure instruction back in response to regular
polling by the @Remote Service plugin module.
For example, when it is necessary for the RICOH Server to obtain device information, the
RICOH system performs steps 1 to 6 in the following diagram, in this order.
Note: The @Remote-supporting devices regular polling of the RICOH system in order to [1]
notify operating status and [2] check for any commands from the RICOH Server.
Notes:
1. The data that can be sent varies depending on the device, device configurations, or
the service plugin module type.
2. Ricoh can configure devices to withhold some of the above-listed data elements.
1. RICOH's related subsidiary companies should not be considered as third party in this
section.
a. Disclosure is requested by law or provision is based on the law.
b. The customer is explicitly notified of the information that may be disclosed, and
consents to such disclosure.
c. To fulfill the use of data for provision of @Remote services, RICOH needs to
provide device information to a business partner such as subcontractors or
business agents, whom RICOH will manage appropriately.
d. To protect the interests of a person or legal entity, such as life, physical body, or
property, yet it is difficult to obtain explicit customer approval.
e. Device information needs to be taken over and disclosed for merger or business
succession based on legal reasons, in which case it will be handled within the
scope of the use of data.
f. RICOH is required to submit device information without the customer’s consent
in order to cooperate to the duties of the central or local government institutions
or their subcontractors set by law, in which case obtaining explicit customer
approval may obstruct the concerned duties.
This table identifies two communication scenarios between the customer’s devices and the
RICOH Server and the port number.
Figure 11: Public and Private Keys Used for Encryption and Decryption
Notes:
1. *National Institute of Standards and Technology (NIST) is a governmental institution
within the U.S. Department of Commerce. NIST studies and researches
instrumentation and standards in scientific technologies.
2. *As of January 2016.
The main common key encryption method used is AES cryptography. In this method, three
different key lengths are available: 128-bit, 192-bit, and 256-bit. NIST*1 has publicly
announced in a computer security report that AES using the 256-bit key length will be
available until year 2030*2.
Notes:
1. *National Institute of Standards and Technology (NIST) is a governmental institution
within the U.S. Department of Commerce. NIST studies and researches
instrumentation and standards in scientific technologies.
2. *As of January 2016.
Certificates for Ricoh device are embedded in the Ricoh devices. Even if a problem occurs
with Ricoh devices, Ricoh can effectively respond by dispatching a CE to update the
firmware or remotely update the certificates.
To address certificate security issues, Ricoh conducts regular reviews based on market IT
security standards and the latest IT trends
Figure 14: Encrypted Data Exchange using Public and Common Key
Document End
Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.
Alternative Proxies: