Menu, toolbar and Icons of SCTS DM

1.1 Menu

1.1.1 Configuration

The Configuration menu can be used to save the changes in the devices, to clear the session pane and to remove all the configured devices.

1.1.2 Settings

The Settings menu can be used to start stop or configure transport servers. It can also be used to view the state of various transport servers. The Settings menu can be used to set the logs path. By default, the logs are saved in the path where SCTS DM is installed. The settings menu is also used to select the type of OBEX service the client has to use to connect to the obex server.

1.1.3 Tools

Currently available tool in the Tools menu is the ‘Credentials calculator’ and WBXML – XML converter.

1.1.4 Help

The Help menu has the guides which help in configuring the tool as a normal client/server or a test client/server. The Help menu can be used to report a bug to the SCTS team, which will prompt the user as to what are the necessary information that has to be sent to the SCTS team.

1.2 Toolbar

The various toolbar items are context sensitive. For example the ‘ + Add Device’ will add a ‘Client Device’ if the focus is on the ‘Client Devices’ object or will Add a ‘Server Device’ if the focus is on the ‘Server Devices’ object.

1.3 Icons

SCTS DM has different icons to represent the various internal objects. The icons corresponding to the different internal objects are shown below.

Device Management tree

DM Accounts

Connection objects

Commands

Server Device:

Client Device:

Session with Errors:

Session without Errors:

Test passed

Test failed

Not Tested

Optional Test

Not supported

Posted in: Mobile-OMA| Tags: OMA SCOMO DM Menu Toolbar Icon SCTS Server

---

Handshake Protocol Overview in TSL

The cryptographic parameters of the session state are produced by the
TLS Handshake Protocol, which operates on top of the TLS record
layer.When a TLS client and server first start communicating, they
agree on a protocol version, select cryptographic algorithms,
optionally authenticate each other, and use public-key encryption
techniques to generate shared secrets.

The TLS Handshake Protocol involves the following steps:

-Exchange hello messages to agree on algorithms, exchange random
values, and check for session resumption.

-Exchange the necessary cryptographic parameters to allow the
client and server to agree on a premaster secret.

-Exchange certificates and cryptographic information to allow the
client and server to authenticate themselves.

-Generate a master secret from the premaster secret and exchanged
random values.

-Provide security parameters to the record layer.

-Allow the client and server to verify that their peer has
calculated the same security parameters and that the handshake
occurred without tampering by an attacker.

Note that higher layers should not be overly reliant on whether TLS
always negotiates the strongest possible connection between two
peers.There are a number of ways in which a man-in-the-middle
attacker can attempt to make two entities drop down to the least
secure method they support.The protocol has been designed to
minimize this risk, but there are still attacks available: for
example, an attacker could block access to the port a secure service
runs on, or attempt to get the peers to negotiate an unauthenticated
connection.The fundamental rule is that higher levels must be
cognizant of what their security requirements are and never transmit
information over a channel less secure than what they require.The
TLS protocol is secure in that any cipher suite offers its promised
level of security: if you negotiate 3DES with a 1024-bit RSA key
exchange with a host whose certificate you have verified, you can
expect to be that secure.

These goals are achieved by the handshake protocol, which can be
summarized as follows: The client sends a ClientHello message to
which the server must respond with a ServerHello message, or else a
fatal error will occur and the connection will fail.The ClientHello
and ServerHello are used to establish security enhancement
capabilities between client and server.The ClientHello and
ServerHello establish the following attributes: Protocol Version,
Session ID, Cipher Suite, and Compression Method.Additionally, two
random values are generated and exchanged: ClientHello.random and
ServerHello.random.

 The actual key exchange uses up to four messages: the server
Certificate, the ServerKeyExchange, the client Certificate, and the
ClientKeyExchange.New key exchange methods can be created by
specifying a format for these messages and by defining the use of the
messages to allow the client and server to agree upon a shared
secret.This secret MUST be quite long; currently defined key
exchange methods exchange secrets that range from 46 bytes upwards.

Following the hello messages, the server will send its certificate in
a Certificate message if it is to be authenticated.Additionally, a
ServerKeyExchange message may be sent, if it is required (e.g., if
the server has no certificate, or if its certificate is for signing
only).If the server is authenticated, it may request a certificate
from the client, if that is appropriate to the cipher suite selected.
Next, the server will send the ServerHelloDone message, indicating
that the hello-message phase of the handshake is complete.The
server will then wait for a client response.If the server has sent
a CertificateRequest message, the client MUST send the Certificate
message.The ClientKeyExchange message is now sent, and the content
of that message will depend on the public key algorithm selected
between the ClientHello and the ServerHello.If the client has sent
a certificate with signing ability, a digitally-signed
CertificateVerify message is sent to explicitly verify possession of
the private key in the certificate.

