Application Authentication
Hi, All
I have some question about MHP Application Authentication, please help me answer them, thanks
1. What's the difference or relationship between "Application Authentication" and "File Authentiction"?
2. For mhp specification 1.03, File Authentication process is described in chapter 12.4.4, but no application authentication is involved, what steps does Application Authentication include?
3. When a DSMCC File is accessed by using java.io.FileInputStream, mhp can authenticate it, if failed to authenticate, it is considered as an empty file, but for Application Authentication, when will do ?
4. For a File Authentication, mhp should search and verify the digital signature of it, however, checking signature is a time-consuming operation for embeded system, in the case if check signature when load each signed file, it may cost much time when run a Xlet. So how to avoid the repeated checking signauture?
# 1
> Hi, All
>
> I have some question about MHP Application
> Authentication, please help me answer them, thanks
>
> 1. What's the difference or relationship between
> "Application Authentication" and "File
> Authentiction"?
In an authenticated application, all the class files have to be authenticated.
In fact they all have to be authenticated by the same certificate as used to authenticate the first class file - the one which contains the class implementing javax.tv.xlet.Xlet.
Also if Class.getResource is used to load data files then those must be authenticated. Data files loaded via java.io or org.dvb.dsmcc need only be authenticated if desired by the application.
>
> 2. For mhp specification 1.03, File Authentication
> process is described in chapter 12.4.4, but no
> application authentication is involved, what steps
> does Application Authentication include?
>
See 12.6.1 "General principles", the paragraph beginning "For a DVB-J application to be correctly authenticated,"
> 3. When a DSMCC File is accessed by using
> java.io.FileInputStream, mhp can authenticate it, if
> failed to authenticate, it is considered as an empty
> file, but for Application Authentication, when will
> do ?
>
See 12.6.1 "General principles", the paragraph beginning "For a DVB-J application to be correctly authenticated,"
> 4. For a File Authentication, mhp should search and
> verify the digital signature of it, however, checking
> signature is a time-consuming operation for embeded
> system, in the case if check signature when load each
> signed file, it may cost much time when run a Xlet.
> So how to avoid the repeated checking signauture?
If the signature of a file has to be checked then there is no way to avoid it.
# 2
dear desperado, thanks for your reply,
About Application authencation, quote from the mhp spec 1.03,
"For a DVB-J application to be correctly authenticated, all the class files that the application consists of need to be signed,
the signatures need to verify (see 12.4.4, "Integration" on page 160) and the application_id needs to be from within the
range allocated to signed applications (see Table 12, "Value ranges for application_id" on page 84). If, during the loading
or execution of the application the MHP detects a signed file containing a class that failed to pass the authentication
process (e.g. because its actual hash value does not match the expected hash value), then the class shall be considered as
not available."
But I have three questions about the description,
1. Does app authentciation inclue all class files authencation, that is , if xlet has 10 class files, the app authentication will do file authentiation for 10 times?
2. According to spec 12.4.4, file authencation include hash verify and signature, certficate chain verify, Dose the applicaton authencation should verify signatures for the times as the number of class files?
it's not acceptable for much cost of signature verification for embeded system.
3. If application failed to authenticated, it can't be granted request permisions, but What's time of the start or end for application authentication, for start point, may be load the main class of Xlet, butthe end? Does it need to authencate all class files?
if yes, but the time of loading a class is not known to us, which depend on Xlet's behaviour, that is , we can't know what time xlet would authenticate all class files.
if no, Could we consider the end time of authencating the main class implementing javax.tv.Xlet as the end of application authenction?
hope your advice, thanks
graynick
# 3
> dear desperado, thanks for your reply,
>
> About Application authencation, quote from the mhp
> spec 1.03,
> "For a DVB-J application to be correctly
> authenticated, all the class files that the
> application consists of need to be signed,
> the signatures need to verify (see 12.4.4,
> "Integration" on page 160) and the application_id
> needs to be from within the
> range allocated to signed applications (see Table 12,
> "Value ranges for application_id" on page 84). If,
> during the loading
> or execution of the application the MHP detects a
> signed file containing a class that failed to pass
> the authentication
> process (e.g. because its actual hash value does not
> match the expected hash value), then the class shall
> be considered as
> not available."
>
> But I have three questions about the description,
>
> 1. Does app authentciation inclue all class files
> authencation, that is , if xlet has 10 class files,
> the app authentication will do file authentiation for
> 10 times?
Each class file must be authenticated some time before it's loaded.
If some of the 10 class files are never loaded then they don't have to be authenticated. If all are loaded then the implementation will have to authenticate all 10 files.
>
> 2. According to spec 12.4.4, file authencation
> include hash verify and signature, certficate chain
> verify, Dose the applicaton authencation should
> verify signatures for the times as the number of
> class files?
> t's not acceptable for much cost of signature
> verification for embeded system.
The implementation can cache results as long as the files in the network haven't changed. If a hash file is authenticated once then as long as the files used to authenticate it haven't changed (parent hash files, the signature file and the certificate file) then that process doesn't need to be repeated.
>
> 3. If application failed to authenticated, it can't
> be granted request permisions, but What's time of
> the start or end for application authentication, for
> start point, may be load the main class of Xlet, but
> the end? Does it need to authencate all class
> files?
Which language are you refering to here?
I would expect that as long as the Xlet class and the PRF are successfully authenticated then the Xlet would be granted permissions. Other class files can be authenticated later and if they fail, they just won't be loaded.
>
> if yes, but the time of loading a class is not known
> to us, which depend on Xlet's behaviour, that is , we
> can't know what time xlet would authenticate all
> class files.
>
> if no, Could we consider the end time of
> authencating the main class implementing
> javax.tv.Xlet as the end of application authenction?
>
>
> hope your advice, thanks
> graynick
# 4
Thanks for your answer,
Actually, Caching the authencation result can save the time of repeated process,just as your said, it's depend on the files not changed in the network, but we may lack of enough methods to detect those change, In MHP, we may use dsmcc.ObjectChangeEventListener to listen an object , the changed of version number of DSMCC module as well .
But if a hacker modify some files, he may not modify the DSMCC information in transport stream, that is , we may not detect it by normal method, we consider no change at the moment, the authentication will not repeat, in the case the security risk come out.
So, Do we can detect any change if the files is modified by any means, normally and abnormally?
# 5
I think this depends on how your implementation of DSMCC works. The implementation of DSMCC will have information not available through public MHP APIs. In any case, dsmcc.ObjectChangeEventListener is meaningless since it's effectively optional.
For example, some/most implementations cache the entire DSMCC carousel in memory and always keep the most current version of each file. On these implementations, the security mechanism can have a private interface with the DSMCC object carousel mechanism to track when security related files change regardless of the signalling.
I don't see the security risk of changing a file without changing the module version number. Most implementations would just ignore the changed file.
# 6
desperado, Thanks for your reply
As we said, it's important to cache authentiation result for MHP security implementation, now it can be saved into dsmcc cache, but if Xlet is transmitted from other soure, such as TCP/IP, Local Disk. How to save the authentication result? Do we need build an authenticated cache for each source? that is, IP authentication cache, Local cache?
MHP 1.1 introduce "Application Storage", terminal can save the whole application classes after it is authenticated, Once the Xlet is launched from storage next time, it should be authenticated again, so we acutal ly need a authentication cache to increase performance.
# 7
MHP 1.1 explicitly allows implementations to compute the authentication information when an application is stored and re-use that when the application runs. The only part of the authentication process which is critical when an application runs is checking the certificates, particularly to ensure that none have expired or been revoked.
