Security is always an important issue.  I doubt that many in the community will argue with that.

You bring up a great point that we must look at security issues as we move forward with SCORM2, but I think that they should be done concurrently with SCORM2, and not pause the needed innovation that is happening until they can be worked out.  This become especially important as some of the webservice proposals get evaluated.

Thanks

Chris Raasch

We agree with this point. Our paper proposes using an "answer key" file supplied with the SCO. This is used by the LMS server to evaluate the students responses and assign a score. The only reason this isn't widely exploited is that SCORM is not widely deployed. Its just a matter of time.

We just need to make cheating as hard as it is on any standardized test. Cheating will always be possible, we just need to make it harder to cheat the API than it is to cheat using traditional methods. Attackers will always favor the weakest point of attack, currently that's the API.

We would be happy to bring exploit code to the event in October. We are confident that this issue affects all LMS vendors because the attack is itself SCORM conformant.

This is an interesting question. My thoughts:

1) This isn't a new problem. Insecurity has been a criticism of SCORM since Day 1, yet it's been widely adopted. That's not an excuse though and as adoption increases, security is more of a concern. I agree that security should be reexamined in SCORM 2.0.

2) "SCORM is not for high stakes assessments"...that's been the party line to the security criticism, is that still valid?

3) While more security is required in some uses of SCORM (for instance the legally required compliance training cited in the paper), it is overkill in other uses. Do we really need a 128-bit encrypted encrypted communication to tell whether or not the learner has mastered the company's new phone system? As Len Murphy says in "SCORM 2.0: Grab the Low Hanging Fruit" - "So although security is important, the level need not be universally set to DEFCON 1." Perhaps we need a "secure mode". This mode could be coupled to a web services extension since securing the current API would be quite difficult if not impossible.

I agree that we don't need to go to "DEFCON 1". Even having the stuff encrypted is overkill (besides do you want to be responsible for implementing working crypto on javascript?). Just seperate the target from the attacker and you will have good security, which is all you need.

The idea of using web services to achieve this is interesting.