Rosenfeld's answer is pretty much correct. Note however that the attack can only be successful if the attacker generates a fake chain in secret and then starts broadcasting the fake chain after the mini-blockchain has completed a full cycle (and providing that the attacker has managed to keep up with the real chain).
We are aware of this attack vector and we've developed a contingency plan to deal with it should it ever occur. The paper sourced by the question asker is a little bit outdated now, we have a project wiki which covers a lot of things that the paper skipped over. The Weaknesses and attack vectors page of the wiki discusses the "secret chain attack".
The Secret Chain Attack
If an attacker had enough hashing power he could generate a fake chain
in secret using the real proof chain but a fake account tree. He would
need to out-pace the real mini-blockchain for a full cycle until
there's no evidence left to indicate his account tree is fake and then
start broadcasting the fake chain.
This wouldn't affect older nodes who have been validating blocks for
longer than the cycle of the mini-blockchain because they could easily
detect that the fake chain appeared out of thin air. If it appears to
the node as if the chain popped out of thin air the node will simply
assume that the chain has no valid origin point.
So there's no way the attacker could trick existing nodes to accept
his fake chain, but new nodes are still at risk. New nodes have no
way of determining which is the valid chain because they have no
history of what happened before the oldest block in the
mini-blockchain. Using some sort of consensus mechanism is not perfect
either.
Minimizing risk of attack success
If a new node detects multiple chains which originate from the same
proof chain it can try to query other nodes for older blocks all the
way to the block in which the competing chains diverged and if no one
around has this long history (no one is required to have it) the node
will simply refuse to participate in the network until the situation
has been resolved.
It's unlikely the attack could last very long without the help of new
nodes but just in case the community will release a new checkpoint
pointing to the right chain as quickly as possible if this situation
does arise. When the checkpoint is released new nodes will be able to
safely join the network and help the other nodes work against the
attacker.
Since this attack will only put new nodes at risk and since it will
most likely never happen, this strategy is an acceptable contingency
plan for dealing with the attack. Worse case scenario is that new
nodes have to wait until a new checkpoint is released which points to
the real chain. Businesses already running a node would not be
affected in any way.