Partager via


Device Management Security

Device management has the following potential security risk: It supports both HTTP and HTTPS connections. Using HTTP connections can expose the communication to the local network.

Security is provided through Secure Sockets Layer (SSL), officially called Transport Level Security (TLS). While SSL supports three kinds of authentication, device management, by default, will use only one type: server authentication.

Windows CE clients can authenticate the server by obtaining the server certificate and verifying it by using the Certification Authority (CA) certificate that comes with the device. If the relative distinguished name (RDN) of the certificate does not match the name of the server being connected to, then the connection is dropped because the server is not who it contends it is. The device should be able to authenticate itself against a server requiring NTLM or plain text authentication. Because all connections happen over SSL, sending the password in clear text is acceptable practice.

Connection credentials should be stored on a per server basis and it should be possible to connect to different servers with different credentials.

Optionally, the OEM should be able to supply an authentication routine that can do extra checking of both the server credentials and the server's authority to schedule certain actions, for example scheduling a task, and check the contents of a payload.

The Device Management Client (DMC) provides a transparent manageability solution for embedded devices. Activating the client on the device means that an administration server will be able to send software updates and run scripts that can perform actions on the system. The Device Management Script Engine runs the scripts. These actions can be potentially malicious. To ensure that the client is not compromised, the DMC enforces a certificate-based authentication policy. Once this certificate is provisioned, all download and run access is granted to the administration server.

Best Practices

Install the proper certificate on the device

The DMC will not be able to run properly until the proper certificate is installed on the device. This helps to prevent unauthorized server access to the device. This is built-in and cannot be disabled. It is also important to remove any certificates that are not used from the device.

Use an access control scheme

Use an access control scheme, for example a password, to ensure that the device is locked down. This helps to prevent sensitive data that might have been downloaded from being lost. The Data Protection API (DPAPI) protects all data but this is effective only when the device is access controlled.

Include a device identifier in ROM

It is highly recommended that OEMs include a device identifier in ROM to ensure that the device identifier cannot be spoofed. This will also ensure the enterprise integrity and uniqueness of the device.

Do not use dangerous commands in scripts and executable programs

Be careful to make sure that the administration does not use potentially dangerous commands in scripts sent down to the Script Engine. Test scripts and executable programs before deploying them.

Be careful when scripting report tasks

Be careful when scripting report tasks because reports can be scheduled to reach any server.

Ensure that the user does not incorrectly provision the device

Ensure that the user does not incorrectly provision the device for a server other than the one specified by the administrator.

Default Registry Settings

You should be aware of the registry settings that impact security. If a value has security implications, you will find a Security Note in the registry settings documentation.

For device management registry information, see Device Management Registry Settings.

Ports

No specific ports are used for device management.

 Last updated on Thursday, April 08, 2004

© 1992-2003 Microsoft Corporation. All rights reserved.