At this point, a ChangeCipherSpec message is sent by the client, and
the client copies the pending Cipher Spec into the current Cipher
Spec.The client then immediately sends the Finished message under
the new algorithms, keys, and secrets.In response, the server will
send its own ChangeCipherSpec message, transfer the pending to the
current Cipher Spec, and send its Finished message under the new
Cipher Spec.At this point, the handshake is complete, and the
client and server may begin to exchange application layer data.(See
flow chart below.)Application data MUST NOT be sent prior to the
completion of the first handshake (before a cipher suite other than
TLS_NULL_WITH_NULL_NULL is established).

Posted in: Mobile-OMA Internet Topic| Tags: Protocol TSL Handshaking Hello Message Cryptographic certificate

---

SyncML Introduction

1    SyncML Framework
This specification can be implemented by using the SyncML interface from the SyncML Framework (See Figure 2). Not all the features of the SyncML Interface need to be implemented to comply with this specification.
1.1.1    Figure 2 SyncML Framework
The application “A” depicts a networked service that provides data synchronization service for other applications, in this case application “B”, on some networked device. The service and device are connected over some common network transport, such as HTTP.
In the figure above, the ‘Sync Engine’ functionality is completely placed onto the OMA DS server side even if some OMA DS client implementations can in practice provide some sync engine functionality, too. The ‘Sync Server Agent’ and the ‘Sync Client Agent’ use the protocol defined in this specification and the representation protocol [DSREPU] offered by the SyncML interface (‘SyncML I/F’) to communicate with each other.
2    Device Roles
Figure 3 depicts a synchronization example in which a mobile phone acts as an OMA DS client and a server acts as an OMA DS server. The client sends SyncML message including the data modifications made in the client to the server. The server synchronizes the data (including possible additions, replaces, and deletions) within the SyncML messages with data stored in the server. After that, the server returns its modifications back to the client.
2.1.1     Synchronization Example with Mobile Phone and Server
The example presented the figure above is very simple. However, this example describes the roles of the devices in this specification. That is:
SyncML Client – This is the device that contains a sync client agent and that sends first its modifications to the server. The client MUST also be able to receive responses from the SyncML server. Although the SyncML client has always the role to send its modifications first, in some cases the server can have a role to initiate synchronization. The SyncML client is typically a mobile phone, PC, or PDA device.
SyncML Server – This is the device, which contains a sync server agent and sync engine, and which usually waits that the SyncML client starts synchronization and sends the clients modification to the server. The server is responsible for processing the sync analysis when it has received the client modifications. In addition, it can be able to initiate synchronization if unsolicited commands from the server to the client are supported on the transport protocol level. Typically, the SyncML server is a server device or PC.
3    Sync Types

 

Sync Scenario	Description
Two-way sync	A normal sync type in which the client and the server exchange information about modified data in these devices. The client sends the modifications first.
Slow sync	A form of two-way sync in which all items are compared with each other on a field-by-field basis. In practice, this means that the client sends all its data from a database to the server and the server does the sync analysis (field-by-field) for this data and the data in the server.
One-way sync from client only	A sync type in which the client sends its modifications to the server but the server does not send its modifications back to the client.
Refresh sync from client only	A sync type in which the client sends all its data from a database to the server (i.e., exports). The server is expected to replace all data in the target database with the data sent by the client.
One-way sync from server only	A sync type in which the client gets all modifications from the server but the client does not send its modifications to the server.
Refresh sync from server only	A sync type in which the server sends all its data from a database to the client. The client is expected to replace all data in the target database with the data sent by the server.
Server Alerted Sync	A sync alert type, which provides the means for a server to alert the client to perform synchronization. When the server alerts the client, it also tells it which type of synchronization to initiate.

Posted in: Mobile-OMA| Tags: SyncML DM Introduction Framework Device Sync Slow Sync Two-way

---

Some Definitions in syncML Data Sync Protocol

