Upload
nicholas-carroll
View
17
Download
0
Embed Size (px)
DESCRIPTION
OMA-BCAST-2004-0145-RD Comments Issues not addressed in BCAST Requirements. Comments to slides #3 and #4 by Nokia. Submitted To:BCAST Date:4 th November 2004 Availability: Public OMA Confidential Contact: Arieh Moller ( [email protected] ) - PowerPoint PPT Presentation
Citation preview
© 2004 Open Mobile Alliance Ltd. All Rights Reserved.Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-BCAST-2004-0nnn Slide #1
[OMA-Template-SlideDeck-20040122]
Submitted To: BCAST
Date: 4th November 2004
Availability: Public OMA Confidential
Contact: Arieh Moller ([email protected])
Arjen van der Vegt ([email protected])
Herve Brugal ([email protected])
Ilan Mahalal ([email protected])
Source: NDS, Irdeto Access, Gemplus, Axalto
OMA-BCAST-2004-0145-RD Comments
Issues not addressed in BCAST Requirements
USE OF THIS DOCUMENT BY NON-OMA MEMBERS IS SUBJECT TO ALL OF THE TERMS AND CONDITIONS OF THE USE AGREEMENT (located at http://www.openmobilealliance.org/UseAgreement.html) AND IF YOU HAVE NOT AGREED TO THE TERMS OF THE USE AGREEMENT, YOU DO NOT HAVE THE RIGHT TO USE, COPY OR DISTRIBUTE THIS DOCUMENT.
THIS DOCUMENT IS PROVIDED ON AN "AS IS" "AS AVAILABLE" AND "WITH ALL FAULTS" BASIS.
X
Comments to slides #3 and #4 by Nokia
Comments to slides #3 and #4 by Nokia
© 2004 Open Mobile Alliance Ltd. All Rights Reserved.Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-BCAST-2004-0nnn Slide #2
[OMA-Template-SlideDeck-20040122]
Key Issues
• We believe that the current version of the BCAST requirement contain some serious security flaws.
• The area that we believe need requirements added is Service & Content Protection
© 2004 Open Mobile Alliance Ltd. All Rights Reserved.Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-BCAST-2004-0nnn Slide #3
[OMA-Template-SlideDeck-20040122]
Service & Content Protection
• The issues that we still believe needs to be addressed are as follows:• There needs to be a mechanism to allow for the application of “bug fixes” to deployed devices
• There needs to be a mechanism to allow for upgrading the key management systems if new business models are required to be supported
• There needs to be a method to allow for the key management system to be replaced if (and when) it gets compromised.
• There needs to be a mechanism that can complement device revocation, as revocation has many negative operational implications e.g. an annoyed user base
the requirement as formulated calls for a specific solution to a potential problem (there is no business requirement that would call for replacable modules; the business requirement is to have a secure solution that supports mobility and interoperability)
Conclusion:
if experts in the DRM group conclude that a mechanism such as the proposed one is needed, this mechanism can and will be specified
the requirement as formulated calls for a specific solution to a potential problem (there is no business requirement that would call for replacable modules; the business requirement is to have a secure solution that supports mobility and interoperability)
Conclusion:
if experts in the DRM group conclude that a mechanism such as the proposed one is needed, this mechanism can and will be specified
© 2004 Open Mobile Alliance Ltd. All Rights Reserved.Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-BCAST-2004-0nnn Slide #4
[OMA-Template-SlideDeck-20040122]
S&CP requirements
Therefore we suggest that the following requirement be added:• The system SHALL support the defined key management system, and SHALL allow for an open standard secure mechanism to allow for system recovery, upgrades, and bug fixes.
• In light of preliminary comments we wish to stress that by no means does the above conflict with the following requirement:
• SPCP-2 Openness - All functions needed for service and content protection, including e.g. the key management, the delivery, and encryption and decryption operations of keys and content, and interfaces, SHALL be fully specified so that no proprietary extension to any part of the system are required.
• The above does not require any extension, but rather ALLOWS it.
upgrades shall be covered by device management
• if security of the upgrade mechanism is of concern, this can be brought into DM
we need no standardized mechanism to distribute bug fixes
• bugs in the mechanism need to be eliminated in the specification and IOP phase
• bugs in the implementation are under the responsibility of the vendors
what does system recovery mean?
• there can’t be a requirement for something we don’t know what it is
Conclusion:
• the mechanisms that make up a secure service and content protection system, as well as the mechanisms that are required to keep it secure, shall be specified during specification work, but there is at this moment in time no genuine requirement that calls for a particular solution such as the proposed one.
upgrades shall be covered by device management
• if security of the upgrade mechanism is of concern, this can be brought into DM
we need no standardized mechanism to distribute bug fixes
• bugs in the mechanism need to be eliminated in the specification and IOP phase
• bugs in the implementation are under the responsibility of the vendors
what does system recovery mean?
• there can’t be a requirement for something we don’t know what it is
Conclusion:
• the mechanisms that make up a secure service and content protection system, as well as the mechanisms that are required to keep it secure, shall be specified during specification work, but there is at this moment in time no genuine requirement that calls for a particular solution such as the proposed one.
© 2004 Open Mobile Alliance Ltd. All Rights Reserved.Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-BCAST-2004-0nnn Slide #5
[OMA-Template-SlideDeck-20040122]
Thank you!