Korsec.eu
Polski
English

DIGITAL TV SYSTEM DISTRIBUTION
WITH A VERY HIGH SECURITY LEVEL

KORSEC is a system of digital content distribution. A security level of KORSEC is very high, much higher than other system like Conax or Latens. KORSEC based on SSH code family, which are used as a security code of bank transaction. The system contain two type of equipments: the first one is a server-coder SETTOBBOX, the second type is a SETTOPBOX. The STB is implemented with a code-protocol compatible with coder-server. The content data are sent to the STB as coded data and directly to the STB, which pass the authorisation process. The stream method is UNICAST. The way give us a full control of user, because the stream is coded individually. We are able to prepare a table of every channel and user, when the user turned on the STB equipment, when he set certain channel, how long the data have been sent, when the channel stopped, what action of user was after etc. There is no way to register in KORSEC the ideal copy of the authorised STB at the same time.
The KORSEC drops the second try of authorisation of “the same” STB. What's more, this fact is automatically register and send to the administrator.

Weeks of system:
1. the summarize bandwitch of content is growing proportional to numbers of active users
2. relatively high digital power is needed by AES coder, specially at server side
3. The output of the system is protected by DHCP protocol. There is no other popular and strong protocols compatible with hardware to chose.

Nowadays is not a problem with many gigabits bandwitch and high computing power, although it is steel some expensive.

Strong sides of system:
1. high level of transmission security to a settopbox
2. tolerance of a data lost in transmission. It is no any MPEG artefacts at TV screen.

About SHH:

Secure Shell or SSH is a network protocol that allows data to be exchanged over a secure channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary. SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding arbitrary TCP ports and X11 connections; it can transfer files using the associated SFTP or SCP protocols.

SSH architecture

Diagram of the SSH-2 binary packet.
The SSH-2 protocol has a clean internal architecture (defined in RFC 4251) with well-separated layers. These are:

  • The transport layer (RFC 4253). This layer handles initial key exchange and server authentication and sets up encryption, compression and integrity verification. It exposes to the upper layer an interface for sending and receiving plaintext packets of up to 32,768 bytes each (more can be allowed by the implementation). The transport layer also arranges for key re-exchange, usually after 1 GB of data has been transferred or after 1 hour has passed, whichever is sooner.

  • The user authentication layer (RFC 4252). This layer handles client authentication and provides a number of authentication methods. Authentication is client-driven, a fact commonly misunderstood by users; when one is prompted for a password, it may be the SSH client prompting, not the server. The server merely responds to client's authentication requests. Widely used user authentication methods include the following: "password": a method for straightforward password authentication, including a facility allowing a password to be changed. This method is not implemented by all programs.


  • "publickey": a method for public key-based authentication, usually supporting at least DSA or RSA keypairs, with other implementations also supporting X.509 certificates.


  • "keyboard-interactive" (RFC 4256): a versatile method where the server sends one or more prompts to enter information and the client displays them and sends back responses keyed-in by the user. Used to provide one-time password authentication such as S/Key or SecurID. Used by some OpenSSH configurations when PAM is the underlying host authentication provider to effectively provide password authentication, sometimes leading to inability to log in with a client that supports just the plain "password" authentication method.


  • GSSAPI authentication methods which provide an extensible scheme to perform SSH authentication using external mechanisms such as Kerberos 5 or NTLM, providing single sign on capability to SSH sessions. These methods are usually implemented by commercial SSH implementations for use in organizations, though OpenSSH does have a working GSSAPI implementation.


  • The connection layer (RFC 4254). This layer defines the concept of channels, channel requests and global requests using which SSH services are provided. A single SSH connection can host multiple channels simultaneously, each transferring data in both directions. Channel requests are used to relay out-of-band channel specific data, such as the changed size of a terminal window or the exit code of a server-side process. The SSH client requests a server-side port to be forwarded using a global request. Standard channel types include: "shell" for terminal shells, SFTP and exec requests (including SCP transfers)


  • "direct-tcpip" for client-to-server forwarded connections


  • "forwarded-tcpip" for server-to-client forwarded connections


  • This open architecture provides considerable flexibility, allowing SSH to be used for a variety of purposes beyond secure shell. The functionality of the transport layer alone is comparable to TLS; the user authentication layer is highly extensible with custom authentication methods; and the connection layer provides the ability to multiplex many secondary sessions into a single SSH connection, a feature comparable to BEEP and not available in TLS.



    Rys. 1 - Schemat autoryzacji odbiornika w systemie



    Rys. 2 - Schemat połączeń logicznych



    TELEWIZJA 3D  //  IPTV AVIOS  // TELEWIZJA HD   //  MULTIMEDIA PLAYER  //  IPTV STB KORBOX  // KORBANK.COM - KORSEC 2.0  // KORBANK.COM - KORSEC 1.0
    Korbank S.A.
    u. Nabycińska 19, 53-677 Wrocław
    NIP 894-26-41-602 REGON 932239691
    web: www.korbank.pl
    E-mail: info@korbank.pl
    Kontakt z Przedstawicielem:
    Tel. +48 71 712 77 77
    Copyright 2015 © Korbank S.A.