Application	A SyncML application that supports the SyncML protocol. The application can either be the originator or recipient of the SyncML protocol commands. The application can act as a SyncML client or a SyncML server.
Capabilities exchange	The SyncML capability that allows a client and server to exchange what device, user and application features they each support.
Client	A SyncML Client refers to the protocol role when the application issues SyncML "request" messages. For example in data synchronization, the Sync SyncML Command in a SyncML Message.
Client Modification	A modification of an item, which occurs in a client database before the modification is synchronized to the server database.
Command	A SyncML Command is a protocol primitive. Each SyncML Command specifies to a recipient an individual operation that is to be performed. For example, the SyncML Commands supported by this specification include Add, Alert, Atomic, Copy, Delete, Exec, Get, Map, Replace, Search, Sequence and Sync.
Data	A unit of information exchange, encoded for transmission over a network.
Data collection	A data element, which acts as a container of other data elements, (e.g., {c {{i1, data1}, ... {in, datan}}}). In SyncML, data collections are synchronized with each other. See data element.
data element	A piece of data and an associated identifier for the data, (e.g., {i, data}).
Data element equivalence	When two data elements are synchronized. The exact semantics is defined by a given data synchronization model.
Data exchange	The act of sending, requesting or receiving a set of data elements.
Data format	The encoding used to format a data type. For example, characters or integers or character encoded binary data.
Data type	The schema used to represent a data object (e.g., text/calendar MIME content type for an iCalendar representation of calendar information or text/directory MIME content type for a vCard representation of contact information).
Data synchronization	The act of establishing an equivalence between two data collections, where each data element in one item maps to a data item in the other, and their data is equivalent.
Data synchronization protocol	The well-defined specification of the "handshaking" or workflow required to accomplish synchronization of data elements on an originator and recipient data collection. The SyncML specification forms the basis for specifying an open data synchronization protocol.
GUID (Global Unique Identifier)	A number assigned to an object in a database. GUID values are never reused. Note that in practice, numbers do not have to be unique forever, they MUST only be unique as long as they exist in some mapping table.
LUID (Locally Unique Identifier)	A number assigned to an object in a database. LUID values are only unique locally, i.e., to a particular SyncML client database, but MAY be present on other SyncML client databases. In this protocol, the SyncML client device assigns to each object a locally unique, non-reusable identifier, or LUID. They are unique per device and per application.
Message	A SyncML Message is the primary contents of a SyncML Package. It contains the SyncML Commands, as well as the related data and meta-information. The SyncML Message is an XML document.
Operation	A SyncML Operation refers to the conceptual transaction achieved by the SyncML Commands specified by a SyncML Package. For example in the case of data synchronization, "synchronize my personal address book with a public address book".
Originator	The network device that creates a SyncML request.
Package	A SyncML Package is the complete set of commands and related data elements that are transferred between an originator and a recipient. The SyncML package can consist of one or more SyncML Messages.
Parser	Refers to an XML parser. An XML parser is not absolutely required to support SyncML. However, a SyncML implementation that integrates an XML parser may be easier to enhance. This document assumes that the reader has some familiarity with XML syntax and terminology.
Recipient	The network device that receives a SyncML request, processes the request and sends any resultant SyncML response.
Representation protocol	A well-defined format for exchanging a particular form of information. SyncML is a representation protocol for conveying data synchronization and device management operations.
Request	A message or a command sent from a device to another.
Server	A SyncML Server refers to the protocol role when an application issues SyncML "response" messages. For example in the case of data synchronization, a Results Command in a SyncML Message.
Server alerted notification	The general term for Server Alerter Synchronization
Server modification	A modification of an item, which occurs in the server database before the modification is synchronized to the client database.
Slow synchronization	When a data set is synchronized for the first time, or state relating to the synchronization has been lost, the whole data set MUST be copied from one device to the other. Since this can be a time-consuming operation, this is known as slow synchronization.
Synchronization anchor	A string representing a synchronization event. The format of the string will typically be either a sequence number or an ISO 8601-formatted extended representation, basic format date/time stamp.
Synchronization data	Refers to the data elements within a SyncML Command. In a general reference, can also refer to the sum of the data elements within a SyncML Message or SyncML Package.
Synchronization engine	The portion of a SyncML server that can analyze a data set and modifications to that data set made by both SyncML server and SyncML client. The synchronization engine will implement policies to enable the detection and resolution of conflicting changes.
SyncML request message	An initial SyncML Message that is sent by an originator to a recipient network device.
SyncML response message	A reply SyncML Message that is sent by a recipient of a SyncML Request back to the originator of the SyncML Request.
Temporary GUID	A temporary number assigned by the server to an object in a database (See also GUID.). Temporary GUID values are valid till the map operation for the items, with which the temporary GUIDs are associated, has been received from the client. After that the temporary GUID can be erased.

Posted in: Mobile-OMA| Tags: Definition SyncML Data Sync Protocol

---